/srv/irclogs.ubuntu.com/2015/10/14/#juju-dev.txt

perrito666davechen1y: the second one was intended to be a fix it and ship it but rb disagreed with me00:16
perrito666davechen1y: http://reviews.vapour.ws/r/2880/ the first issue is more a question of personal curiosity than an issue00:17
* thumper headdesks01:24
* thumper takes a breath01:24
thumperFFS01:24
anastasiamacthumper: ?01:25
thumperjust something that is SO broken01:25
* thumper submits a reversal01:25
anastasiamacthumper: is ur desk titanium? :D01:25
anastasiamacor better yet - foam?01:25
thumperalright git folks01:27
thumper...01:27
* thumper works it out01:27
anastasiamacthumper: git 42 ./...?01:27
thumperreviewer: http://reviews.vapour.ws/r/2886/01:34
thumperplz01:34
thumperdavechen1y: ^^?01:37
thumperwallyworld: ping01:43
wallyworldyo01:43
thumperwallyworld: I need a sanity check01:45
thumperquick call?01:45
wallyworldsure01:45
thumper1:101:45
mupBug #1505866 opened: TestRenderNetworkInterfacesScript* tests fail on windows <blocker> <ci> <regression> <test-failure> <windows> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1505866>01:50
perrito666thumper: this is just a revert?01:52
thumperperrito666: yes01:53
perrito666thumper: does it require juju-core fixes to go along?01:53
mupBug #1505866 changed: TestRenderNetworkInterfacesScript* tests fail on windows <blocker> <ci> <regression> <test-failure> <windows> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1505866>01:53
thumperperrito666: no01:53
perrito666thumper: then ship it01:53
perrito666your comment seems to be on par with the code for what I can see01:55
mupBug #1505866 opened: TestRenderNetworkInterfacesScript* tests fail on windows <blocker> <ci> <regression> <test-failure> <windows> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1505866>01:56
perrito666anyone else needs a review before I go to sleep and you are out of reviewer until its the morning wherever katco lives?02:07
perrito666k timeout02:13
perrito666bye02:13
thumperwallyworld: here's one http://reviews.vapour.ws/r/2887/03:16
wallyworldok03:16
thumperwallyworld: just pushing a branch based on what we talked about03:21
wallyworldok03:21
thumperwallyworld: http://reviews.vapour.ws/r/2889/03:24
wallyworldok03:25
thumperwallyworld: :-( the check means passing the gc.C object all the way through03:30
* thumper hacks03:30
wallyworldthumper: oh. was a suggestion, but i think worthwhile, if you agree03:31
thumperI'm just trying it03:31
thumperwallyworld: I think this is what you are after, good enough?03:33
wallyworldlooking03:33
thumperwallyworld: most the attempt strategies are in tests right now03:34
thumperand it makes the code less clear03:34
thumperIMO03:34
thumperalso03:34
wallyworldfastclock change looks ok03:34
thumperthe duplication of the unlock is so we have decent logging03:35
thumperno point saying we are retrying and then not03:35
wallyworldi realise that, but you log after each failed attemot03:35
thumperby having the unlock first, then retry loops, better information logging03:35
thumperbut then you have to check if you are the last one03:35
thumperand not log that one03:35
thumperI went for this as I thought it was more clear03:35
wallyworldok03:35
wallyworldfeel free to drop any03:36
thumperok, I'll try to be nice03:36
thumperwallyworld: in the end I did everything you wanted04:03
thumperjust like always04:03
thumper:)04:03
wallyworldthumper: aw, shucks04:04
wallyworldbut you didn't have to04:04
thumperis there anyone looking at the 1.25 block?04:04
* thumper shrugs04:04
thumperit's fine04:04
wallyworldeg the attempt strategy04:04
wallyworldand you made a good point abput the loop04:04
thumperAttempt has a HasNext04:04
thumperjust used that04:04
wallyworldok04:04
thumperinternally it is overkill for what is needed04:04
wallyworldwill be good to se ehow this improves it04:04
thumperbut as a UI, it is fine04:05
thumperugh04:26
thumperbug 150586604:27
mupBug #1505866: TestRenderNetworkInterfacesScript* tests fail on windows <blocker> <ci> <regression> <test-failure> <windows> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1505866>04:27
* thumper EOD05:00
thumperlaters05:00
mupBug #1505902 opened: MAAS 1.9: "storage-default-block-source" is not allowed in bootstrap <bootstrap> <ci> <maas> <juju-core:Triaged> <juju-core 1.26:Triaged> <https://launchpad.net/bugs/1505902>05:39
dimiternmorning all06:58
frobwaredimitern, hey - can we catch up after the sprint?07:47
frobwaredimitern, s/sprint/standup/07:47
dimiternfrobware, hey, yes - I've just accepted it08:05
dimiternfrobware, upgrading my hardware maas here to 1.9 to test voidspace's fix and mine08:06
voidspacedimitern: cool, I'm porting mine to master08:09
voidspacedimitern: you're doing 1.24 differently apparently?08:09
voidspacedimitern: mine's landed on 1.2508:09
voidspacedimitern: including a fix for interface alias mangling08:10
dimiternvoidspace, I had some comments yes - mostly about taking a simpler approach with the script08:10
dimiternvoidspace, that last one I couldn't quite get08:10
voidspacedimitern: you mean understand?08:10
dimiternvoidspace, yep08:10
voidspaceso maas creates aliases like "eth0:1"08:10
voidspacedimitern: and if the primary interface is "eth0" then some of the sed manipulations that change "eth0" to "juju-br0"08:11
dimiternvoidspace, ah I see, so the script needs to replace the whole thing incl. :1 with juju-br0908:11
dimiternjuju-br0 even08:11
voidspacewill change some references to "eth0:1" to "juju-br0:1"08:11
voidspaceyep08:11
voidspacewhich broke mongo08:11
dimiternvoidspace, hmm good catch though!08:11
voidspaceso I fixed that by improving the sed regex to check for "${PRIMARY_IFACE}\s*$08:12
dimiternvoidspace, so did you manage to reproduce the issue on 1.9 before your fix?08:12
voidspacedimitern: yep08:12
dimiternvoidspace, I'm not sure that thing with the aliases was part of the original issue - as you perhaps added 2 IPs to the eth0 NIC, and maas renders those as aliases08:12
voidspacedimitern: I didn't change the aliases - I left them intact. I changed the script to not touch them.08:13
voidspacedimitern: I don't think it was part of the original issue08:13
voidspacedimitern: but it showed up when testing - so I had to work out why it was happening08:13
voidspacesomehow I'd got an alias for a nic on one node08:13
frankbandimitern: you might be interested in http://reviews.vapour.ws/r/2892/ (support service constraints in bundle deployment). if you could take a look it would be great08:13
voidspacenot sure how08:13
dimiternfrankban, awesome! will have a look, thanks!08:14
frankbandimitern: ty08:14
voidspacedimitern: I don't know if you saw - my PR splits the part of the script that does text manipulation on /e/n/i into a separate script08:14
voidspacedimitern: so it can be unit tested08:15
* dimitern has a shiny new hw maas with 1.9.0alpha4 now :)08:15
voidspacedimitern: so adding new tests / changing the script is easy08:15
dimiternvoidspace, sounds good08:15
dimiternvoidspace, my alternative solution was to do something like sed -i s/${PRIMARY}/{{.Bridge}}/;/iface ${PRIMARY} inet/a\    bridge_ports: ${PRIMARY}" && append "iface ${PRIMARY} inet manual"08:16
dimiternfrankban, is guibundles branched off of master?08:19
voidspacedimitern: that looks pretty much equivalent yeah08:20
frankbandimitern: yes, last merged master was a blessd one from the week before seattle. will have to merge it again soon08:20
dimiternvoidspace, it's shorter but perhaps more dangerous, as it does replace all "eth0" with "juju-br0" indiscriminately08:21
voidspacedimitern: yep, it would need fixing to not mangle aliases08:21
dimiternfrankban, ok, I've LGTM-ed it - will you backport the same to 1.25?08:21
voidspacedimitern: you can run the tests I wrote against it08:21
dimiternvoidspace, yeah, I'll now test first your fix then mine08:22
frankbandimitern: I was going to ask about what should I do to include this work in 1.2608:22
frankbandimitern: so I'll do whatever required08:22
frankbandimitern: oh, and thanks for the review!08:23
dimiternfrankban, well, master (1.26) is not quite up-to-date with 1.25 as I've realized last week, there are a few fixes needed in provider/ec2, but I'll take care of that08:23
voidspacedimitern: I'm porting mine to master - if you have a simplification we could do that as a patch on top of what I've already done08:23
dimiternvoidspace, sounds good - we can have a simpler solution for 1.26 and one that works for 1.24 and 1.25 (even if they're different - shouldn't be a big deal)08:23
voidspacedimitern: if you go to an individual node view in maas 1.9 you can add an interface alias and check your fix works with that08:23
dimiternvoidspace, I'm doing just that now - added 2 aliases and set eth0 (the only NIC the NUC it has unfortunately) to static, 1 alias to auto assign, and 1 to static08:25
mgzvoidspace: bug 150594908:27
mupBug #1505949: TestRenderNetworkInterfacesScript* fail on windows <blocker> <ci> <maas-provider> <regression> <test-failure> <windows> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1505949>08:27
dimiternmgz, d'oh :) voidspace - it should be skipped in windows08:28
voidspacemgz: pthpthpthpth08:28
mgzit's easy to fix at least :)08:28
dimiternthat looked like an interface name with biosdevnames=1 :)08:28
voidspacemgz: dimitern: ok, on it08:29
dimiternvoidspace, cheers - please add a card for it etc.08:29
voidspacemgz: it's not in master yet - so I'll land a fix for 1.25 and make sure the fix is in the port to master08:29
voidspacedimitern: yep08:29
mgzvoidspace: also not in 1.24 it seems, a different version of the maas fix landed there?08:31
voidspacemgz: not yet08:31
voidspacemgz: shortly...08:31
mgzokay, thanks!08:31
mattywmgz, regarding http://reviews.vapour.ws/r/2883. I guess your comment is in response to my use of return err in the UnmarshalYaml function?08:33
mgzmattyw: yeah, as we're now returning err rather than false from the marshalling funcs, I just wondered if the errors are clearer with trace08:36
mattywmgz, I'll look again, but I think you're right, I think trace would be better, thanks for pointing it out08:37
mgzor something like `spaces, err = parseYamlStrings("spaces", val); if err != nil { return errors.Annotate("failed to parse spaces", err) }` type thing08:38
mgzdon't think we need to go overboard, but may be nice for the complex functions08:39
mattywmgz, it's useful in contraints becuase there are a few steps to that08:41
mattywmgz, but in version it's best to leave it as it is I think08:41
mgzmattyw: yes, that makes sense to me08:41
mattywmgz, just pushing those changes, do you want to take another look?08:42
voidspacemgz: dimitern: http://reviews.vapour.ws/r/2893/08:48
mgzmattyw: reshipit08:52
mattywmgz, it's going in, thanks very much08:53
mgzvoidspace: looks fine08:53
dimiternvoidspace, reviewed08:54
mgzdimitern: I'm not sure about your comment08:54
mgzreally the skipifbug is for stuff we're skipping until we fix the bug08:54
voidspacedimitern: it's not a windows bug08:54
mgzI don't intent to implement /bin/sh on windows08:54
dimiternvoidspace, mgz, I see - well, then ignore my comment :)08:55
voidspaceheh :-)08:55
dimiternfwereade, standup?09:02
mattywmgz, anything more I can do to help with yaml.v2 stuff?09:56
mgzmattyw: can you look at my charm branch change?09:56
mgzrog suggested expanding test coverage on it, so suggestions on that would be helpful09:57
mattywmgz, looking now, there seems to be some controversy about using the latest juju/utils, any idea what's going on there?09:59
mattywmgz, you seem to change it in that pr09:59
mgzmattyw: it's fine if we rebump to now latest09:59
mgzand it's not code that charm uses09:59
mattywmgz, any idea what that controversy is10:00
mattywmgz, also, any idea what kind of expanded test coverage rog had in mind, it seems ok to me, worrying that I'm missing something10:00
mgzthe see github.com/juju/utils/pull {159,162,163}10:01
mgzmattyw: I think he had in mind that the YAMLMarshal tests didn't tell anyone that storage wasn't being serialised10:02
mgzand don't say if the old redundant vars should be10:02
mgzhm, and this test just failed, did it do that for me last time... aha, no, it's after I rebased on latest10:04
mgzwell, that's a starting point10:04
mgzI'll bump utils and do this10:04
mgzooo, I'm silly10:05
mgzI did the rebase wrong, someone had added json attrs to Meta, not yaml ones10:06
mgz...three lots of these is going to be painful10:06
mgzmattyw: so, my basic issue is I'm not quite sure what the intended non-bson serialisation of Meta is exactly10:08
mattywmgz, we can get rid of the meta.SetYaml because yaml.v2 does it all for us right?...10:11
mattywmgz, but type Meta is missing the yaml tags, which I think would be useful10:11
mgzmattyw: right, it needs them10:11
mgzmattyw: I had added them but the rebase conflicted and I dropped my changes10:11
mattywmgz, ah ok10:11
mgzmattyw: but I don't quite understan https://github.com/juju/charm/pull/15810:12
mgzmattyw: do you know what is using json serialisation of Meta? there are no tests for that in meta_test.go10:13
mgzor was that just a mistake and yaml was intended?10:14
mgz(it's what I assumed on the conflict...)10:15
mattywmgz, hmm, I'm looking through master for changes to see if it's used there10:16
mattywmgz, it's also possible it's used in one of the feature branches?10:16
mattywmgz, or a mistake?10:16
mgzI think it's just a mistake that happened to work10:16
mgzbecause what mattered was the field rename back, and the serialisation tags are ignored... and GetYAML actually did the serialisation10:18
mgz...hm, comment in that branch makes it sound intentional10:19
mgzbut the pr discussion then makes no sense10:19
mgzmattyw: I'm just going to make the yaml serialisation do exactly what it did before10:22
mgzand let someone else deal with this confusion10:22
voidspacemgz: the windows bug was never committed to master10:22
voidspacemgz: can I delete juju-core from that issue10:22
voidspacedimitern: http://reviews.vapour.ws/r/2894/10:22
mattywmgz, I'd say that's a wise choice10:22
mgzvoidspace: I prefer if it's just Invalid and present, otherwise makes lp search even more confused10:23
voidspacemgz: the branch has landed on 1.25 (thanks for kicking the PR again) and I've marked it as fix committed10:23
voidspacemgz: ok10:23
voidspacemgz: I have a branch for master that incorporates the windows skipping10:23
voidspacedimitern: shall I backport mine to 1.24, or would you rather land yours there?10:24
dimiternvoidspace, do yours10:26
dimiternvoidspace, I'd like to simplify the master10:26
dimiterns/master/fix for master/10:27
mupBug #1505866 changed: TestRenderNetworkInterfacesScript* tests fail on windows <blocker> <ci> <regression> <test-failure> <windows> <juju-core:Invalid> <juju-core 1.25:Fix Committed by mfoord> <https://launchpad.net/bugs/1505866>10:28
voidspacedimitern: ok10:33
mgzmattyw: okay, this is terrifying10:34
mgzthree different serialisations with slightly different behaviours10:34
mgzlike, is it intentional or a tyop that Tags is json:"tag"10:35
mattywmgz, do we have tests in place for the three different behaviours?10:35
mgzI see nothing anywhere using json10:35
mupBug #1505866 opened: TestRenderNetworkInterfacesScript* tests fail on windows <blocker> <ci> <regression> <test-failure> <windows> <juju-core:Invalid> <juju-core 1.25:Fix Committed by mfoord> <https://launchpad.net/bugs/1505866>10:37
mgzmattyw: I run `:%s/ json:\([^ ]\+\)//g` and no tests fail10:38
mgz(seriously vim, I always forget which regexp chars need \)10:38
mattywmgz, so, luckily for me I'll be buggering off to lunch soon ;)10:39
mattywmgz, but10:39
mattywmgz, I'd try to break the behvaiour and see if any tests in charm or core fail10:40
mattywmgz, and then try to get at least simple test coverage for the 3 behaviours in the charm package10:40
mattywmgz, and then cover it in todo's and bug numbers to sort it out10:40
mattyw(if you want my opinion)10:40
mgzmattyw: I have fixed by branch, pushing now10:40
mgzI'll send a message to list about whether the json stuff was actually intended10:41
voidspacedimitern: so for 1.24 I'll just land it10:41
voidspacedimitern: for master I'll wait for your review with a suggested simpler approach10:41
dimiternvoidspace, sgtm, sorry - still in a call10:44
voidspacedimitern: np10:44
mupBug #1505866 changed: TestRenderNetworkInterfacesScript* tests fail on windows <blocker> <ci> <regression> <test-failure> <windows> <juju-core:Invalid> <juju-core 1.25:Fix Committed by mfoord> <https://launchpad.net/bugs/1505866>10:49
mattywmgz, taking a long lunch, I'll look at the charm pr when I get back10:53
rogpeppemgz: to get a "bug fix" PR past the bot, where should the "fixes-xxxx" thing go?10:59
rogpeppemgz: in the subject of the PR or the body?10:59
rogpeppemgz: and are the square brackets and quotes mandator?10:59
rogpeppey10:59
mgzfixes-xx in comment on github, no other characters required11:01
rogpeppemgz: ah, in a comment!11:07
rogpeppemgz: i tried subject and in the body in 3 forms!11:08
mgzrogpeppe: unrelated, I would like to land https://github.com/juju/charm/pull/164 even though the serialisation is insane, and fix the test coverage/intetions in a follow up. the v2 changes to yaml have the exact behaviour as before, it's just everything else is nuts11:08
mgzrogpeppe: it should probably check the body of the commit for bug mentions too, it's nice to have them there anyway11:08
rogpeppemgz: i'd really like it if you added some serialization tests in a previous branch (without mgo.v2) then we can see how the behaviour changes11:10
rogpeppemgz: otherwise we have no way of knowing what it has changed11:10
mgzrogpeppe: so, what I'm changing (the yaml) is covered by testing11:12
mgzrogpeppe: what's not covered (the new stuff, storage etc) I've now omitted from serialisation, which is what the codew was doing before11:12
mgzand thelack of tests of any json serialisation is another thing all together11:13
mgzrogpeppe: so, what I anticipate, is a follow branch that adds Sotrage and PayloadClass and testing for those11:14
rogpeppemgz:  it would be nice to add some tests that have some omitted storage serialisation11:15
mgzrogpeppe: and another folloup that either deletes the json or actually tests it11:15
rogpeppemgz: so that it's easy to see that the followup fixes that11:15
rogpeppemgz: i don't think you can delete the json.11:15
mgzokay, will throw one in for that11:15
rogpeppemgz: thanks11:15
rogpeppemgz: at least one API already serialises the charm metadata as JSON11:16
mgzwell, in the last 16 days it changed from serialising Tags as "tag" rather than "tags"11:19
mgzrogpeppe: I give up, just going to have to fix this ;_;11:22
rogpeppeoh really? that's bad.11:22
mgzI prefer when touching code doesn't mean you have to sort out everyone before you's bugs11:22
rogpeppemgz: me too11:22
dimiternvoidspace, I'm having trouble with your fix for 1.2512:05
dimiternvoidspace, here's what /e/n/i looks like after the juju-br0 script have run: http://paste.ubuntu.com/12780287/12:06
dimiternvoidspace, here's how it looked like when deploying the node via MAAS (no juju involved): http://paste.ubuntu.com/12780294/12:07
dimiternvoidspace, notice the aliases are not handled ok and there's also no lo device12:08
dimiternvoidspace, sorry, just to be sure I've deployed another node from maas, configured the same way and lo is missing, but the rest is as expected: http://paste.ubuntu.com/12780344/12:17
mgzvoidspace: so I have maybe-bad news12:24
perrito666man we really need to find a prettier way to include bash into our code12:25
mgzvoidspace: the networking for lxc on our wily slave seems to be screwed, not sure why yet12:25
mgzvoidspace: but could be a leak from running local-deploy on that machine with the 1.24 version of the maas networking change12:26
mgzor manual deploy12:27
mgz1.25 did not have this problem12:28
mgzvoidspace: is it possible our real /etc/network/interfaces got stomped?12:30
dimiternmgz, what do you see?12:36
dimiternmgz, I think voidspace's fix does not do the right thing with /e/n/i12:36
mgzjust no interfaces other than loopback visible to a non-juju managed lxc container12:36
mgzand whoops, I think I just borked networking to the box entirely when poking things ;_;12:37
jammgz: ouch. borking networking is definitely something that hurts, as you use it to fix the thing12:37
frobwaredimitern, voidspace: I also see the lack of loopback12:38
dimiternmgz, hmm that sounds like an issue with /var/lib/lxc/<container>/config12:38
dimiternfrobware, yeah, I can confirm this on both vivid and trusty, but this is how maas (curtin?) renders /e/n/i12:38
frobwaredimitern, you mentioned this morning about cloud-init not getting an interface with just a deploy from MAAS... I think?12:40
dimiternfrobware, on one of the machines, yes - which has a single eth0 configured in maas to DHCP12:41
frobwaredimitern, so I think I see the same. eth0 is static, with static aliases for eth0:1 and eth0:212:41
frobwaredimitern, cloud-init eventually completes post its 120s timeout12:41
mupBug #1506044 opened: juju.worker.diskmanager goes into ERROR loop inside a container <logging> <storage> <juju-core:Triaged> <https://launchpad.net/bugs/1506044>12:43
dimiternfrobware, and no lo to defined at all?12:44
frobwaredimitern, and although there is no 'auto lo - iface lo inet loopback' entry rebooting the machine I do see the loopback device configured.12:44
dimiternfrobware, ok, so then the lack of loopback perhaps is not an issue?12:44
frobwaredimitern, I can certainly `telnet 127.0.0.1 22' and it connects so there's something bound and listening...12:46
dimiternfrobware, right12:52
dimiternfrobware, I'm experimenting with the ways to deal with juju-br0 where there are aliases12:53
frobwaredimitern, I'm just wondering if the whole thing could be simpler.12:53
frobwaredimitern, the aliases seems to work OK, no?12:53
dimiternfrobware, I managed to get both s/eth0/juju-br0/ + add iface eth0 inet manual and bridge_ports eth0 to juju-br0's config; AND just replacing the "eth0" -> "juju-br0", leaving "eth0:0" and "eth0:1" intact12:54
dimiternfrobware, the only issue is in the second case I end up having duplicate routes: 192.168.1.0/24 dev eth0 and juju-br012:54
dimiternfrobware, voidspace, ok, I'm convinced now the 1.9 fix is not working for me, I'm going back to my original simpler fix and tweaking it to make it work12:56
frobwaredimitern, there's also the possibility of introducing 'ip link add name juju-br0 type bridge'12:57
dimiternfrobware, however.. I've just realized we might be having a lot bigger issue here12:57
dimiternfrobware, yeah, I'll check this too12:57
dimiternfrobware, the bigger issue is simply, juju-br0 is *supposed* to get its address via DHCP12:58
dimiternfrobware, and hence the containers on it will do the same12:58
dimiternfrobware, when we have a statically configured eth0 (or juju-br0) we won't be able to just do dhcp on the container side12:58
dimiternfrobware, in fact this seems so serious to me that we need to have a chat with the maas team how to resolve this12:59
dimiternit won't just work12:59
dimiternwithout dhcp12:59
dimiternit might work ok if we had a solid story around addressable containers (with static IPs)13:00
frobwaredimitern, there's nothing preventing the containers getting DHCP13:00
frobwaredimitern, MAAS still runs DHCP, no?13:00
dimiternfrobware, I've experimented with a vivid vbox vm so far, but the case is the same more or less - single eth0 on the vm, configured as bridged to the host's eth0 (which is statically configured, but can also dhcp to the router and get an IP)13:01
frobwaredimitern, voidspace: so I think this line is broken in that script: "    sed -i "s/auto ${PRIMARY_IFACE}//" {{.Config}}"13:06
frobwaredimitern, voidspace: this is why you get ":1", ":2" entries13:06
dimiternfrobware, yeah13:07
frobwaredimitern, voidspace: this might be better expressed as s/auto ${PRIMARY_IFACE}[^:]//13:07
voidspacehmmm13:07
voidspacedimitern: frobware: just been on lunch, reading scrollback13:08
voidspacedoesn't sound good13:08
voidspacemgz: ouch13:14
voidspacemgz: I only touched maas networking not local13:15
jamdooferlad: dimitern: priorities call?13:16
dimiternjam, omw, sorry13:16
mgzvoidspace: it may not be related, but I made it harder to find out by borking the machine13:18
voidspacemgz: :-(13:19
voidspacefrobware: dimitern: so there's an additional missing "\s*$" in the unAuto function - this is what kills the aliases when you have dhcp13:23
voidspacedimitern: frobware: note that this is also technically a pre-existing problem - not a new problem with my patch13:23
voidspacelack of loopback is odd13:24
mattywmgz, done https://github.com/juju/charm/pull/16413:34
mgzmattyw: I assume we just want the latet version of yaml.v2 everywhere?13:36
alexisbvoidspace, thank you for getting the fix for 1494476 committed!13:41
mattywmgz, I guess so13:41
voidspacealexisb: no problem13:42
voidspacealexisb: there might be some more work to be done on it though - at least one scenario it doesn't work on, maybe two13:43
voidspacealexisb: to be fair these are really pre-existing problems that allowing maas 1.9 to work at all has uncovered13:43
alexisbvoidspace, can we please make sure to open bugs for the scenarios that do not work13:44
voidspacealexisb: ok13:44
voidspacealexisb: hoping to get them done today and not leave any known bugs13:44
alexisbvoidspace, that works too :)13:45
alexisbvoidspace, keep me updated13:46
voidspacealexisb: ok13:46
voidspacedimitern: this code is only used when we don't have addressable containers, right? so containers won't be getting an address via dhcp13:55
voidspacethat was my understanding.13:55
voidspaceah, maybe I'm misunderstanding13:56
dimiternvoidspace, yes13:59
dimiternvoidspace, but so far this hinged upon the primary nic getting it's ip via dhcp14:00
perrito666sinzui: can you tell me more about https://bugs.launchpad.net/juju-core/+bug/1403689 ?14:15
mupBug #1403689: Server should handle tools of unknown or unsupported series <tech-debt> <upgrade-juju> <upload-tools> <juju-core:Triaged> <juju-core 1.22:Triaged> <juju-core 1.24:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1403689>14:15
perrito666it seems like there was some discussion around it between thumper and you14:16
sinzuiperrito666: there are several cases where used cannot upgrade because their old server doesn't know about wily or windows or centos. Why should the server care if there are wily agents in the streams? It wants a precise or trusty agent and they are in the streams14:17
sinzuiperrito666: Tim suggested that the server should pull the agents without judging the series/os they are for.14:18
perrito666I tend to agree14:19
sinzuiperrito666: some users have synced agents to their local disk, deleted the wily and windows agents, then published private streams to complete an upgrade. The state server could have ignored them.14:19
perrito666why is that targetted to 1.22?14:19
perrito666ok I am taking it, ill ignore the 1.22 milestone for now14:20
sinzuiperrito666: the bug is old and 1.22 users are afffected14:20
sinzui+1 perrito66614:20
perrito666oh so this actually needs to be backported eventually ?14:20
perrito666sinzui:  do we have any of the failure reports associated?14:24
sinzuiperrito666: not from CI. I think the affected users were on precise or trusty 1.22.6/8 with stale distro-info14:26
voidspacefrobware: dimitern: so I don't see how the loopback is being removed14:43
voidspacefrobware: dimitern: do you have the /e/n/i before it gets modified?14:43
frobwarevoidspace, there's a PB far above ^^^ :)  http://paste.ubuntu.com/12780294/14:44
dimiternvoidspace, the loopback it not pre-rendered by curtin/maas14:44
voidspacefrobware: I saw that - I thought that was *after*14:45
voidspacedimitern: so maas doesn't render loopback sometimes *ouch*14:45
voidspacedimitern: that sounds like a maas bug14:45
frobwarevoidspace, I see lo in that PB ^^^14:46
voidspacefrobware: there are two PB14:46
voidspacemaybe three14:46
voidspacefrobware: oh, you did post the link14:46
dimiternvoidspace, indeed - I haven't seen it render /e/n/i with lo in it when there's per-node network config specifically set; however during deployment, if you quickly ssh in you'll see something like "auto lo...auto eth0 ...dhcp" (configured by cloud-init-dyn-network something)14:47
frobwareTheMue, moved our 1:1 for tomorrow - apologies for the short notice.14:52
voidspacefrobware: we don't remove loopback for that14:52
TheMuefrobware: no problem, feel free14:52
voidspacefrobware: it's only the alias issue which was fixed for static but not dhcp14:52
voidspacefrobware: so I think the missing loopback is maas fault not ours14:52
frobwarevoidspace, based on the script it's not clear how it is removed.14:54
frobwarevoidspace, but it did exist at some point. See: /etc/network/interfaces.old14:54
frobwarevoidspace, contents are here: http://pastebin.ubuntu.com/12781804/14:55
voidspacefrobware: when I run that input (the first pastebin here) through our script, loopback is not removed :-)14:56
voidspacefrobware: dimitern thinks that maas renders it without loopback and then adds it14:56
voidspacefrobware: so maybe there's a race condition14:56
voidspacesounds like we need to talk to the maas guys about it14:58
frobwarevoidspace, If I just deploy I do get lo.14:59
voidspacefrobware: I've  not seen it without15:00
voidspacefrobware: here's a fix for the DHCP with aliases issue15:09
frobwarevoidspace, so what's the plan here? The lo disappearing is odd. Fixing the alias thing I agree is new.15:09
voidspacehttp://reviews.vapour.ws/r/2896/15:09
frobwarevoidspace, heh - beat me to it...15:09
voidspacefrobware: I'm 99% certain *we're* not screwing loopback in this code15:10
voidspacefrobware: we *might* be overwriting MAAS as it adds it (a race condition because both maas/curtin and us are modifying /e/n/i)15:10
voidspacefrobware: if that's the case we either need to poll and wait for loopback to appear, or talk to the maas guys about a better fix15:11
frobwarevoidspace, it might be easier to do this substitution in perl using non-greedy matches.15:11
voidspacefrobware: so probably raise a bug for that problem15:11
voidspacefrobware: I think that regex is fine15:11
voidspacefrobware: and is perl preinstalled? cloudinit is executed before package installation I understand15:11
voidspaceso we can't depend on anything not in a base ubuntu install15:12
voidspacewe could use Python as that is in a base install15:12
voidspacebut dimitern wasn't keen on doing that...15:12
voidspaceand if we're going to not use bash I'd rather use Python :-)15:12
voidspacepretty sure it has non greedy matches too15:12
frobwarevoidspace, so here's a thing... can we temporarily test with writing /e/n/i to some other place and do a few runs to see if we somehow(??) remove lo?15:12
voidspacefrobware: well - we have a test harness that does that15:13
voidspacefrobware: you can give it whatever input you want15:13
frobwarevoidspace, I was more interested in the dynamic nature then the pre-canned test input, but sure...15:13
voidspacefrobware: well, the only bit that's different is the code that sets PRIMARY_IFACE15:14
voidspacebut even if that turns out empty I can't see any way that code could remove the loopback entries15:14
frobwarevoidspace, agreed.15:14
frobwarevoidspace, for 99% of the time. :)15:14
voidspacewell, running the same script multiple times on the same input won't make any difference - the part that modifies /e/n/i is deterministic15:15
voidspaceif there was a bug we'd need to determine the right input to feed it15:15
voidspacefrobware: *grrr*15:16
voidspacefrobware: you sure you want to work on the networking team?15:16
voidspacefrobware: :-)15:16
frobwarevoidspace, OS bugs are harder. :)15:17
voidspaceheh15:17
frobwarevoidspace, invariably there's no actual machine to debug...15:17
frobwarevoidspace, dimitern: see recent conversation on #maas15:19
frobwarevoidspace, we will always get lo whether it's there or not15:20
voidspaceah, I can join #maas - won't be able to see past conversation15:20
voidspacefrobware: dimitern left15:20
voidspaceI've joined #maas15:20
wwitzel3ericsnow: pig15:21
wwitzel3lol15:21
wwitzel3ericsnow: ping15:21
voidspacewwitzel3: how rude...15:21
wwitzel3;)15:21
ericsnowwwitzel3: hey15:21
voidspacewwitzel3: ericsnow may not be the prettiest member of juju but that's plain rude15:21
frobwarevoidspace: http://pastebin.ubuntu.com/12782022/15:21
ericsnowlol15:22
voidspacefrobware: thanks, reading15:22
voidspacefrobware: ah15:22
voidspacefrobware: so if it's not there it's not a problem15:22
wwitzel3ericsnow: hey, so the existing SetStatus stuff actually maps pretty well to what we want, I'm just going to gut the PluginStatus / StateStatus / CombinedStatus stuff and pass in a string.15:22
voidspacefrobware: so we can ignore that issue?15:22
wwitzel3ericsnow: my question is, in the list command, what status are you showing in that column?15:22
frobwarevoidspace, yep. maybe chasing ghosts here.15:22
voidspacewell - I've put up a PR for 1.25 fixing dhcp with aliases15:23
voidspaceI'll backport to 1.24 and roll into the branch for master which is still awaiting a review from dimitern I believe15:23
wwitzel3ericsnow: is it the workload.Details.Status or workload.Status? .. it doesn't really matter since I'm updating both items in the doc15:23
wwitzel3ericsnow: but I'm curious which the list command is using (I guess I could go look)15:23
voidspacefrobware: perrito666 has approved the 1.25 PR so I'll crack on with that15:24
voidspacefrobware: oh wait, wrong PR - he *will* look at it, hasn't yet15:24
ericsnowwwitzel3: Payload.Status (which comes from Workload.Status.State)15:24
wwitzel3ericsnow: ok, perfect15:24
frobwarevoidspace, maybe we should add the cat /e/n/i as we talked about yesterday. at least that way we would know what it is to start with.15:30
voidspacefrobware: ok15:37
mupBug #1506121 opened: cloud-images query format deprecated, lxc should use simplestreams <juju-core:New> <https://launchpad.net/bugs/1506121>15:43
mupBug #1506121 changed: cloud-images query format deprecated, lxc should use simplestreams <juju-core:New> <https://launchpad.net/bugs/1506121>15:46
voidspacefrobware: doing that, including it in this PR15:47
voidspacefrobware: but it will require manual testing15:47
mupBug #1506121 opened: cloud-images query format deprecated, lxc should use simplestreams <juju-core:New> <https://launchpad.net/bugs/1506121>15:52
voidspacefrobware: that's pushed here if you want to take a look: http://reviews.vapour.ws/r/2896/15:56
voidspacefrobware: I'm just trying it out15:58
frobwarevoidspace, ack15:58
voidspacefrobware: logging with cat seems to work fine16:05
voidspacefrobware: I already have a +1 on the branch so I'm landing it16:06
katcoericsnow: natefinch: wwitzel3: http://reviews.vapour.ws/r/2898/16:09
frobwarevoidspace, here's some sample output from my quick test: http://pastebin.ubuntu.com/12782441/16:10
natefinchkatco: looking16:10
ericsnowkatco: lgtm16:11
katcoericsnow: ty16:11
voidspacefrobware: looks good to me16:12
natefinchkatco: Ditto to mr speedy up there16:12
katconatefinch: ty16:12
frobwarevoidspace, I'm heading out but seems all OK to me.16:15
voidspacefrobware: cool16:16
voidspacefrobware: see you later16:16
rogpeppemgz: any possibility we could get CI running on the chicago-cubs branch soonish?16:33
rogpeppemgz: the bug has been fixed now (or *should* have been)16:33
rogpeppesinzui: ^16:33
mgzrogpeppe: yup, will hopefully happen by tomorrow16:34
rogpeppemgz: thanks16:34
mgzwe have lots of people doing work, and I slowed things down by booming the wilys-lave16:39
rogpeppemgz: when can we remove the critical status of the bug? will that happen automatically if it gets blessed?16:39
rogpeppemgz: i'm concerned that it might take a week before we can land anything16:39
alexisbwwitzel3, ping17:16
wwitzel3alexisb: pong17:18
alexisbheya wwitzel3, I was just curious if you had a build of the lxd provider branch I could pull down and play with17:18
wwitzel3alexisb: https://github.com/wwitzel3/juju/tree/skullcrusher has lxd and the deploy branches merged in to it right now17:20
wwitzel3alexisb: ericsnow might have a more up-to-date one than that .. that is the same one from the sprint.17:22
alexisbthank you wwitzel317:22
ericsnowalexisb: try the lxd-provider feature branch of github.com/juju/juju17:23
katcowwitzel3: hey the link from your email to docs isn't working18:16
mupBug #1505902 changed: MAAS 1.9: "storage-default-block-source" is not allowed in bootstrap <bootstrap> <ci> <maas> <juju-core:Invalid> <juju-core 1.26:Invalid> <https://launchpad.net/bugs/1505902>18:41
katcowwitzel3: looking at your pr too... why is it so large? seems like there's a lot of registration code in there that should have already existed in the feature branch already?18:41
natefinchkatco: looks like it includes all of eric's stuff, too18:59
natefinchkatco: like the list-payloads stuff19:00
katconatefinch: still, much of that registration stuff should have already been in the feature branch19:07
natefinchkatco:  we hadn't implemented the CLI commands yet, so there wasn't the CLI command registration code19:11
=== wesleyma` is now known as wesleymason
alexisbericsnow, does your lxd branch have bundle support?20:44
ericsnowalexisb: what do you mean "bundle"?  charm bundles?20:45
ericsnowalexisb: if it's something extra then it probably doesn't have it :)20:45
alexisb:) ok20:46
alexisbnws :)20:46
alexisbericsnow, just fyi, the bundle support I am referring to his the "guibundle" branch that adds support for deploying bundles in core20:47
ericsnowalexisb: not included then20:48
wwitzel3katco: I had merged eric's branch in to test the charm with both commands, but forgot to backout the merge when I pushed up a fix22:02
wwitzel3katco: I resolved it, it is back to normal22:02
katcowwitzel3: k22:03
mupBug #1506225 opened: Failed bootstrap does not clean up failed environment <juju-core:New> <https://launchpad.net/bugs/1506225>22:29
mupBug #1506225 changed: Failed bootstrap does not clean up failed environment <juju-core:New> <https://launchpad.net/bugs/1506225>22:32
mupBug #1506225 opened: Failed bootstrap does not clean up failed environment <juju-core:New> <https://launchpad.net/bugs/1506225>22:47
mupBug #1506225 changed: Failed bootstrap does not clean up failed environment <juju-core:New> <https://launchpad.net/bugs/1506225>22:51
mupBug #1506225 opened: Failed bootstrap does not clean up failed environment <juju-core:New> <https://launchpad.net/bugs/1506225>22:54
wallyworldanastasiamac: standup?23:16
anastasiamacwallyworld: m stanidn :D23:17

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