/srv/irclogs.ubuntu.com/2014/08/08/#juju-dev.txt

menn0axw: how's things?02:47
axwmenn0: heya. not bad, yourself?02:49
menn0axw: yeah not too bad. super tired after 2 terrible nights in a row with the youngest.02:49
menn0axw: did you catch up with what happened while you were on leave?02:50
menn0I reverted that Safe.J change as it made ensure-availability very unhappy02:50
menn0I have no idea why but it was that change that did it02:50
axwmenn0: I did see, yes, thanks for fixing02:50
axwmenn0: ok. it's weird, can't see why it'd break anything02:51
axwbut I think it shouldn't be too hard to work around02:51
menn0axw: ok cool02:54
menn0axw: also, regarding bug 1350983. is this something you can confirm as being fixed?02:56
menn0needs testing against azure to be sure.02:56
menn0axw: actually I just saw that Curtis says the problem is still happening even after the Safe.J change was reverted.02:57
menn0axw: so it might be something else02:57
axwyeah, I don't think that bug is related to Safe02:58
axwanyone around to do a review? https://github.com/juju/juju/pull/48306:02
TheMuemorning07:15
dimiternwaigani, hey, are your still around?07:38
dimiternTheMue, morning07:38
waiganidimitern: hello, yes :)07:38
dimiternwaigani, i'm sending you a quick write-up how I use git rebase workflow with my scripts/aliases07:39
dimiternwaigani, and I'd appreciate feedback on how it works for you :)07:39
waiganidimitern: thank you!07:39
dimiternwaigani, np, i'm glad somebody else will try it out!07:40
* TheMue is setting up a test environment with nested lxc containers07:47
voidspac_axw: ping08:03
voidspac_are you still awake?08:03
axwvoidspac_: awake? it's 4pm :)08:03
voidspac_axw: oh!08:03
voidspac_I always assume that it's the middle of the night for you when it's day for me :-)08:04
voidspac_axw: anyway, so on my PR to fix a local provider bug you complain that it doesn't fix the manual provider too...08:04
voidspac_axw: :-p08:04
* axw complains a lot08:04
axwI do indeed, because that's the way it screwed up my laptop08:05
voidspac_axw: heh, so report your own damn bugs...08:05
voidspac_axw: seriously though - do we want the same fix for the manual provider08:05
axwvoidspac_: pretty sure the original one was related to manual, but yeah, I should have08:05
voidspac_do we not want jujud to change networking for manually provisioned machines08:06
axwI think so08:06
axwumm08:06
voidspac_https://bugs.launchpad.net/juju-core/+bug/134963508:06
axwwell, what are the networks for a manual environment?08:06
voidspac_"local environment"08:06
voidspac_although, hmmm08:06
axwthe summary was changed08:06
axwthe title I mean08:07
axwanyway08:07
voidspac_sure08:07
voidspac_so in the fix I have we don't touch networks at all for local provider08:07
voidspac_"apply" just short-circuits and bails08:07
voidspac_you suggest having the networker "know" if the provider supports networking or not08:08
voidspac_axw: what specifically are you suggesting?08:08
axwvoidspac_: right. and this is the sort of thing fwereade prefers; that we operate in terms of environment/provider capabilities, rather than coding to specific providers08:08
* axw thinks08:08
voidspac_axw: ok, but local provider machine 0 *is* a special snowflake08:09
voidspac_unfortunately08:09
voidspac_so it's not *just* provider, it's the bootstrap machine on the local provider08:09
voidspac_not touching networking config at all for manual provider also makes sense - so long as that's what we want08:10
voidspac_(and is easy enough to add a check for)08:10
axwvoidspac_: so what *I* would prefer is that the networker do nothing for any envrionment whose SupportsNetworks method returns false08:12
voidspac_axw: when I grep for SupportsNetworks I get no results08:12
axwlemme check spelling08:12
axwvoidspac_: sorry, no first "s": SupportNetworks08:13
voidspac_axw: that would be easy enough if it fixes the issue08:13
voidspac_axw: I'll look into that (I notice you did mention it in your comment - sorry)08:14
voidspac_axw: thanks08:14
axwvoidspac_: atm, only the MAAS provider returns true (depending on MAAS version)08:14
voidspac_axw: we *need* the networking stuff for local provider machine != 008:14
voidspac_axw: it sets up something we need08:14
axwoh, we do? what's that?08:14
voidspac_not sure, but local provider breaks without it08:15
axwit's relatively new, and used just for MAAS I thought08:15
voidspac_that was my first approach08:15
voidspac_dimitern: ^^^^08:15
axwbuh08:15
voidspac_axw: let me try again08:15
voidspac_(once a test run finishes)08:15
axwokey dokey08:15
axwdimitern: is it safe/sensible to disable the networker worker if the environment's SupportNetworks method returns false at machine agent startup?08:16
voidspac_if you have openstack environment variables set there's a juju-metadata test that always fails08:16
voidspac_it doesn't get the error it expects08:16
axwwonderful08:16
axwthat means it's not embedding the base suite I guess08:16
TheMue$ remove => not found / $ delete => not found / $ destroy => destroyed *aaaaaaah*08:18
=== psivaa-afk-bbl is now known as psivaa
dimiternaxw, unfortunately, no08:20
dimiternvoidspac_, axw, supportnetworks capability is supposed to be used by providers to tell juju if *any* networking is supported, but for the local/manual case this is not enough08:20
dimiternvoidspac_, axw, it seems to me we need another capability or something for this08:22
axwdimitern: I don't quite understand. local and manual both currently return false for SupportNetworks, so why isn't that enough to go by?08:22
axwif that means "no networking is supported"08:22
dimiternit's not necessarily an environment-wide setting (for local it only needs to apply to the bootstrap node; for manual too I guess, but how about manually provisioned machines?)08:23
dimiternaxw, because I haven't got that far yet - they will support *some* sort of networking08:23
axwok, I see08:24
axwso it'd work today, but not for long08:24
dimiternyeah08:24
axwwell then, whatever we do is going to be a stop-gap08:24
axwvoidspac_: ^^ maybe don't invest too much time if it's all going to change soon08:25
dimiternvoidspac_, axw, how about having a capability called ManageBootstrapNetworking bool ?08:25
dimiternit can be true for all but the local and manual provider08:26
voidspac_dimitern: that is then only used by local provider?08:26
axwdimitern: I don't know that that's right either. Do we really want to be managing networking on manually provisioned machines? They won't ever know about networks, right?08:26
voidspac_ManageNetworking that is always false on manual provider and false for local bootstrap machine08:27
dimiternaxw, they will at some point, at least units deployed on such machines08:27
dimiternvoidspac_, alas it can't be per-machine, it's an environ capability.. although I guess we can make it take a machine id and check..08:27
voidspac_dimitern: well, the environ is running on a specific machine08:29
voidspac_but if that's innappropriate for an environ capabilitiy then maybe that's not where this belongs08:30
dimiternvoidspac_, you know, I'd rather have this critical bug fixed now, and have a TODO + tech dept bug about improving the way we decide the value of the writeNetworkConfig flag for the networker08:32
voidspac_dimitern: well, the PR is ready to merge08:32
voidspac_dimitern: *but*08:32
voidspac_dimitern: axw says the original report was about manually provisioned machines, not just the local provider08:32
voidspac_and my PR does not address the manual provider at all08:32
voidspac_I can add a TODO for sure08:33
axwcan we just make it != "maas" for now, and TODO FIXME08:33
voidspac_axw: I will check if that works08:33
voidspac_axw: I have test failures though :-/08:33
voidspac_which I suspect are sporadic08:33
voidspac_but checking08:33
axw:(08:34
voidspac_I need more coffee for this08:34
dimiternaxw, type != "maas" is a really dirty hack :) but I can live with it for a short while, until we find a better way08:36
axwI agree, I didn't really want to go there08:37
axwseems better to fix now and do properly when networking evolves tho08:37
axwTheMue: it would appear you're the lucky OCR. can you please take a look at https://github.com/juju/juju/pull/483 and https://github.com/juju/juju/pull/484? these fix 2/3 critical bugs on 1.2108:42
TheMueBtw, reading the notes of Stéphane and Serge *before* installing nested containers helps .. *blush*08:42
voidspac_if you do a bootstrap (local provider), immediately followed by a deploy08:42
voidspac_you get:08:42
voidspac_ERROR upgrade in progress - Juju functionality is limited08:42
TheMueaxw: I’m OCR, oh!08:42
axwoops08:43
axwTheMue: no you're not08:43
axwsorry08:43
axwspreadsheet hadn't updated yet08:43
TheMueNo, Nate and Wayne. *phew*08:43
TheMueBut still can take a look.08:43
axwthanks :)08:43
TheMueaxw: 483 LGTM08:46
axwTheMue: thanks08:46
voidspac_axw: dimitern: latest revision uses the dirty hack08:54
voidspac_https://github.com/juju/juju/pull/47708:54
voidspac_axw: dimitern: only writes network config changes for maas08:54
TheMueaxw: 484 LGTM too with one note08:55
voidspac_works for local provider (tested "manually")08:55
axwTheMue: thanks08:56
TheMueaxw: yw08:57
axwvoidspac_: I'd prefer if we just disabled it altogether if != maas, but I'll defer to dimitern since I don't know enough about the networker09:00
voidspac_it would simplify this code a great deal to just only start the networker for maas09:02
dimiternaxw, voidspac_, please, let's not disable the networker just for that09:03
dimiternvoidspac_, LGTM09:04
voidspac_dimitern: might be late to standup by the way09:48
voidspac_only by ten minutes or so09:48
voidspac_dimitern: lp bug created09:48
voidspac_by the way09:48
voidspac_and linked in comment09:48
dimiternvoidspac_, no worries, cheers09:48
voidspac_even though this is a critical bug it doesn't seem to be one of the blocking bugs, so I'm not sure if this can be merged yet09:49
voidspac_we'll see09:49
rogpeppe1dimitern: are merges to juju-core still blocked on critical bugs?09:54
dimiternrogpeppe1, I'm not aware of that, if it's the case09:55
rogpeppe1dimitern: ah, ok. i still see two critical bugs open, and i thought that all merges into juju-core were blocked if that was the case, unless they directly addressed those issues09:56
rogpeppe1dimitern: is that not the case?09:56
rogpeppe1dimitern: (i've had a branch sitting for weeks waiting for things to be unblocked)09:56
dimiternrogpeppe1, one of the critical bugs has an approved fix pending merging, i need to see about the other one09:56
rogpeppe1dimitern: i guess i'll try to merge again then09:57
dimiternrogpeppe1, sgtm09:59
TheMueaaaaah, after two failed approaches my nested containers are now running (ok, currently only, but the way how to do it has been important)10:20
TheMuehehe, running the mac with a test trusty in a vm running a trusty lxc container running two trusty containers10:26
rogpeppe1dimitern: hmm, looks like merges *are* still blocked: http://juju-ci.vapour.ws:8080/job/github-merge-juju/236/console10:26
dimiternrogpeppe1, that's michael's fix - we'll sort it out on the standup shortly10:28
rogpeppe1dimitern: cool. i'll keep my fingers crossed. could you ping me when merges are finally unblocked, please?10:28
dimiternrogpeppe1, sure thing10:29
rogpeppe1dimitern: ta!10:29
=== jamespag` is now known as jamespage
perrito666axw: hey thanks for the patch10:52
perrito666axw: the other bug seems to have been fixed after your other patch was reverted10:53
perrito666but I was awaiting confirmation from sin10:53
perrito666zui10:53
dimiternvoidspace, are you back?11:03
dimiternmgz, ping11:06
voidspacedimitern: yes, gimme a second11:11
voidspacedimitern: TheMue: I guess I missed standup, sorry11:15
natefinchpeople keep inviting me to meetings in Nuremberf and not actually giving me a way to participate :/11:15
natefinchs/Nuremberf/Nuremberg/11:16
dimiternvoidspace, np, we can have a call or chat here if you like11:16
voidspacedimitern: chat here is fine11:16
voidspacedimitern: I guess I need something new, other than "generally explore ipv6"11:17
voidspacedimitern: my PR is blocked, even though it fixes a critical bug11:17
voidspaceI guess it doesn't fix a critical bug on the right branch :-)11:17
voidspacedimitern: I still have an outstanding task to close the database port as an upgrade step, so I can revert to that11:18
dimiternvoidspace, btw I had a couple of suggestions to your PR - did you see them?11:21
voidspacedimitern: yes, I addressed them11:22
voidspacedimitern: create LP bug and link in TODO, get rid of loop11:22
dimiternvoidspace, right, cheers11:22
voidspacedimitern: and fix a comment11:22
dimiternvoidspace, it seems the bot blocked it because it has conflicting "fixes-###" comments11:23
dimiternvoidspace, I've never seen this before, might be a new thing11:23
voidspacedimitern: that's the standard blocked message isn't it?11:23
voidspace Does not match ['fixes-1350983', 'fixes-1353443']11:23
voidspaceso, only a fix for issue 1350983 or 1353443 will be allowed11:24
voidspaceand mine fixes 134963511:24
voidspacedimitern: see the same message here https://github.com/juju/juju/pull/44911:24
voidspacewell, not the same message precisely but the same format11:25
dimiternright11:25
dimiternvoidspace, we need some guys with strong bot-fu :) mgz perhaps, others?11:25
dimiternvoidspace, we need this fix to land, as rogpeppe1 is blocked because of that11:27
voidspacedimitern: but trunk is blocked on those other issues11:27
dimiternvoidspace, you mean bug 1350983 ?11:27
dimiternmup, bug 135098311:28
voidspacedimitern: yep and 135344311:28
mupdimitern: Bug #1350983: Cannot bootstrap on azure: cannot create log collection <azure-provider> <bootstrap> <ci> <regression> <juju-core:In Progress by hduran-8> <https://launchpad.net/bugs/1350983>11:28
voidspaceaccording to the message11:28
voidspacemup bug 135344311:28
dimiternperrito666, hey, any update on ^^ ?11:28
voidspacemup, bug 135344311:28
mupvoidspace: Bug #1353443: Install hook error due to modprobe 8021q failure <ci> <local-provider> <networker> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1353443>11:28
perrito666dimitern: sinzui was going to make a few runs on CI but as of yesterday It seemd to be fixed, let me mark fix committed11:29
perrito666I tested it a LOT of times without a failure11:29
dimiternvoidspace, I commented on that ^ bug earlier; the fix is not the same as for the networker bug screwing the local provider networking11:29
dimiternperrito666, but has it landed on trunk?11:29
perrito666dimitern: yes11:30
voidspacedimitern: disabling the networker except for maas would fix it though....11:31
perrito666ow fff is failing again11:31
voidspacedimitern: does the networker do anything useful right now if you're not using maas?11:32
voidspaceperrito666: fff?11:32
perrito666voidspace: I try not to say profanities on work channels11:32
dimiternvoidspace, :) well, not really11:32
dimiternvoidspace, we'll still have issues with lxc containers in maas11:32
perrito666voidspace: if you where here you could have heard that pronounced out loud11:33
voidspacedimitern: right11:33
voidspaceperrito666: oh :-D11:33
voidspaceperrito666: I thought fff was the thing that was failing and wondered what it was11:33
dimiternvoidspace, that's why I think the fix should involve making the networker aware whether it's running in an LXC container or not, and not try to modprobe anything11:33
dimiternvoidspace, it does enable/disable NICs (or it should at least)11:34
voidspacedimitern: is that done in Execute ?11:36
voidspacedimitern: because I disable that too11:36
perrito666dimitern: oh it is failing with timeout io which is fixed by the next merge to land in CI11:37
dimiternvoidspace, ah11:38
dimiternvoidspace, i'll have to pull your branch again and do some more testing on my maas11:38
voidspacedimitern: it's not disabled for maas11:39
voidspacedimitern: it is for the other providers11:39
dimiternvoidspace, yes, but frankly I haven't tested the networker on maas myself so far :/11:40
voidspaceright11:40
dimitern(i.e. it's main job about managing interfaces)11:40
dimiternits11:40
dimiternok, brb for a while11:41
* dimitern lunches11:41
menn0voidspace: you know how to make your PR merge right?11:52
menn0voidspace: you need a comment of "__fixes-1349635__" and then also "$$whatever$$" in the same or another comment11:54
menn0$$fixes-1349635$$ won't cut it11:54
menn0I suspect "$$__fixes-1349635__$$" might work as a 2-in-1 though :)11:54
menn0#134963511:56
menn0(that was me testing mup)11:56
menn0ANYWAY... bed time!11:56
voidspacemgz: are you tinkering?12:28
mgzvoidspace: not tinkering, just needed to apply a hammer to get your change landing12:34
wwitzel3natefinch: so if we rotate purely on size, rsyslog can do it. But it has no concept of a daily. Do you think that is acceptable? Or does it need to be a daily rotation?12:34
voidspacemgz: thanks12:34
katcowwitzel3: dropping in on this convo: size of log = what, daily = how. i always prefer the what if possible.12:45
katcoe.g.: a log could grow too large w/in a day, or not grow enough in a month12:45
mgzvoidspace: do you know if there's any hope of bug 1353443 being got to today?12:45
mgzit's currently unassigned, but blocks master and you and dimitern seem to know what's up with it12:46
wwitzel3katco: I agree, the open bug is about the size, but I think we did log ration for units as a daily rotation, so having a different rotation scheme for the all-machines might be weird12:47
katcowwitzel3: yeah that would be confusing as a user12:48
wwitzel3katco: though if it was clearly documented, that might be ok12:52
katcowwitzel3: docs? who reads the friendly docs? :)12:54
natefinchwwitzel3, katco: size.   Daily rotation is useless.   You run the risk of rotating an empty log, or filling up the disk when you get 10 gigs of logs in a really busy couple hours.12:59
natefinchwwitzel3, katco: I went through that with lumberjack, at first I supported rotation by time, but then I realized that was just a bad idea13:00
natefinchwwitzel3, katco: the code I wrote for rotating the unit and machine logs just rotates based on size13:00
katconatefinch: hey i saw a js logging package earlier this morning: sherlog. :p13:00
natefinchkatco: nice13:00
voidspacemgz: I don't know13:15
voidspacemgz: not by me I'm afraid as I have to finish a bit early, off up a mountain later13:15
voidspacemgz: and I'm not sure what the best fix is - "not modprobe inside an lxc container" is most of the answer, but the right way for the networker to know whether or not it is contained is trickier13:16
voidspaceand dimitern should probably answer that13:16
dimiternvoidspace, we can tell whether we're in a lxc container or not easily from the agent config - machine tag will be something like machine-0-lxc-0 instead of machine-013:18
dimiternvoidspace, we shouldn't disable modprobe for kvm containers though, only for lxc13:18
mgzdimitern: I think this is the only remaining issue blocking landing13:18
voidspacedimitern: so, "if strings.Contains(agent.Tag(), "lxc")...13:18
voidspaceit's pretty horrible13:19
dimiternvoidspace, no, there's a names.ParseTag13:20
voidspacedimitern: do you think that is the right fix, protect modprobe with a check for lxc by parsing the tag?13:23
dimiternvoidspace, I think it's the right fix to disable modprobe altogether for machine agents running in lxc containers13:24
dimiternvoidspace, whether I think parsing the tag to get the container type is good enough - not really :)13:25
voidspaceright13:25
voidspacethat seems yucky13:25
dimiternvoidspace, we should have a way to tell what's the machine13:25
dimiternvoidspace, but nevertheless having a common way to tell if a machine is a container and what type is useful, and should be in state and the api13:28
voidspacein the api?13:29
voidspacea machine agent shouldn't have to make an external call to find out whether it's running in a container or not13:29
voidspaceor maybe it should, if that lives in the state13:29
voidspaceseems like the agent should know though13:29
perrito666natefinch: lemme know if we do the 1:1 so I actually get onto the call13:30
perrito666aghhh so close13:32
natefinchprein a minute13:32
natefinchperrito666:  in a minute13:32
dimiternvoidspace, by the api i meant "extend the agent api as needed so that info is available", no need to make a separate call (like with Life())13:38
natefinchdimitern, voidspace:  do you guys think you can get #1353443 fixed today?  I'm anxious to get master open to commits again13:46
natefinchmup is failing me  - https://bugs.launchpad.net/juju-core/+bug/135344313:47
voidspacenatefinch: dimitern: I'm leaving in 15minutes I'm afraid...13:47
dimiternnatefinch, voidspace, I think it just got merged, no?13:48
voidspacedimitern: no, the other one13:49
dimiternoh, bugger13:49
voidspaceThis one just got merged13:50
voidspacehttps://bugs.launchpad.net/juju-core/+bug/134963513:50
dimiternnatefinch, voidspace, I'll take it and try to do a quick fix13:50
dimitern #1353443 I mean13:50
voidspacedimitern: thanks13:50
natefinchbe back in a couple hours.... taking my wife to her midwife appointment.17:23
=== natefinch is now known as natefinch-afk
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
perrito666anyone alive here/23:30
perrito666?23:30

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!