[00:16] <perrito666> davechen1y: the second one was intended to be a fix it and ship it but rb disagreed with me
[00:17] <perrito666> davechen1y: http://reviews.vapour.ws/r/2880/ the first issue is more a question of personal curiosity than an issue
[01:24]  * thumper headdesks
[01:24]  * thumper takes a breath
[01:24] <thumper> FFS
[01:25] <anastasiamac> thumper: ?
[01:25] <thumper> just something that is SO broken
[01:25]  * thumper submits a reversal
[01:25] <anastasiamac> thumper: is ur desk titanium? :D
[01:25] <anastasiamac> or better yet - foam?
[01:27] <thumper> alright git folks
[01:27] <thumper> ...
[01:27]  * thumper works it out
[01:27] <anastasiamac> thumper: git 42 ./...?
[01:34] <thumper> reviewer: http://reviews.vapour.ws/r/2886/
[01:34] <thumper> plz
[01:37] <thumper> davechen1y: ^^?
[01:43] <thumper> wallyworld: ping
[01:43] <wallyworld> yo
[01:45] <thumper> wallyworld: I need a sanity check
[01:45] <thumper> quick call?
[01:45] <wallyworld> sure
[01:45] <thumper> 1:1
[01:50] <mup> Bug #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:52] <perrito666> thumper: this is just a revert?
[01:53] <thumper> perrito666: yes
[01:53] <perrito666> thumper: does it require juju-core fixes to go along?
[01:53] <mup> Bug #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] <thumper> perrito666: no
[01:53] <perrito666> thumper: then ship it
[01:55] <perrito666> your comment seems to be on par with the code for what I can see
[01:56] <mup> Bug #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>
[02:07] <perrito666> anyone else needs a review before I go to sleep and you are out of reviewer until its the morning wherever katco lives?
[02:13] <perrito666> k timeout
[02:13] <perrito666> bye
[03:16] <thumper> wallyworld: here's one http://reviews.vapour.ws/r/2887/
[03:16] <wallyworld> ok
[03:21] <thumper> wallyworld: just pushing a branch based on what we talked about
[03:21] <wallyworld> ok
[03:24] <thumper> wallyworld: http://reviews.vapour.ws/r/2889/
[03:25] <wallyworld> ok
[03:30] <thumper> wallyworld: :-( the check means passing the gc.C object all the way through
[03:30]  * thumper hacks
[03:31] <wallyworld> thumper: oh. was a suggestion, but i think worthwhile, if you agree
[03:31] <thumper> I'm just trying it
[03:33] <thumper> wallyworld: I think this is what you are after, good enough?
[03:33] <wallyworld> looking
[03:34] <thumper> wallyworld: most the attempt strategies are in tests right now
[03:34] <thumper> and it makes the code less clear
[03:34] <thumper> IMO
[03:34] <thumper> also
[03:34] <wallyworld> fastclock change looks ok
[03:35] <thumper> the duplication of the unlock is so we have decent logging
[03:35] <thumper> no point saying we are retrying and then not
[03:35] <wallyworld> i realise that, but you log after each failed attemot
[03:35] <thumper> by having the unlock first, then retry loops, better information logging
[03:35] <thumper> but then you have to check if you are the last one
[03:35] <thumper> and not log that one
[03:35] <thumper> I went for this as I thought it was more clear
[03:35] <wallyworld> ok
[03:36] <wallyworld> feel free to drop any
[03:36] <thumper> ok, I'll try to be nice
[04:03] <thumper> wallyworld: in the end I did everything you wanted
[04:03] <thumper> just like always
[04:03] <thumper> :)
[04:04] <wallyworld> thumper: aw, shucks
[04:04] <wallyworld> but you didn't have to
[04:04] <thumper> is there anyone looking at the 1.25 block?
[04:04]  * thumper shrugs
[04:04] <thumper> it's fine
[04:04] <wallyworld> eg the attempt strategy
[04:04] <wallyworld> and you made a good point abput the loop
[04:04] <thumper> Attempt has a HasNext
[04:04] <thumper> just used that
[04:04] <wallyworld> ok
[04:04] <thumper> internally it is overkill for what is needed
[04:04] <wallyworld> will be good to se ehow this improves it
[04:05] <thumper> but as a UI, it is fine
[04:26] <thumper> ugh
[04:27] <thumper> bug 1505866
[04:27] <mup> Bug #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>
[05:00]  * thumper EOD
[05:00] <thumper> laters
[05:39] <mup> Bug #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>
[06:58] <dimitern> morning all
[07:47] <frobware> dimitern, hey - can we catch up after the sprint?
[07:47] <frobware> dimitern, s/sprint/standup/
[08:05] <dimitern> frobware, hey, yes - I've just accepted it
[08:06] <dimitern> frobware, upgrading my hardware maas here to 1.9 to test voidspace's fix and mine
[08:09] <voidspace> dimitern: cool, I'm porting mine to master
[08:09] <voidspace> dimitern: you're doing 1.24 differently apparently?
[08:09] <voidspace> dimitern: mine's landed on 1.25
[08:10] <voidspace> dimitern: including a fix for interface alias mangling
[08:10] <dimitern> voidspace, I had some comments yes - mostly about taking a simpler approach with the script
[08:10] <dimitern> voidspace, that last one I couldn't quite get
[08:10] <voidspace> dimitern: you mean understand?
[08:10] <dimitern> voidspace, yep
[08:10] <voidspace> so maas creates aliases like "eth0:1"
[08:11] <voidspace> dimitern: and if the primary interface is "eth0" then some of the sed manipulations that change "eth0" to "juju-br0"
[08:11] <dimitern> voidspace, ah I see, so the script needs to replace the whole thing incl. :1 with juju-br09
[08:11] <dimitern> juju-br0 even
[08:11] <voidspace> will change some references to "eth0:1" to "juju-br0:1"
[08:11] <voidspace> yep
[08:11] <voidspace> which broke mongo
[08:11] <dimitern> voidspace, hmm good catch though!
[08:12] <voidspace> so I fixed that by improving the sed regex to check for "${PRIMARY_IFACE}\s*$
[08:12] <dimitern> voidspace, so did you manage to reproduce the issue on 1.9 before your fix?
[08:12] <voidspace> dimitern: yep
[08:12] <dimitern> voidspace, 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 aliases
[08:13] <voidspace> dimitern: I didn't change the aliases - I left them intact. I changed the script to not touch them.
[08:13] <voidspace> dimitern: I don't think it was part of the original issue
[08:13] <voidspace> dimitern: but it showed up when testing - so I had to work out why it was happening
[08:13] <voidspace> somehow I'd got an alias for a nic on one node
[08:13] <frankban> dimitern: 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 great
[08:13] <voidspace> not sure how
[08:14] <dimitern> frankban, awesome! will have a look, thanks!
[08:14] <frankban> dimitern: ty
[08:14] <voidspace> dimitern: 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 script
[08:15] <voidspace> dimitern: so it can be unit tested
[08:15]  * dimitern has a shiny new hw maas with 1.9.0alpha4 now :)
[08:15] <voidspace> dimitern: so adding new tests / changing the script is easy
[08:15] <dimitern> voidspace, sounds good
[08:16] <dimitern> voidspace, 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:19] <dimitern> frankban, is guibundles branched off of master?
[08:20] <voidspace> dimitern: that looks pretty much equivalent yeah
[08:20] <frankban> dimitern: yes, last merged master was a blessd one from the week before seattle. will have to merge it again soon
[08:21] <dimitern> voidspace, it's shorter but perhaps more dangerous, as it does replace all "eth0" with "juju-br0" indiscriminately
[08:21] <voidspace> dimitern: yep, it would need fixing to not mangle aliases
[08:21] <dimitern> frankban, ok, I've LGTM-ed it - will you backport the same to 1.25?
[08:21] <voidspace> dimitern: you can run the tests I wrote against it
[08:22] <dimitern> voidspace, yeah, I'll now test first your fix then mine
[08:22] <frankban> dimitern: I was going to ask about what should I do to include this work in 1.26
[08:22] <frankban> dimitern: so I'll do whatever required
[08:23] <frankban> dimitern: oh, and thanks for the review!
[08:23] <dimitern> frankban, 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 that
[08:23] <voidspace> dimitern: 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 done
[08:23] <dimitern> voidspace, 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] <voidspace> dimitern: if you go to an individual node view in maas 1.9 you can add an interface alias and check your fix works with that
[08:25] <dimitern> voidspace, 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 static
[08:27] <mgz> voidspace: bug 1505949
[08:27] <mup> Bug #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:28] <dimitern> mgz, d'oh :) voidspace - it should be skipped in windows
[08:28] <voidspace> mgz: pthpthpthpth
[08:28] <mgz> it's easy to fix at least :)
[08:28] <dimitern> that looked like an interface name with biosdevnames=1 :)
[08:29] <voidspace> mgz: dimitern: ok, on it
[08:29] <dimitern> voidspace, cheers - please add a card for it etc.
[08:29] <voidspace> mgz: 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 master
[08:29] <voidspace> dimitern: yep
[08:31] <mgz> voidspace: also not in 1.24 it seems, a different version of the maas fix landed there?
[08:31] <voidspace> mgz: not yet
[08:31] <voidspace> mgz: shortly...
[08:31] <mgz> okay, thanks!
[08:33] <mattyw> mgz, 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:36] <mgz> mattyw: yeah, as we're now returning err rather than false from the marshalling funcs, I just wondered if the errors are clearer with trace
[08:37] <mattyw> mgz, I'll look again, but I think you're right, I think trace would be better, thanks for pointing it out
[08:38] <mgz> or something like `spaces, err = parseYamlStrings("spaces", val); if err != nil { return errors.Annotate("failed to parse spaces", err) }` type thing
[08:39] <mgz> don't think we need to go overboard, but may be nice for the complex functions
[08:41] <mattyw> mgz, it's useful in contraints becuase there are a few steps to that
[08:41] <mattyw> mgz, but in version it's best to leave it as it is I think
[08:41] <mgz> mattyw: yes, that makes sense to me
[08:42] <mattyw> mgz, just pushing those changes, do you want to take another look?
[08:48] <voidspace> mgz: dimitern: http://reviews.vapour.ws/r/2893/
[08:52] <mgz> mattyw: reshipit
[08:53] <mattyw> mgz, it's going in, thanks very much
[08:53] <mgz> voidspace: looks fine
[08:54] <dimitern> voidspace, reviewed
[08:54] <mgz> dimitern: I'm not sure about your comment
[08:54] <mgz> really the skipifbug is for stuff we're skipping until we fix the bug
[08:54] <voidspace> dimitern: it's not a windows bug
[08:54] <mgz> I don't intent to implement /bin/sh on windows
[08:55] <dimitern> voidspace, mgz, I see - well, then ignore my comment :)
[08:55] <voidspace> heh :-)
[09:02] <dimitern> fwereade, standup?
[09:56] <mattyw> mgz, anything more I can do to help with yaml.v2 stuff?
[09:56] <mgz> mattyw: can you look at my charm branch change?
[09:57] <mgz> rog suggested expanding test coverage on it, so suggestions on that would be helpful
[09:59] <mattyw> mgz, looking now, there seems to be some controversy about using the latest juju/utils, any idea what's going on there?
[09:59] <mattyw> mgz, you seem to change it in that pr
[09:59] <mgz> mattyw: it's fine if we rebump to now latest
[09:59] <mgz> and it's not code that charm uses
[10:00] <mattyw> mgz, any idea what that controversy is
[10:00] <mattyw> mgz, also, any idea what kind of expanded test coverage rog had in mind, it seems ok to me, worrying that I'm missing something
[10:01] <mgz> the see github.com/juju/utils/pull {159,162,163}
[10:02] <mgz> mattyw: I think he had in mind that the YAMLMarshal tests didn't tell anyone that storage wasn't being serialised
[10:02] <mgz> and don't say if the old redundant vars should be
[10:04] <mgz> hm, and this test just failed, did it do that for me last time... aha, no, it's after I rebased on latest
[10:04] <mgz> well, that's a starting point
[10:04] <mgz> I'll bump utils and do this
[10:05] <mgz> ooo, I'm silly
[10:06] <mgz> I did the rebase wrong, someone had added json attrs to Meta, not yaml ones
[10:06] <mgz> ...three lots of these is going to be painful
[10:08] <mgz> mattyw: so, my basic issue is I'm not quite sure what the intended non-bson serialisation of Meta is exactly
[10:11] <mattyw> mgz, we can get rid of the meta.SetYaml because yaml.v2 does it all for us right?...
[10:11] <mattyw> mgz, but type Meta is missing the yaml tags, which I think would be useful
[10:11] <mgz> mattyw: right, it needs them
[10:11] <mgz> mattyw: I had added them but the rebase conflicted and I dropped my changes
[10:11] <mattyw> mgz, ah ok
[10:12] <mgz> mattyw: but I don't quite understan https://github.com/juju/charm/pull/158
[10:13] <mgz> mattyw: do you know what is using json serialisation of Meta? there are no tests for that in meta_test.go
[10:14] <mgz> or was that just a mistake and yaml was intended?
[10:15] <mgz> (it's what I assumed on the conflict...)
[10:16] <mattyw> mgz, hmm, I'm looking through master for changes to see if it's used there
[10:16] <mattyw> mgz, it's also possible it's used in one of the feature branches?
[10:16] <mattyw> mgz, or a mistake?
[10:16] <mgz> I think it's just a mistake that happened to work
[10:18] <mgz> because what mattered was the field rename back, and the serialisation tags are ignored... and GetYAML actually did the serialisation
[10:19] <mgz> ...hm, comment in that branch makes it sound intentional
[10:19] <mgz> but the pr discussion then makes no sense
[10:22] <mgz> mattyw: I'm just going to make the yaml serialisation do exactly what it did before
[10:22] <mgz> and let someone else deal with this confusion
[10:22] <voidspace> mgz: the windows bug was never committed to master
[10:22] <voidspace> mgz: can I delete juju-core from that issue
[10:22] <voidspace> dimitern: http://reviews.vapour.ws/r/2894/
[10:22] <mattyw> mgz, I'd say that's a wise choice
[10:23] <mgz> voidspace: I prefer if it's just Invalid and present, otherwise makes lp search even more confused
[10:23] <voidspace> mgz: the branch has landed on 1.25 (thanks for kicking the PR again) and I've marked it as fix committed
[10:23] <voidspace> mgz: ok
[10:23] <voidspace> mgz: I have a branch for master that incorporates the windows skipping
[10:24] <voidspace> dimitern: shall I backport mine to 1.24, or would you rather land yours there?
[10:26] <dimitern> voidspace, do yours
[10:26] <dimitern> voidspace, I'd like to simplify the master
[10:27] <dimitern> s/master/fix for master/
[10:28] <mup> Bug #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:33] <voidspace> dimitern: ok
[10:34] <mgz> mattyw: okay, this is terrifying
[10:34] <mgz> three different serialisations with slightly different behaviours
[10:35] <mgz> like, is it intentional or a tyop that Tags is json:"tag"
[10:35] <mattyw> mgz, do we have tests in place for the three different behaviours?
[10:35] <mgz> I see nothing anywhere using json
[10:37] <mup> Bug #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:38] <mgz> mattyw: I run `:%s/ json:\([^ ]\+\)//g` and no tests fail
[10:38] <mgz> (seriously vim, I always forget which regexp chars need \)
[10:39] <mattyw> mgz, so, luckily for me I'll be buggering off to lunch soon ;)
[10:39] <mattyw> mgz, but
[10:40] <mattyw> mgz, I'd try to break the behvaiour and see if any tests in charm or core fail
[10:40] <mattyw> mgz, and then try to get at least simple test coverage for the 3 behaviours in the charm package
[10:40] <mattyw> mgz, and then cover it in todo's and bug numbers to sort it out
[10:40] <mattyw> (if you want my opinion)
[10:40] <mgz> mattyw: I have fixed by branch, pushing now
[10:41] <mgz> I'll send a message to list about whether the json stuff was actually intended
[10:41] <voidspace> dimitern: so for 1.24 I'll just land it
[10:41] <voidspace> dimitern: for master I'll wait for your review with a suggested simpler approach
[10:44] <dimitern> voidspace, sgtm, sorry - still in a call
[10:44] <voidspace> dimitern: np
[10:49] <mup> Bug #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:53] <mattyw> mgz, taking a long lunch, I'll look at the charm pr when I get back
[10:59] <rogpeppe> mgz: to get a "bug fix" PR past the bot, where should the "fixes-xxxx" thing go?
[10:59] <rogpeppe> mgz: in the subject of the PR or the body?
[10:59] <rogpeppe> mgz: and are the square brackets and quotes mandator?
[10:59] <rogpeppe> y
[11:01] <mgz> fixes-xx in comment on github, no other characters required
[11:07] <rogpeppe> mgz: ah, in a comment!
[11:08] <rogpeppe> mgz: i tried subject and in the body in 3 forms!
[11:08] <mgz> rogpeppe: 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 nuts
[11:08] <mgz> rogpeppe: it should probably check the body of the commit for bug mentions too, it's nice to have them there anyway
[11:10] <rogpeppe> mgz: 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 changes
[11:10] <rogpeppe> mgz: otherwise we have no way of knowing what it has changed
[11:12] <mgz> rogpeppe: so, what I'm changing (the yaml) is covered by testing
[11:12] <mgz> rogpeppe: what's not covered (the new stuff, storage etc) I've now omitted from serialisation, which is what the codew was doing before
[11:13] <mgz> and thelack of tests of any json serialisation is another thing all together
[11:14] <mgz> rogpeppe: so, what I anticipate, is a follow branch that adds Sotrage and PayloadClass and testing for those
[11:15] <rogpeppe> mgz:  it would be nice to add some tests that have some omitted storage serialisation
[11:15] <mgz> rogpeppe: and another folloup that either deletes the json or actually tests it
[11:15] <rogpeppe> mgz: so that it's easy to see that the followup fixes that
[11:15] <rogpeppe> mgz: i don't think you can delete the json.
[11:15] <mgz> okay, will throw one in for that
[11:15] <rogpeppe> mgz: thanks
[11:16] <rogpeppe> mgz: at least one API already serialises the charm metadata as JSON
[11:19] <mgz> well, in the last 16 days it changed from serialising Tags as "tag" rather than "tags"
[11:22] <mgz> rogpeppe: I give up, just going to have to fix this ;_;
[11:22] <rogpeppe> oh really? that's bad.
[11:22] <mgz> I prefer when touching code doesn't mean you have to sort out everyone before you's bugs
[11:22] <rogpeppe> mgz: me too
[12:05] <dimitern> voidspace, I'm having trouble with your fix for 1.25
[12:06] <dimitern> voidspace, here's what /e/n/i looks like after the juju-br0 script have run: http://paste.ubuntu.com/12780287/
[12:07] <dimitern> voidspace, here's how it looked like when deploying the node via MAAS (no juju involved): http://paste.ubuntu.com/12780294/
[12:08] <dimitern> voidspace, notice the aliases are not handled ok and there's also no lo device
[12:17] <dimitern> voidspace, 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:24] <mgz> voidspace: so I have maybe-bad news
[12:25] <perrito666> man we really need to find a prettier way to include bash into our code
[12:25] <mgz> voidspace: the networking for lxc on our wily slave seems to be screwed, not sure why yet
[12:26] <mgz> voidspace: but could be a leak from running local-deploy on that machine with the 1.24 version of the maas networking change
[12:27] <mgz> or manual deploy
[12:28] <mgz> 1.25 did not have this problem
[12:30] <mgz> voidspace: is it possible our real /etc/network/interfaces got stomped?
[12:36] <dimitern> mgz, what do you see?
[12:36] <dimitern> mgz, I think voidspace's fix does not do the right thing with /e/n/i
[12:36] <mgz> just no interfaces other than loopback visible to a non-juju managed lxc container
[12:37] <mgz> and whoops, I think I just borked networking to the box entirely when poking things ;_;
[12:37] <jam> mgz: ouch. borking networking is definitely something that hurts, as you use it to fix the thing
[12:38] <frobware> dimitern, voidspace: I also see the lack of loopback
[12:38] <dimitern> mgz, hmm that sounds like an issue with /var/lib/lxc/<container>/config
[12:38] <dimitern> frobware, yeah, I can confirm this on both vivid and trusty, but this is how maas (curtin?) renders /e/n/i
[12:40] <frobware> dimitern, you mentioned this morning about cloud-init not getting an interface with just a deploy from MAAS... I think?
[12:41] <dimitern> frobware, on one of the machines, yes - which has a single eth0 configured in maas to DHCP
[12:41] <frobware> dimitern, so I think I see the same. eth0 is static, with static aliases for eth0:1 and eth0:2
[12:41] <frobware> dimitern, cloud-init eventually completes post its 120s timeout
[12:43] <mup> Bug #1506044 opened: juju.worker.diskmanager goes into ERROR loop inside a container <logging> <storage> <juju-core:Triaged> <https://launchpad.net/bugs/1506044>
[12:44] <dimitern> frobware, and no lo to defined at all?
[12:44] <frobware> dimitern, and although there is no 'auto lo - iface lo inet loopback' entry rebooting the machine I do see the loopback device configured.
[12:44] <dimitern> frobware, ok, so then the lack of loopback perhaps is not an issue?
[12:46] <frobware> dimitern, I can certainly `telnet 127.0.0.1 22' and it connects so there's something bound and listening...
[12:52] <dimitern> frobware, right
[12:53] <dimitern> frobware, I'm experimenting with the ways to deal with juju-br0 where there are aliases
[12:53] <frobware> dimitern, I'm just wondering if the whole thing could be simpler.
[12:53] <frobware> dimitern, the aliases seems to work OK, no?
[12:54] <dimitern> frobware, 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" intact
[12:54] <dimitern> frobware, the only issue is in the second case I end up having duplicate routes: 192.168.1.0/24 dev eth0 and juju-br0
[12:56] <dimitern> frobware, 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 work
[12:57] <frobware> dimitern, there's also the possibility of introducing 'ip link add name juju-br0 type bridge'
[12:57] <dimitern> frobware, however.. I've just realized we might be having a lot bigger issue here
[12:57] <dimitern> frobware, yeah, I'll check this too
[12:58] <dimitern> frobware, the bigger issue is simply, juju-br0 is *supposed* to get its address via DHCP
[12:58] <dimitern> frobware, and hence the containers on it will do the same
[12:58] <dimitern> frobware, when we have a statically configured eth0 (or juju-br0) we won't be able to just do dhcp on the container side
[12:59] <dimitern> frobware, in fact this seems so serious to me that we need to have a chat with the maas team how to resolve this
[12:59] <dimitern> it won't just work
[12:59] <dimitern> without dhcp
[13:00] <dimitern> it might work ok if we had a solid story around addressable containers (with static IPs)
[13:00] <frobware> dimitern, there's nothing preventing the containers getting DHCP
[13:00] <frobware> dimitern, MAAS still runs DHCP, no?
[13:01] <dimitern> frobware, 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:06] <frobware> dimitern, voidspace: so I think this line is broken in that script: "    sed -i "s/auto ${PRIMARY_IFACE}//" {{.Config}}"
[13:06] <frobware> dimitern, voidspace: this is why you get ":1", ":2" entries
[13:07] <dimitern> frobware, yeah
[13:07] <frobware> dimitern, voidspace: this might be better expressed as s/auto ${PRIMARY_IFACE}[^:]//
[13:07] <voidspace> hmmm
[13:08] <voidspace> dimitern: frobware: just been on lunch, reading scrollback
[13:08] <voidspace> doesn't sound good
[13:14] <voidspace> mgz: ouch
[13:15] <voidspace> mgz: I only touched maas networking not local
[13:16] <jam> dooferlad: dimitern: priorities call?
[13:16] <dimitern> jam, omw, sorry
[13:18] <mgz> voidspace: it may not be related, but I made it harder to find out by borking the machine
[13:19] <voidspace> mgz: :-(
[13:23] <voidspace> frobware: dimitern: so there's an additional missing "\s*$" in the unAuto function - this is what kills the aliases when you have dhcp
[13:23] <voidspace> dimitern: frobware: note that this is also technically a pre-existing problem - not a new problem with my patch
[13:24] <voidspace> lack of loopback is odd
[13:34] <mattyw> mgz, done https://github.com/juju/charm/pull/164
[13:36] <mgz> mattyw: I assume we just want the latet version of yaml.v2 everywhere?
[13:41] <alexisb> voidspace, thank you for getting the fix for 1494476 committed!
[13:41] <mattyw> mgz, I guess so
[13:42] <voidspace> alexisb: no problem
[13:43] <voidspace> alexisb: there might be some more work to be done on it though - at least one scenario it doesn't work on, maybe two
[13:43] <voidspace> alexisb: to be fair these are really pre-existing problems that allowing maas 1.9 to work at all has uncovered
[13:44] <alexisb> voidspace, can we please make sure to open bugs for the scenarios that do not work
[13:44] <voidspace> alexisb: ok
[13:44] <voidspace> alexisb: hoping to get them done today and not leave any known bugs
[13:45] <alexisb> voidspace, that works too :)
[13:46] <alexisb> voidspace, keep me updated
[13:46] <voidspace> alexisb: ok
[13:55] <voidspace> dimitern: this code is only used when we don't have addressable containers, right? so containers won't be getting an address via dhcp
[13:55] <voidspace> that was my understanding.
[13:56] <voidspace> ah, maybe I'm misunderstanding
[13:59] <dimitern> voidspace, yes
[14:00] <dimitern> voidspace, but so far this hinged upon the primary nic getting it's ip via dhcp
[14:15] <perrito666> sinzui: can you tell me more about https://bugs.launchpad.net/juju-core/+bug/1403689 ?
[14:15] <mup> Bug #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:16] <perrito666> it seems like there was some discussion around it between thumper and you
[14:17] <sinzui> perrito666: 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 streams
[14:18] <sinzui> perrito666: Tim suggested that the server should pull the agents without judging the series/os they are for.
[14:19] <perrito666> I tend to agree
[14:19] <sinzui> perrito666: 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] <perrito666> why is that targetted to 1.22?
[14:20] <perrito666> ok I am taking it, ill ignore the 1.22 milestone for now
[14:20] <sinzui> perrito666: the bug is old and 1.22 users are afffected
[14:20] <sinzui> +1 perrito666
[14:20] <perrito666> oh so this actually needs to be backported eventually ?
[14:24] <perrito666> sinzui:  do we have any of the failure reports associated?
[14:26] <sinzui> perrito666: not from CI. I think the affected users were on precise or trusty 1.22.6/8 with stale distro-info
[14:43] <voidspace> frobware: dimitern: so I don't see how the loopback is being removed
[14:43] <voidspace> frobware: dimitern: do you have the /e/n/i before it gets modified?
[14:44] <frobware> voidspace, there's a PB far above ^^^ :)  http://paste.ubuntu.com/12780294/
[14:44] <dimitern> voidspace, the loopback it not pre-rendered by curtin/maas
[14:45] <voidspace> frobware: I saw that - I thought that was *after*
[14:45] <voidspace> dimitern: so maas doesn't render loopback sometimes *ouch*
[14:45] <voidspace> dimitern: that sounds like a maas bug
[14:46] <frobware> voidspace, I see lo in that PB ^^^
[14:46] <voidspace> frobware: there are two PB
[14:46] <voidspace> maybe three
[14:46] <voidspace> frobware: oh, you did post the link
[14:47] <dimitern> voidspace, 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:52] <frobware> TheMue, moved our 1:1 for tomorrow - apologies for the short notice.
[14:52] <voidspace> frobware: we don't remove loopback for that
[14:52] <TheMue> frobware: no problem, feel free
[14:52] <voidspace> frobware: it's only the alias issue which was fixed for static but not dhcp
[14:52] <voidspace> frobware: so I think the missing loopback is maas fault not ours
[14:54] <frobware> voidspace, based on the script it's not clear how it is removed.
[14:54] <frobware> voidspace, but it did exist at some point. See: /etc/network/interfaces.old
[14:55] <frobware> voidspace, contents are here: http://pastebin.ubuntu.com/12781804/
[14:56] <voidspace> frobware: when I run that input (the first pastebin here) through our script, loopback is not removed :-)
[14:56] <voidspace> frobware: dimitern thinks that maas renders it without loopback and then adds it
[14:56] <voidspace> frobware: so maybe there's a race condition
[14:58] <voidspace> sounds like we need to talk to the maas guys about it
[14:59] <frobware> voidspace, If I just deploy I do get lo.
[15:00] <voidspace> frobware: I've  not seen it without
[15:09] <voidspace> frobware: here's a fix for the DHCP with aliases issue
[15:09] <frobware> voidspace, so what's the plan here? The lo disappearing is odd. Fixing the alias thing I agree is new.
[15:09] <voidspace> http://reviews.vapour.ws/r/2896/
[15:09] <frobware> voidspace, heh - beat me to it...
[15:10] <voidspace> frobware: I'm 99% certain *we're* not screwing loopback in this code
[15:10] <voidspace> frobware: we *might* be overwriting MAAS as it adds it (a race condition because both maas/curtin and us are modifying /e/n/i)
[15:11] <voidspace> frobware: 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 fix
[15:11] <frobware> voidspace, it might be easier to do this substitution in perl using non-greedy matches.
[15:11] <voidspace> frobware: so probably raise a bug for that problem
[15:11] <voidspace> frobware: I think that regex is fine
[15:11] <voidspace> frobware: and is perl preinstalled? cloudinit is executed before package installation I understand
[15:12] <voidspace> so we can't depend on anything not in a base ubuntu install
[15:12] <voidspace> we could use Python as that is in a base install
[15:12] <voidspace> but dimitern wasn't keen on doing that...
[15:12] <voidspace> and if we're going to not use bash I'd rather use Python :-)
[15:12] <voidspace> pretty sure it has non greedy matches too
[15:12] <frobware> voidspace, 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:13] <voidspace> frobware: well - we have a test harness that does that
[15:13] <voidspace> frobware: you can give it whatever input you want
[15:13] <frobware> voidspace, I was more interested in the dynamic nature then the pre-canned test input, but sure...
[15:14] <voidspace> frobware: well, the only bit that's different is the code that sets PRIMARY_IFACE
[15:14] <voidspace> but even if that turns out empty I can't see any way that code could remove the loopback entries
[15:14] <frobware> voidspace, agreed.
[15:14] <frobware> voidspace, for 99% of the time. :)
[15:15] <voidspace> well, running the same script multiple times on the same input won't make any difference - the part that modifies /e/n/i is deterministic
[15:15] <voidspace> if there was a bug we'd need to determine the right input to feed it
[15:16] <voidspace> frobware: *grrr*
[15:16] <voidspace> frobware: you sure you want to work on the networking team?
[15:16] <voidspace> frobware: :-)
[15:17] <frobware> voidspace, OS bugs are harder. :)
[15:17] <voidspace> heh
[15:17] <frobware> voidspace, invariably there's no actual machine to debug...
[15:19] <frobware> voidspace, dimitern: see recent conversation on #maas
[15:20] <frobware> voidspace, we will always get lo whether it's there or not
[15:20] <voidspace> ah, I can join #maas - won't be able to see past conversation
[15:20] <voidspace> frobware: dimitern left
[15:20] <voidspace> I've joined #maas
[15:21] <wwitzel3> ericsnow: pig
[15:21] <wwitzel3> lol
[15:21] <wwitzel3> ericsnow: ping
[15:21] <voidspace> wwitzel3: how rude...
[15:21] <wwitzel3> ;)
[15:21] <ericsnow> wwitzel3: hey
[15:21] <voidspace> wwitzel3: ericsnow may not be the prettiest member of juju but that's plain rude
[15:21] <frobware> voidspace: http://pastebin.ubuntu.com/12782022/
[15:22] <ericsnow> lol
[15:22] <voidspace> frobware: thanks, reading
[15:22] <voidspace> frobware: ah
[15:22] <voidspace> frobware: so if it's not there it's not a problem
[15:22] <wwitzel3> ericsnow: 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] <voidspace> frobware: so we can ignore that issue?
[15:22] <wwitzel3> ericsnow: my question is, in the list command, what status are you showing in that column?
[15:22] <frobware> voidspace, yep. maybe chasing ghosts here.
[15:23] <voidspace> well - I've put up a PR for 1.25 fixing dhcp with aliases
[15:23] <voidspace> I'll backport to 1.24 and roll into the branch for master which is still awaiting a review from dimitern I believe
[15:23] <wwitzel3> ericsnow: is it the workload.Details.Status or workload.Status? .. it doesn't really matter since I'm updating both items in the doc
[15:23] <wwitzel3> ericsnow: but I'm curious which the list command is using (I guess I could go look)
[15:24] <voidspace> frobware: perrito666 has approved the 1.25 PR so I'll crack on with that
[15:24] <voidspace> frobware: oh wait, wrong PR - he *will* look at it, hasn't yet
[15:24] <ericsnow> wwitzel3: Payload.Status (which comes from Workload.Status.State)
[15:24] <wwitzel3> ericsnow: ok, perfect
[15:30] <frobware> voidspace, 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:37] <voidspace> frobware: ok
[15:43] <mup> Bug #1506121 opened: cloud-images query format deprecated, lxc should use simplestreams <juju-core:New> <https://launchpad.net/bugs/1506121>
[15:46] <mup> Bug #1506121 changed: cloud-images query format deprecated, lxc should use simplestreams <juju-core:New> <https://launchpad.net/bugs/1506121>
[15:47] <voidspace> frobware: doing that, including it in this PR
[15:47] <voidspace> frobware: but it will require manual testing
[15:52] <mup> Bug #1506121 opened: cloud-images query format deprecated, lxc should use simplestreams <juju-core:New> <https://launchpad.net/bugs/1506121>
[15:56] <voidspace> frobware: that's pushed here if you want to take a look: http://reviews.vapour.ws/r/2896/
[15:58] <voidspace> frobware: I'm just trying it out
[15:58] <frobware> voidspace, ack
[16:05] <voidspace> frobware: logging with cat seems to work fine
[16:06] <voidspace> frobware: I already have a +1 on the branch so I'm landing it
[16:09] <katco> ericsnow: natefinch: wwitzel3: http://reviews.vapour.ws/r/2898/
[16:10] <frobware> voidspace, here's some sample output from my quick test: http://pastebin.ubuntu.com/12782441/
[16:10] <natefinch> katco: looking
[16:11] <ericsnow> katco: lgtm
[16:11] <katco> ericsnow: ty
[16:12] <voidspace> frobware: looks good to me
[16:12] <natefinch> katco: Ditto to mr speedy up there
[16:12] <katco> natefinch: ty
[16:15] <frobware> voidspace, I'm heading out but seems all OK to me.
[16:16] <voidspace> frobware: cool
[16:16] <voidspace> frobware: see you later
[16:33] <rogpeppe> mgz: any possibility we could get CI running on the chicago-cubs branch soonish?
[16:33] <rogpeppe> mgz: the bug has been fixed now (or *should* have been)
[16:33] <rogpeppe> sinzui: ^
[16:34] <mgz> rogpeppe: yup, will hopefully happen by tomorrow
[16:34] <rogpeppe> mgz: thanks
[16:39] <mgz> we have lots of people doing work, and I slowed things down by booming the wilys-lave
[16:39] <rogpeppe> mgz: when can we remove the critical status of the bug? will that happen automatically if it gets blessed?
[16:39] <rogpeppe> mgz: i'm concerned that it might take a week before we can land anything
[17:16] <alexisb> wwitzel3, ping
[17:18] <wwitzel3> alexisb: pong
[17:18] <alexisb> heya wwitzel3, I was just curious if you had a build of the lxd provider branch I could pull down and play with
[17:20] <wwitzel3> alexisb: https://github.com/wwitzel3/juju/tree/skullcrusher has lxd and the deploy branches merged in to it right now
[17:22] <wwitzel3> alexisb: ericsnow might have a more up-to-date one than that .. that is the same one from the sprint.
[17:22] <alexisb> thank you wwitzel3
[17:23] <ericsnow> alexisb: try the lxd-provider feature branch of github.com/juju/juju
[18:16] <katco> wwitzel3: hey the link from your email to docs isn't working
[18:41] <mup> Bug #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] <katco> wwitzel3: 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:59] <natefinch> katco: looks like it includes all of eric's stuff, too
[19:00] <natefinch> katco: like the list-payloads stuff
[19:07] <katco> natefinch: still, much of that registration stuff should have already been in the feature branch
[19:11] <natefinch> katco:  we hadn't implemented the CLI commands yet, so there wasn't the CLI command registration code
[20:44] <alexisb> ericsnow, does your lxd branch have bundle support?
[20:45] <ericsnow> alexisb: what do you mean "bundle"?  charm bundles?
[20:45] <ericsnow> alexisb: if it's something extra then it probably doesn't have it :)
[20:46] <alexisb> :) ok
[20:46] <alexisb> nws :)
[20:47] <alexisb> ericsnow, just fyi, the bundle support I am referring to his the "guibundle" branch that adds support for deploying bundles in core
[20:48] <ericsnow> alexisb: not included then
[22:02] <wwitzel3> katco: 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 fix
[22:02] <wwitzel3> katco: I resolved it, it is back to normal
[22:03] <katco> wwitzel3: k
[22:29] <mup> Bug #1506225 opened: Failed bootstrap does not clean up failed environment <juju-core:New> <https://launchpad.net/bugs/1506225>
[22:32] <mup> Bug #1506225 changed: Failed bootstrap does not clean up failed environment <juju-core:New> <https://launchpad.net/bugs/1506225>
[22:47] <mup> Bug #1506225 opened: Failed bootstrap does not clean up failed environment <juju-core:New> <https://launchpad.net/bugs/1506225>
[22:51] <mup> Bug #1506225 changed: Failed bootstrap does not clean up failed environment <juju-core:New> <https://launchpad.net/bugs/1506225>
[22:54] <mup> Bug #1506225 opened: Failed bootstrap does not clean up failed environment <juju-core:New> <https://launchpad.net/bugs/1506225>
[23:16] <wallyworld> anastasiamac: standup?
[23:17] <anastasiamac> wallyworld: m stanidn :D