[01:08] <thumper> davecheney: you around?
[02:00] <davecheney> thumper: sorry i missed you
[02:00] <davecheney> i thought the 1:1 was tuesday
[02:00] <thumper> ah :)
[02:00] <thumper> just last week
[02:01] <thumper> I have some time in an hour if that works for you
[02:06] <davecheney> thumper: i don't have anythig to talk about
[02:06] <davecheney> tomorrow is my last day
[02:06] <davecheney> then i'm taking a few personal days
[02:06] <davecheney> then off to vienna
[02:06] <davecheney> see you in nuremberg
[02:07] <thumper> um... ok
[02:10] <davecheney> or we can 1:1
[02:10] <davecheney> if you're free
[02:10] <davecheney> if there is stuff you have to talk about
[03:25] <anastasiamac> wallyworld_: hi :D
[03:29] <wallyworld_> hi
[03:33] <thumper> jam: ping for when you are around
[03:38] <anastasiamac> wallyworld_: u keep dorpping from canonical ...
[03:38] <anastasiamac> wallyworld_: 1.23 and master forwards r up for review
[03:38] <anastasiamac> wallyworld_: also map-ordering milestone is 1.24 which is currnt trunk so no backporting is required :D
[03:40] <wallyworld_> ok, ta looking
[04:20] <thumper> jam: reping
[04:31] <jam> hey thumper
[04:31] <thumper> jam: just doing expense paperwork
[04:31] <thumper> jam: hangout in 5 minutes?
[04:32] <jam> thumper: as you'd like, what about?
[04:32] <thumper> container stuff
[04:35] <thumper> jam https://plus.google.com/hangouts/_/canonical.com/containers
[07:00] <mattyw> morning everyone
[07:03] <dimitern> mattyw, o/
[07:05] <jam> hey dimitern, want to meet up a bit early?
[07:05] <dimitern> jam, hey - yeah, that works for me
[07:06] <jam> dimitern: k, I'm there
[07:06] <dimitern> jam, omw
[07:37] <TheMue> morning o/ ≋ (windy)
[07:38] <dimitern> TheMue, morning
[08:22] <voidspace> wallyworld: ping
[08:31] <dimitern> voidspace, dooferlad, morning
[08:31] <dooferlad> dimitern o/
[08:31] <dimitern> dooferlad, I have a PR for you to have a look - https://github.com/juju/juju/pull/1976/
[08:31] <dooferlad> dimitern: looking
[08:32] <dimitern> dooferlad, in retrospect, I should've done that a week ago, but there it is
[08:33] <dooferlad> dimitern: If you had, I would probably have done a lot less digging into the Juju code. It is all an education.
[08:33] <dimitern> dooferlad, that's my consolation :)
[08:33] <dooferlad> dimitern: :-)
[08:40] <voidspace> dimitern: morning
[08:41] <dimitern> voidspace, nice branch btw
[08:42] <dimitern> voidspace, i'll approve it shortly I think
[08:42] <voidspace> dimitern: fixing the provisioner issue? cool.
[08:42] <voidspace> dimitern: wallyworld reviewed it, but he missed the test I think.
[08:42] <dimitern> voidspace, the maas thing yeah
[08:42] <voidspace> dimitern: I have a trunk branch as well, but I haven't submitted it
[08:42] <dimitern> voidspace, was it a diff mismatch on RB or it shows that test?
[08:42] <voidspace> dimitern: in case I need to make changes, when the first one lands I'll submit the second
[08:43] <voidspace> dimitern: it shows the test, but it's in container_test.go and wallyworld was expecting something in provisioner_test.go
[08:43] <dimitern> voidspace, ah, right
[08:44] <voidspace> dimitern: I'm pretty sure that's it anyway, he's not around to ask :-)
[08:52] <wallyworld> voidspace: hi, sorry as having dinner
[08:52] <voidspace> wallyworld: you're allowed to have dinner... :-)
[08:52] <wallyworld> voidspace: sorry i missed the test, i'll take another loko
[08:52] <voidspace> wallyworld: np
[08:53] <wallyworld> voidspace: actually, i gave you a shipit so go for it, was more of a question seeking clarification
[08:53] <voidspace> wallyworld: ah
[08:53] <dimitern> voidspace, reviewed
[08:54] <voidspace> wallyworld: well, it was a "Fix it, then ship it!"" with an open issue. I wanted to check with you before just dropping the issue.
[08:54] <wallyworld> voidspace: ah i see what you mean, thanks for asking
[08:54] <voidspace> dimitern: thanks
[08:54] <voidspace> wallyworld: I have some minor issues from dimitern to fix anyway...
[08:54] <voidspace> :-)
[09:02] <dimitern> TheMue, standup?
[09:34] <voidspace> dimitern:
[09:34] <voidspace> ... value *errors.Err = &errors.Err{message:"", cause:(*errors.Err)(0xc2100790f0), previous:(*errors.Err)(0xc2100a50f0), file:"github.com/juju/juju/leadership/leadership.go", line:43} ("leadership claim denied")
[09:34] <voidspace> dimitern: util_test.go:1406:
[09:35] <frankban> ocr: is anyone available for reviewing http://reviews.vapour.ws/r/1324/ ? thank you!
[10:07] <dimitern> dooferlad, my branch landed btw
[10:07] <dooferlad> dimitern: sweet.
[10:07] <dimitern> dooferlad, I'm starting on CLI for subnets following the same approach
[10:37] <mattyw> natefinch, morning
[10:37] <mattyw> natefinch, judging by twitter I'd say you've been watching the news/ reading a paper this morning ;)
[10:37] <natefinch> mattyw: been watching the news for a while, just finally figured out how to put my views into 140 characters :)
[10:58]  * TheMue is out for lunch, bbiab
[10:58] <TheMue> dimitern: btw, found a nice way to simulate the error, it's pretty simple
[11:00] <dimitern> TheMue, yeah? let me know when you're back please
[12:25] <TheMue> dimitern: sure, "select id, hostname from maasserver_node;" resolves the names, then you do a "select id, name from metadataserver_noderesult where node_id = ..." to find the right gathered datas.
[12:25] <TheMue> dimitern: interesting is the one named 00-maas-01-lshw.out
[12:25] <dimitern> TheMue, yes, indeed
[12:25] <dimitern> TheMue, so you managed to reproduce the bug and the error?
[12:26] <TheMue> dimitern: having its ids allows you to do a "update metadataserver_noderesult set data = '' where id = 43;"
[12:26] <TheMue> dimitern: in a first round the bootstrap funnily wanted exactly my corrupted node, yes, with a matching error like in lp
[12:27] <TheMue> dimitern: I then acquired the node to have a working bootstrap and then released it again to simulate the error during deploying
[12:28] <TheMue> dimitern: this currently hangs, so I now want to take a deeper look into the logs and await to find the same error there
[12:28] <dimitern> TheMue, btw you can specify which node to pick at bootstrap time with --to node.maas
[12:29] <TheMue> dimitern: ah, makes the next round a bit more simple
[12:29] <dimitern> TheMue, yeah :)
[12:30] <TheMue> dimitern: but so it is fine too, with currently only four nodes here you quickly get the right (corrupted) one
[12:30] <dimitern> TheMue, so if the error is reproduced, you should see it just before bootstrap outputs Lauching instance XYZ
[12:30] <dimitern> TheMue, and the bootstrap should fail
[12:31] <dimitern> TheMue, if it keeps going after the instance is started, then it's not reproduced
[12:31] <TheMue> dimitern: yeah, I had the same output like in the lp issue
[12:31] <TheMue> dimitern: same error message and bootstrapping failing
[12:33] <dimitern> TheMue, nice!
[12:34] <TheMue> yeah
[12:46] <voidspace> bug 1437038
[12:46] <mup> Bug #1437038: 1.23b2 fails to get IP from MAAS for containers, falls back to lxcbr0 <addressability> <maas-provider> <network> <juju-core:Fix Committed by mfoord> <juju-core 1.23:Fix Committed by mfoord> <https://launchpad.net/bugs/1437038>
[12:48] <mup> Bug #1438168 was opened: juju 1.23 doesn't release IP addresses for containers <juju-core:In Progress by mfoord> <https://launchpad.net/bugs/1438168>
[12:56]  * dimitern steps out for a while
[14:03] <natefinch> perrito666: if you can tweet you can get on the hangout ;)
[14:17]  * dimitern is back
[14:32] <dimitern> TheMue, thanks for updating bug 1427814, it's really useful to have the info about how to tweak lshw data in the maas db
[14:32] <mup> Bug #1427814: juju bootstrap fails on maas with when the node has empty lshw output from commissioning <bootstrap> <maas> <maas-provider> <network> <juju-core:Triaged by themue> <https://launchpad.net/bugs/1427814>
[14:32] <TheMue> dimitern: yw
[14:48] <ericsnow> cherylj: would you mind updating #1435974 with where things are at with the LICENCE fixes?
[14:48] <mup> Bug #1435974: Copyright information is not available for some files <juju-core:In Progress by cherylj> <juju-core 1.22:In Progress by cherylj> <juju-core 1.23:In Progress by cherylj> <https://launchpad.net/bugs/1435974>
[15:03] <cherylj> ericsnow: sure.
[15:03] <ericsnow> cherylj: thanks :)
[15:04] <cherylj> ericsnow: I do have questions about a couple repos.
[15:05] <cherylj> I'm guessing we don't need to modify the gojson* repos.
[15:05] <cherylj> and the same for syslog
[15:06] <ericsnow> cherylj: right
[15:07] <ericsnow> cherylj: (since they are slight adaptations of the Go stdlib code and retain that copyright/license)
[15:07] <cherylj> k
[15:07] <cherylj> I just need to do the charm branches, and I think I'll be done.
[15:07] <cherylj> then on to updating dependencies.tsv
[15:08] <ericsnow> dimitern, dooferlad: FWIW, "juju space" is pretty ambiguous; any chance we could name it something more clearly related to networking?
[15:08] <ericsnow> cherylj: awesome!  thanks for slogging through all that :)
[15:09] <cherylj> ericsnow: np!  Although I did run into that unrelated test failure when trying to merge juju/testing 1.22
[15:09] <cherylj> thumper just manually merged it last time
[15:09] <voidspace> dimitern: can we add a new upgrade step in a bugfix release?
[15:10] <dooferlad> ericsnow: That is a discussion which has started several times and is currently on hold. I expect it will come up at the sprint.
[15:10] <voidspace> dimitern: as adding the addresser would require upgrading IP addresses to add a Life field
[15:10] <voidspace> dimitern: that seems unfortunate
[15:10] <ericsnow> dooferlad: cool, thanks
[15:10] <voidspace> dimitern: I have a bunch of patches but I'm not sure what to do about the upgrade step
[15:12] <dimitern> sorry guys - in a call
[15:12] <voidspace> dimitern: np
[15:13] <cherylj> ericsnow, natefinch:  since the license is changing for charm, do I need to update all the branches?  Or just 1.22, v4 and v5?
[15:15] <mup> Bug #1438258 was opened: error while destroying incomplete environment <juju-core:New> <https://launchpad.net/bugs/1438258>
[15:15] <ericsnow> cherylj: I'd say consider the branches that will be related to current or future juju releases
[15:17] <natefinch> cherylj: don't update old branches (other than 1.22 & v4)
[15:17] <cherylj> ericsnow, natefinch:  Thanks!
[15:17] <voidspace> ericsnow: natefinch: if I want to prepare a binary for someone to try out, know how I should do it?
[15:17] <voidspace> we have a script to do source releases but not binaries
[15:17] <voidspace> I just need an amd64 build
[15:18] <voidspace> can I just tart up juju* from $GOPATH/bin
[15:18] <natefinch> voidspace: yeah, you just need juju and jujud
[15:18] <voidspace> natefinch: cool, thanks
[15:18] <ericsnow> voidspace: just "go install ./juju/..." and send them the file out of $GOPATH/bin, right?
[15:19] <voidspace> ericsnow: s/file/files/ but yeah - that's what I thought and natefinch seems to be confirming
[15:19] <ericsnow> voidspace: yep :)
[15:19] <ericsnow> voidspace: BTW, did you see my first-draft poster yet? :)
[15:19] <natefinch> yep... nice thing about go.  It's just copy and paste the binaries.  for us, we just need the client and the server
[15:20] <ericsnow> natefinch, voidspace: don't the tools also need to get copied (so they can be uploaded)
[15:20] <ericsnow> natefinch, voidspace: jujuc, etc.
[15:20] <voidspace> ericsnow: natefinch: jujud is "the tools"
[15:20] <voidspace> ah, maybe
[15:21] <ericsnow> voidspace: yeah, the hook tools like set-relation
[15:21] <natefinch> jujud is the tools, the upload just symlinks jujud to jujuc
[15:21] <natefinch> er vice versa
[15:21] <ericsnow> natefinch: ah
[15:21] <natefinch> ericsnow: all that stuff, symlinks
[15:21] <ericsnow> natefinch: how funny
[15:23] <cherylj> okay, I need reviews for the charm license changes:  https://github.com/juju/charm/pull/107
[15:23] <cherylj> https://github.com/juju/charm/pull/108
[15:23] <cherylj> https://github.com/juju/charm/pull/109
[15:23] <ericsnow> jam: thanks (for the calender access) :)
[15:28] <cherylj> ericsnow: Here's the update list of repos:  https://bugs.launchpad.net/juju-core/+bug/1435974/comments/11
[15:28] <mup> Bug #1435974: Copyright information is not available for some files <juju-core:In Progress by cherylj> <juju-core 1.22:In Progress by cherylj> <juju-core 1.23:In Progress by cherylj> <https://launchpad.net/bugs/1435974>
[15:28] <cherylj> Are there any I missed?
[15:33] <dimitern> voidspace, hey
[15:33] <dimitern> voidspace, so what's the issue with the upgrade step?
[15:37] <ericsnow> cherylj: LGTM, thanks!
[15:37] <cherylj> yay!  thanks, ericsnow   :)
[15:38] <voidspace> dimitern: 1.23 has IP addresses in it
[15:38] <dimitern> voidspace, yeah?
[15:38] <voidspace> dimitern: so if we backport "release IP addresses" to 1.23, we'll need an upgrade step from beta2 to beta3
[15:38] <voidspace> dimitern: adding the Life field to IP addresses
[15:38] <voidspace> dimitern: is that ok?
[15:40] <dimitern> voidspace, can we do that?
[15:41] <dimitern> voidspace, aren't the steps based on major/minor versions?
[15:41] <voidspace> dimitern: well exactly
[15:41] <voidspace> dimitern: I don't think we *can* do it
[15:42] <voidspace> dimitern: that's exactly what I'm asking though :-)
[15:42] <dimitern> voidspace, well
[15:42] <voidspace> dimitern: the other way is to backport the *original* approach
[15:42] <dimitern> voidspace, I think you could still try to run the step - it shouldn't do any harm if Life is already there
[15:43] <voidspace> dimitern: do upgrade steps run at all? I'd have to look through the code to work it out
[15:43] <voidspace> dimitern: the original approach was with a Provisioner API instead of a worker
[15:43] <voidspace> and no Life field
[15:43] <voidspace> I still have that code
[15:43] <dimitern> voidspace, hmm
[15:43] <dimitern> voidspace, ok, let's think for a minute
[15:44] <dimitern> voidspace, what's the worst that can happen if we omit this from 1.23?
[15:44] <voidspace> it looks to me like upgrade steps for a version are run / re-run when you upgrade within a version
[15:44] <dimitern> voidspace, addresses won't be released
[15:44] <voidspace> i.e. 1.23.1 to 1.23.2 will run 1.23 upgrade steps I believe
[15:44] <dimitern> voidspace, ah - then it might work?
[15:44] <voidspace> dimitern: if I'm right
[15:45] <voidspace> PerformUpgrade and runUpgradeSteps in upgrades/upgrade.go
[15:45] <mup> Bug #1438274 was opened: unit test failures: storeManagerStateSuite.TestStateWatcher <ci> <juju-core:New> <https://launchpad.net/bugs/1438274>
[15:45] <dimitern> voidspace, it seems like a quick experiment is needed to verify this
[15:46] <voidspace> yeah
[15:46] <voidspace> dimitern: I'll define a new upgrade step that dies horribly and see if it runs :-)
[15:46] <dimitern> voidspace, e.g. start from the earliest possible version that has IP addresses collection, which is actually used
[15:47] <dimitern> voidspace, which should be the 1.23-beta1 right?
[15:47] <voidspace> sounds right
[15:48] <voidspace> dimitern: but the upgrade step is only on trunk - so I'll either need to do the full port and test that
[15:48] <voidspace> dimitern: or just take trunk and change the version back to 1.23-beta3 or whatever
[15:50] <dimitern> voidspace, the latter seems easier
[15:51] <voidspace> dimitern: that's what I'm doing
[15:51] <voidspace> dimitern: just bootstrapping 1.23
[15:51] <dimitern> voidspace, yeah and deploy some lxc-s
[15:51] <voidspace> yep
[15:51] <voidspace> dimitern: hmm, there's still an issue. This will become a 1.22 upgrade step instead of 1.23
[15:52] <voidspace> dimitern: so the upgrade step needs to check if the ipaddress collection exists, and bail without error if it doesn't
[15:52] <voidspace> and it needs to run if upgrading from 1.22 -> 1.24
[15:52] <dimitern> voidspace, considering the steps are idempotent, it shouldn't be a problem to have the same step for 1.22 and 1.23 I guess
[15:53] <voidspace> dimitern: yep, true - that solves the problem of 1.23 beta 1 -> 1.24
[15:53] <dimitern> voidspace, sweet!
[15:53] <voidspace> and 1.22 -> 1.24 I think
[15:53] <voidspace> in fact 1.23 upgrade steps must run then anyway
[15:53] <voidspace> all intermediate steps must run
[15:54] <dimitern> exactly
[15:54] <voidspace> deploying lxc
[16:18] <cherylj> ericsnow, natefinch:  Can I get a review on the last license changes?    https://github.com/juju/charm/pull/107
[16:18] <cherylj> https://github.com/juju/charm/pull/108
[16:18] <cherylj> https://github.com/juju/charm/pull/109
[16:19] <cherylj> and the utils changes:  http://reviews.vapour.ws/r/1329/        http://reviews.vapour.ws/r/1328/
[16:25] <voidspace> dimitern: it looks like 1.22 steps don't get run when going from 1.23beta3 to 1.23beta4
[16:25] <voidspace> which is odd
[16:25] <voidspace> I'll try again
[16:25] <voidspace> I'm only seeing steps121 in the logs though
[16:26] <dimitern> voidspace, I wouldn't expect 1.22 steps to run for 1.23-beta3 -> 1.23-beta4
[16:26] <dimitern> voidspace, but the 1.23 should
[16:27] <voidspace> dimitern: well - I'm seeing 1.21 ones run - but neither 1.22 nor 1.23...
[16:28] <dimitern> voidspace, how did you prepare your scenario?
[16:28] <voidspace> dimitern: http://pastebin.ubuntu.com/10707700/
[16:28] <voidspace> dimitern: juju bootstrap --upload-tools  (branch 1.23)
[16:28] <voidspace> dimitern: then "juju add-machine lxc:0" and wait for instance id
[16:29] <voidspace> dimitern: then checkout master and do the godeps / go install dance
[16:29] <voidspace> well, after changing version/version.go to 1.23-beta3 (should have picked beta4 but it shouldn't matter)
[16:29] <dimitern> voidspace, and before bootstrap you've rebuilt the juju binaries, right?
[16:29] <voidspace> then "juju upgrade-juju --upload"
[16:29] <voidspace> dimitern: yep
[16:30] <voidspace> then "juju upgrade-juju --upload-tools"
[16:30] <voidspace> I mean
[16:30] <voidspace> dimitern: http://pastebin.ubuntu.com/10707700/
[16:30] <voidspace> I will try again, with a better new version number and maybe some extra logging
[16:30] <voidspace> but first - coffee
[16:31] <dimitern> ok
[16:35] <dimitern> time to go
[19:53] <thumper> mramm: ping
[22:36] <bogdanteleaga> +