[00:04] <menn0> wallyworld, thumper, katco or axw : fix for bug 1451674: http://reviews.vapour.ws/r/1581/
[00:04] <mup> Bug #1451674: Broken DB field ordering when upgrading to Juju compiled with Go 1.3+ <blocker> <golang> <upgrade-juju> <vivid> <juju-core:In Progress by menno.smits> <juju-core 1.23:In Progress by menno.smits> <juju-core 1.24:In Progress by menno.smits> <https://launchpad.net/bugs/1451674>
[00:06] <wallyworld> menn0: looking
[00:13] <menn0> wallyworld: ta
[00:14] <menn0> wallyworld: just saw one thing... addBsonDField could do with a docstring
[00:14] <wallyworld> sure
[00:18] <wallyworld> menn0: haven't finished reading it, but there's a but i can see in updateBsonField
[00:19] <wallyworld> well i think it's a bug
[00:19] <menn0> wallyworld: ok?
[00:19] <wallyworld> the loop var "field" is being updated, but needs to be assigned back into the slice
[00:19] <wallyworld> otherwise the bson.D slice passed in will remain unmodified
[00:20] <menn0> wallyworld: no I think that ok b/c the slice isn't being modified, just a field of a struct inside it
[00:20] <wallyworld> that's what i mean
[00:20] <wallyworld> the field loop var is a copy of the slice value
[00:20] <menn0> wallyworld: if that didn't work then most of the upgrade unit tests would be failing but they still all pass
[00:21] <wallyworld> menn0: http://play.golang.org/p/P3bI04FsF9
[00:21] <wallyworld> if i comment out // this line it prints the same slice
[00:22] <menn0> wallyworld: hmmm ok. i wonder why everything still works then.
[00:22] <wallyworld> nfi
[00:22] <wallyworld> i hadn't finished reading it yet :-)
[00:22] <wallyworld> i'll keep reading to see if i can see why
[00:27] <menn0> wallyworld: no idea why it's working but I'll change it just to be sure
[00:28] <wallyworld> menn0: ok, do you agree there's an issue? or am i on crack?
[00:28] <menn0> wallyworld: your example is pretty convincing
[00:28] <menn0> wallyworld: so I'm going to fix it
[00:28] <wallyworld> ok, would be good to understand why
[00:30] <menn0> wallyworld: yeah there could be a wider test problem
[00:30] <menn0> wallyworld: i'll look at that too
[00:30] <menn0> wallyworld: lunch first
[00:30] <wallyworld> that's what i'm afraid of
[00:30]  * wallyworld is hungry too
[00:31]  * anastasiamac wonders why wallyworld is afraid of lunch
[00:33] <mup> Bug #1452082 was opened: restore: agent old password not found in configuration <backup-restore> <ci> <reliability> <juju-core:Triaged> <https://launchpad.net/bugs/1452082>
[00:34] <menn0> wallyworld: this is probably nicer (and faster) than copying: http://play.golang.org/p/v4b16JDzOE
[00:36] <wallyworld> menn0: that works. i still fear the test may be faulty. but have a mouthful of food so will look ina bit
[00:43] <waigani> menn0, wallyworld: this is what I get: http://pastebin.ubuntu.com/10993413/
[00:45] <wallyworld> right, so there's a bug there. but also in the test because it didn't fail
[00:46] <waigani> wallyworld: yep, I said as much in my review
[01:10] <davecheney> menn0: noted
[01:10] <davecheney> let me check, that is confusing
[01:16] <natefinch> waigani: can I get a review?  http://reviews.vapour.ws/r/1579/
[01:17] <waigani> natefinch: yep. Just let me get some lunch and yours is next on the list
[01:17] <natefinch> waigani: cool, thanks
[01:18] <davecheney> natefinch: LGTM
[01:19] <natefinch> davecheney: thanks
[01:23] <menn0> waigani, wallyworld : I definitely agree that that func needs to be changed. I'm going to figure out why the tests pass despite it.
[01:23] <wallyworld> ty, sounds good
[01:30] <menn0> wallyworld: I see why the everything still works
[01:30] <menn0> waigani: ^^^
[01:30] <menn0> updateBsonDField is only used to update _id
[01:30] <menn0> and the correct _id is used on the txn.Op
[01:30] <menn0> this override the value on the document (in fact you can leave _id off documents, it gets automagically added)
[01:30] <menn0> wallyworld, waigani: i'll fix it anyway of course
[01:31] <wallyworld> menn0: ah makes sense, glad you found it
[01:36] <natefinch> davecheney: exact same thing, except against 1.24, where it should have been targeted in the first place: http://reviews.vapour.ws/r/1582/
[01:42]  * davecheney looks
[01:44] <natefinch> (produced by cherry picking from the first PR, ignoring the two merge commits that prevent me from just re-PRing from the same branch... stupid merges)
[01:45] <mup> Bug #1442132 changed: [packaging juju-1.23] Issues met while working on debian/copyright file <packaging> <tech-debt> <juju-core:Fix Released by gz> <juju-core 1.23:Fix Released by gz> <https://launchpad.net/bugs/1442132>
[01:45] <mup> Bug #1445063 changed: addressable containers cannot resolve non-FQDN in maas <addressability> <cloud-installer> <kvm> <landscape> <lxc> <maas-provider> <network> <oil> <openstack>
 <juju-core:Fix Released by themue> <juju-core 1.23:Fix Released by dimitern> <juju-core 1.24:Fix Released by themue> <https://launchpad.net/bugs/1445063>
[01:45] <mup> Bug #1446662 changed: Vivid bootstrap and destroy-environment intermittently fails <bootstrap> <destroy-environment> <golang> <vivid> <juju-core:Fix Released by ericsnowcurrently> <juju-core 1.23:Fix Released by gz> <https://launchpad.net/bugs/1446662>
[01:45] <mup> Bug #1446857 changed: MeterStatusWatcher tests fail on windows test slave <ci> <test-failure> <juju-core:Fix Released by mattyw> <https://launchpad.net/bugs/1446857>
[01:45] <mup> Bug #1447595 changed: TestLeadership fails on windows test slave <ci> <test-failure> <juju-core:Fix Released by bteleaga> <https://launchpad.net/bugs/1447595>
[01:45] <mup> Bug #1447853 changed: Local charms are not added to storage on upgrade to 1.22.x <charms> <regression> <storage> <upgrade-juju> <juju-core:Fix Released by hduran-8>
[01:45] <mup> <juju-core 1.22:Fix Released by hduran-8> <juju-core 1.23:Fix Committed by hduran-8> <juju-core 1.24:Fix Released by hduran-8> <https://launchpad.net/bugs/1447853>
[01:47] <menn0> waigani, wallyworld: PR updated as per review comments: http://reviews.vapour.ws/r/1581/
[01:48] <sinzui> wallyworld, axw Do either of you have a moment to review http://reviews.vapour.ws/r/1583/
[01:49] <axw> sinzui: done
[01:49] <sinzui> thank you axw
[01:50] <wallyworld> axw: time for a quick chat in standup?
[01:50] <wallyworld> menn0: will look in a sec
[01:50] <axw> wallyworld: sure, brt
[01:52] <davecheney> voidspace: ping ?
[01:55] <thumper> davecheney: is after midnight for voidspace, unlikely to be around
[01:55] <thumper> and he isn't on line even
[01:58] <davecheney> i'll wait
[01:59] <davecheney> https://www.youtube.com/watch?v=UJkxFhFRFDA
[01:59] <natefinch> davecheney: while you wait can you review that second PR? ;)
[02:01] <natefinch> davecheney: https://www.youtube.com/watch?v=6g4dkBF5anU
[02:06] <wallyworld> menn0: i might be retarded driving reviewboard, but i can't get a old-new diff to show the test changes; the test was updated i assume
[02:06] <menn0> wallyworld: no, the tests were fine b/c the end result was correct
[02:07] <wallyworld> hmm, ok. it worried me that the test passed even though the code was flawed
[02:07] <menn0> wallyworld: but by side effect
[02:08] <wallyworld> i'm still a little hestitant
[02:08] <wallyworld> when a key function in the solution doesn't work and the test still passes....
[02:08] <menn0> wallyworld: as I explained updateBsonDField was only used in one place and in that case it didn't really matter what updateBsonDField did b/c mgo or mongo prefers the key from the txn.Op over the document
[02:08] <menn0> wallyworld: may I should just remove updateBsonDField and the call to it
[02:09] <menn0> wallyworld: but then we're relying on an effect of mgo or mongo
[02:09] <wallyworld> if we don't need it then yeah
[02:09] <menn0> wallyworld: which I guess is very unlikely to change
[02:09] <waigani> menn0: or test the func explicitly
[02:09] <wallyworld> i'm -1 on keeping unecessary code around
[02:09] <menn0> wallyworld, waigani: i'm going to remove it
[02:10] <wallyworld> there's plenty of other places in juju that use the txn key
[02:10] <wallyworld> so if mgo changes, juju will break badly
[02:10] <wallyworld> maybe remove the method and add a decent comment
[02:11] <natefinch> it's vcs. We can go back in time to get the code if we need it again.
[02:12] <natefinch> wallyworld: Any specific it reason to mark this bug high, other than it makes us look like knuckleheads?  https://bugs.launchpad.net/juju-core/+bug/1370896
[02:12] <mup> Bug #1370896: juju 1.21-alpha1 has conf files in /var/log/juju on instances <canonical-bootstack> <logging> <rsyslog> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1370896>
[02:13] <wallyworld> natefinch: that, plus a user has a reasonable expectation to blow away a log dir and not break things
[02:13] <natefinch> wallyworld: yeah, that's a good point
[02:14] <wallyworld> i can imagine sysadmins doing that regularly to reclaim space etc
[02:14] <axw> wallyworld anastasiamac: if you have any time today, would appreciate if you could look over https://github.com/juju/docs/pull/411 and see if we're missing anything important
[02:15] <menn0> wallyworld: done
[02:15] <wallyworld> will do
[02:15] <wallyworld> menn0: ty, lookng
[02:15] <anastasiamac> axw: looking :D
[02:16] <natefinch> wallyworld: the rest of our config files are under /var/lib/juju/, is that a fair place to put them?  The bug mentions /etc/ but AFAIK we don't store anything there right now
[02:17] <wallyworld> natefinch: IMO, /var/lib/juju is reasonable. longer term perhaps we should put stuff in /etc/juju or wherever
[02:17] <wallyworld> not sure
[02:17] <menn0> wallyworld: thanks
[02:17] <wallyworld> np, thanks for finding and fixing
[02:18] <menn0> wallyworld, waigani: thanks both for your thorough reviews
[02:18] <mup> Bug #1326091 changed: deploying into kvm with local provider, hostnames are not unique <cloud-installer> <kvm> <local-provider> <juju-core:Fix Released by wwitzel3> <https://launchpad.net/bugs/1326091>
[02:18] <mup> Bug #1326799 changed: juju should log at environment URL <api> <tech-debt> <juju-core:Fix Released by thumper> <https://launchpad.net/bugs/1326799>
[02:18] <mup> Bug #1436925 changed: juju status complains "config has no UUID" when no .jenv is present <canonical-is> <regression> <status> <juju-core:Fix Released by waigani> <https://launchpad.net/bugs/1436925>
[02:18] <mup> Bug #1437015 changed: debug-log spammed with leader-election messages <landscape> <stakeholder-critical> <juju-core:Fix Released by cox-katherine-e> <juju-core 1.24:Fix Released by cox-katherine-e> <https://launchpad.net/bugs/1437015>
[02:18] <mup> Bug #1438489 changed: juju stop responding after juju-upgrade <upgrade-juju> <juju-core:Fix Released by johnweldon4> <juju-core 1.24:Fix Released by johnweldon4> <https://launchpad.net/bugs/1438489>
[02:18] <mup> Bug #1446608 changed: agent panic on MAAS network with uppercase characters <cloud-installer> <landscape> <maas-provider> <network> <reliability> <stakeholder-critical> <juju-core:Fix Released by dimitern> <juju-core 1.24:Fix Released by dimitern> <https://launchpad.net/bugs/1446608>
[02:18] <mup> Bug #1447841 changed: eu-central-1 AWS region V4 signing required and not supported <ec2-provider> <juju-core:Fix Released by cox-katherine-e> <juju-core 1.24:Fix Released by cox-katherine-e> <https://launchpad.net/bugs/1447841>
[02:18] <mup> Bug #1449302 changed: upgrades: old machines need block devices document <storage> <tech-debt> <juju-core:Fix Released by wallyworld> <juju-core 1.24:Fix Released by wallyworld> <https://launchpad.net/bugs/1449302>
[02:18] <mup> Bug #1449367 changed: remove storage feature flag <tech-debt> <juju-core:Fix Released by wallyworld> <juju-core 1.24:Fix Released by wallyworld> <https://launchpad.net/bugs/1449367>
[02:18] <mup> Bug #1449436 changed: Environment variables are not propagated to jujud on vivid <blocker> <juju-core:Fix Released by axwalk> <juju-core 1.23:Fix Committed by axwalk> <juju-core 1.24:Fix Released by axwalk> <https://launchpad.net/bugs/1449436>
[02:18] <mup> Bug #1450146 changed: vsphere provider feature flag should apply only to bootstrap <blocker> <juju-core:Fix Released by ericsnowcurrently> <juju-core 1.24:Fix Released by ericsnowcurrently> <https://launchpad.net/bugs/1450146>
[02:18] <mup> Bug #1451297 changed: Upgrade from 1.18 to 1.23 fails: password for machine agent can't be set <blocker> <regression> <juju-core:Fix Released by menno.smits> <juju-core 1.23:Fix Committed by menno.smits> <juju-core 1.24:Fix Released by menno.smits> <https://launchpad.net/bugs/1451297>
[02:19] <waigani> menn0: I was off target, but glad it helped
[02:19] <natefinch> thumper: your opinion?  our rsyslog config files are under /var/log/juju/ right now.. is /var/lib/juju/ a suitable fix, or should we start using /etc/juju/?   re: https://bugs.launchpad.net/juju-core/+bug/1370896
[02:19] <mup> Bug #1370896: juju 1.21-alpha1 has conf files in /var/log/juju on instances <canonical-bootstack> <logging> <rsyslog> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1370896>
[02:20] <waigani> man that's a lot of mupping
[02:20] <menn0> mupping hell!
[02:20] <natefinch> yeah, mup is pretty muppy tonight
[02:20] <waigani> hehe
[02:20] <thumper> natefinch: I'm trying to get context
[02:20] <wallyworld> axw: anastasiamac: btw one thing we should do after feedback from william is to incude "naked" provider types in the pools list - they will appear as pools with empty config
[02:21] <thumper> natefinch: hmm...
[02:21] <axw> wallyworld: agreed
[02:21] <thumper> personally I think we should start using /etc/juju
[02:21] <wallyworld> thumper: yeah, i think that's ok for longer term, but for 1.24.....
[02:21] <thumper> natefinch: in the near future, we'll have additional acceptable certs
[02:21] <thumper> /etc/juju/certs.d/<files>
[02:21] <wallyworld> we should do this holistically
[02:22] <thumper> are we expected for fix this for 1.24?
[02:22] <thumper> if so... just use $datadir
[02:22] <wallyworld> yes, it's on the 1.24 list
[02:22] <thumper> which is /var/lib/juju
[02:22] <wallyworld> stakeholder bug
[02:22] <thumper> and we'll move to /etc/juju Real Soon Now™
[02:22] <wallyworld> +1
[02:22] <natefinch> heh ok, cool
[02:23] <natefinch> thanks thumper
[02:25] <natefinch> (and wallyworld)
[02:25] <wallyworld> sure
[02:25] <wallyworld> thanks for fixing
[02:26] <anastasiamac> axw: added my 2c to 411 :D tyvm for keeping docs uptodate!!!! :))
[02:27] <axw> anastasiamac: thanks
[03:40] <bdx> hows it going everyone??
[03:40] <bdx> Can anyone give a few examples for possible values for the flat-network-providers config for quantum-gateway?
[03:46] <natefinch> bdx: we're mostly core juju devs on this list. The intricacies of specific charms are not really our specialty.
[03:47] <natefinch> bdx: I think most of the charm developers are in US/UK time zones, and so probably not online right now
[03:48] <natefinch> bdx: I recommend sending an email to juju@lists.ubuntu.com with your question, that way you can get answers asynchronously.
[04:20] <bdx> natefinch: Thanks!
[04:35] <bradm> is it possible to have a subordinate relate to another subordinate?  it doesn't seem to actual cause the relationship to happen, so I'm guessing not.
[04:51] <mup> Bug #1452113 was opened: log files are lost when agents are restarted under systemd  <regression> <systemd> <vivid> <juju-core:New> <juju-core 1.23:New> <juju-core 1.24:New> <https://launchpad.net/bugs/1452113>
[04:51] <mup> Bug #1452114 was opened: Unnecessary errors emitted during init system discovery <systemd> <vivid> <juju-core:New> <juju-core 1.23:New> <juju-core 1.24:New> <https://launchpad.net/bugs/1452114>
[05:04] <mup> Bug #1452113 changed: log files are lost when agents are restarted under systemd  <regression> <systemd> <vivid> <juju-core:New> <juju-core 1.23:New> <juju-core 1.24:New> <https://launchpad.net/bugs/1452113>
[05:04] <mup> Bug #1452114 changed: Unnecessary errors emitted during init system discovery <systemd> <vivid> <juju-core:New> <juju-core 1.23:New> <juju-core 1.24:New> <https://launchpad.net/bugs/1452114>
[05:10] <mup> Bug #1452113 was opened: log files are lost when agents are restarted under systemd  <regression> <systemd> <vivid> <juju-core:New> <juju-core 1.23:New> <juju-core 1.24:New> <https://launchpad.net/bugs/1452113>
[05:10] <mup> Bug #1452114 was opened: Unnecessary errors emitted during init system discovery <systemd> <vivid> <juju-core:New> <juju-core 1.23:New> <juju-core 1.24:New> <https://launchpad.net/bugs/1452114>
[05:30] <axw> wallyworld: I've started looking into placement+storage. let me know if you think something else is more important
[06:43] <wallyworld> axw: placement + storage sounds great
[07:53] <axw> wallyworld: there's a race condition in my storage hook order thingy, it's a bit borken :/
[07:54] <wallyworld> oh noes
[07:54] <axw> if the storage isn't provisioned fast enough, no hooks run
[07:54] <axw> (for storage-using charms only)
[07:54] <wallyworld> we will be releasing a new build in a couple of days
[07:54] <axw> ok
[07:55] <axw> I'll switch over to fixing this
[07:55] <wallyworld> +
[07:55] <wallyworld> 1
[07:55] <axw> I've got half way through getting placement working
[08:26] <voidspace> what's the easiest way of determining the mac address of a container deployed on a machine?
[08:27] <voidspace> juju ssh I guess
[08:31] <TheMue> voidspace: from outside or an agent running inside the container?
[08:31] <voidspace> TheMue: from outside
[08:31] <voidspace> TheMue: but I've found it via "juju ssh"
[08:31] <voidspace> TheMue: thanks
[08:31] <TheMue> voidspace: ok
[08:36] <wallyworld> axw: i'm off to soccer, back later. i've got maas storage working and unit tested, just finishing test double work to allow end-end start instance to run
[08:37] <wallyworld> "working" != tested live yet
[08:37] <wallyworld> done according to spec
[09:01] <voidspace> dooferlad: jam: standup?
[09:01] <jam> omw
[09:33] <gsamfira> hello folks. What version of go are we building the juju binaries with?
[09:51] <anastasiamac> gsamfira: 1.2 :D except for vivid 1.3
[10:16] <mup> Bug #1452207 was opened: worker/uniter: charm does not install properly if storage isn't provisioned before uniter starts <storage> <juju-core:Triaged by axwalk> <https://launchpad.net/bugs/1452207>
[11:25] <bdx> Hi, hows it going all?
[11:26] <bdx> Would someone be kind enough to share what the difference is between data-port and ext-port for neutron-openvswitch charm? .... And possibly
[11:27] <bdx> an example of how different params could be used?
[11:55] <mgz_> github is down at present, so I've disabled the lander
[11:56] <jamespage> mgz_, finally figured out https://bugs.launchpad.net/juju-core/+bug/1413910
[11:56] <mup> Bug #1413910: 1.21-rc1: Ambiguous resolution of private-address <network> <openstack-provider> <juju-core:New> <https://launchpad.net/bugs/1413910>
[11:56] <jamespage> \o/
[11:56] <jamespage> bdx, hello
[11:56] <jamespage> data-port is for vlan and flat networking traffic (east/west)
[11:56] <jamespage> ext-port is for north-south traffic when using neutron dvr
[11:57] <mgz_> ehe, so it is asciibetical sorting related?
[11:58] <mgz_> jamespage: also liam's bug 1435283
[11:58] <mup> Bug #1435283: juju occasionally switches a units public-address if an additional interface is added post-deployment <network> <juju-core:Triaged> <juju-core 1.24:Triaged by mfoord> <https://launchpad.net/bugs/1435283>
[12:04] <jam> mgz_: just before  you posted this they posted "finished emergency maintenance"
[12:05] <mgz_> yup, I'll try re-enabling shortly
[12:08] <jamespage> mgz_, I de-duped and commented on gnuoy's bug
[12:09] <mgz_> jamespage: thanks, Dimiter is off this week but I will poke someone else to pick this up
[12:10] <mgz_> jam: ^ any cunning ideas on sane network selection logic when we grow a new address? currently we do insane things.
[12:46] <mgz_> mattyw: aha, you're ocr today
[12:50] <mgz_> mattyw: so, I have two branches to land, but I actually want to add to pr2158 and want some advice
[12:50] <mgz_> I think the provider should log the instance type and image type it has selected
[12:51] <mgz_> any opinions on where I should put that?
[12:51] <mgz_> I guess in StartInstance rather than in FindInstanceSpec
[13:01] <dooferlad> voidspace, TheMue: MAAS call?
[13:02] <TheMue> dooferlad: in saphire? because I've got no calendar entry
[13:02] <dooferlad> TheMue: Oh, if you aren't on the invite, don't worry
[13:03] <TheMue> dooferlad: ok, I don't worry
[13:03] <TheMue> ;)
[13:03] <mattyw> mgz_, sorry - was feeding my face
[13:03] <mattyw> mgz_, happy to help
[13:07] <jam> mgz_: bug link?
[13:08] <mgz_> http://reviews.vapour.ws/r/1519
[13:08] <mgz_> jam: bug 1435283
[13:08] <mup> Bug #1435283: juju occasionally switches a units public-address if an additional interface is added post-deployment <network> <juju-core:Triaged> <juju-core 1.24:Triaged by mfoord> <https://launchpad.net/bugs/1435283>
[13:08] <mattyw> mgz_, I'd favour StartInstance - as you want to log what you're about to start rather than just what's been found
[13:08] <mgz_> mattyw: okay, adding that, then I'll poke you for a re-stamp and land
[13:09] <mattyw> mgz_, awesome
[13:18] <katco> natefinch: hey are your cards on the kanban up to date?
[13:19] <voidspace> dooferlad: wasn't that yesterday? doesn't look like I have an invite either
[13:19] <dooferlad> voidspace: Yea, I seem to have got in on that meeting. Fun.
[13:19] <voidspace> dooferlad: :-)
[13:19] <dooferlad> voidspace: it is another one today.
[13:19] <voidspace> dooferlad: enjoy
[13:19] <katco> wallyworld: sinzui: is bug 1451283 no longer a blocker?
[13:20] <mup> Bug #1451283: deployer sometimes fails with a unit status not found error <blocker> <ci> <intermittent-failure> <regression> <juju-core:In Progress by wallyworld> <juju-core 1.24:In Progress by wallyworld> <https://launchpad.net/bugs/1451283>
[13:20]  * voidspace lunches
[13:20] <wallyworld> katco: i downgraded it because it's very intermittent
[13:21] <sinzui> katco, it is a blocker according to wallyworld (hence the tag). We agreed to lower it to high so that it doesn't block merges
[13:21] <wallyworld> still unable to reproduce
[13:21] <katco> wallyworld: i.e. do we need to remove the blocker tag?
[13:21] <sinzui> wallyworld, I saw it last night on HP
[13:21] <wallyworld> do we have logs?
[13:21] <sinzui> wallyworld, but my change to capture logs wasn't in place yet
[13:22] <wallyworld> ok, np. next time it happens then
[13:22] <katco> so is trunk blocked or not? :p
[13:24] <wallyworld> no
[13:24] <wallyworld> because it's not critical, just high
[13:24] <katco> wallyworld: so can we remove the blocker tag?
[13:24] <wallyworld> so the blocker tag is new. it used to be that regression blocked. sinzui will need to comment as i'm not 100% on the new ploicy
[13:25] <sinzui> wallyworld, I will send an email
[13:25] <wallyworld> previously demoting to high did the trick
[13:25] <sinzui> wallyworld, blocker means this blocks something that the release team cares about, like a release or merges
[13:25] <katco> gah... why is it i can never pin down how to determine the list of trunk blockers. it's easier to submit a dummy PR haha
[13:25] <wallyworld> there's a lp query
[13:25] <katco> i have 3 queries saved
[13:26] <katco> all of which have been wrong at times now
[13:26] <wallyworld> yeah, the policy i think has changed from critical,tag=regression, to tag=blocker
[13:26] <wallyworld> the email will clear it up
[13:27] <katco> which is not true in this case?
[13:27] <sinzui> katco, any criticals on this list https://bugs.launchpad.net/juju-core/+bugs/?field.tag=blocker+ci&field.tags_combinator=ALL
[13:27] <sinzui> There are none
[13:28] <katco> sinzui: so the absolute rule is: tagged with "blocker" and "critical"?
[13:28] <sinzui> katco, yes
[13:28] <katco> sinzui: awesome, ty!
[13:29] <sinzui> katco, you need to query juju-core, juju-core/1.24, and juju-core/1.23
[13:29] <wallyworld> katco: it used to be tagged with regression and critical
[13:29] <wallyworld> katco: so that's why i simply demoted that bug to high to unblock
[13:30] <katco> wallyworld: gotcha
[13:30] <wallyworld> katco: it still blocks the release supposedly if not fixed, but not landings
[13:30] <wallyworld> once we can reporduce with logs it will get pushed back to critical i suspect
[13:32] <sinzui> katco, wallyworld true. CI will close all blocker+ci bugs when a branch passes. When we have a pleased branch, CI can confidently close all blocking bugs tagged with ci
[13:32] <sinzui> wallyworld, katco CI did that yesterday and left comments on bugs explain how it knows the bug was fixed
[13:32] <wallyworld> \o/
[13:32] <katco> sinzui: yeah that was nice :)
[13:41] <natefinch> katco: sorry, updating kanban now
[13:42] <katco> natefinch: no worries... the more up to date it is, the less i bug people ;)
[13:43] <jam> mgz_: voidspace: it seems like in https://bugs.launchpad.net/juju-core/+bug/1435283 we'd want hysterisis. So if we are currently using an IP address, if we see a new one, don't switch to it.
[13:43] <mup> Bug #1435283: juju occasionally switches a units public-address if an additional interface is added post-deployment <network> <juju-core:Triaged> <juju-core 1.24:Triaged by mfoord> <https://launchpad.net/bugs/1435283>
[13:43] <natefinch> katco: one of my bugs is reviewed and ready to merge, but 1.24 is blocked, so it can't land... should I set the card to done, or in progress and blocked?  It's technically something I still need to remember to do (land it once 1.24 is open).
[13:43] <jam> We do that for stuff like "move the currently active API IP address to the front of the list"
[13:43] <jam> we could "move the last known IP addresses ahead of the rest"
[13:43] <jam> natefinch: is wwitzel3 around?
[13:44] <katco> natefinch: "under review" and blocked
[13:44] <natefinch> katco: ok thanks
[13:44] <jam> I don't know what time he shows up these days
[13:44] <jam> I may try to bpi
[13:44] <jam> ping him later
[13:44] <katco> natefinch: although i don't see that 1.24 is blocked?
[13:45] <natefinch> katco: oh... maybe it has opened since last night
[13:45]  * natefinch hadn't actually checked in the last 9 hours :)
[13:47] <katco> natefinch: there are no open critical bugs with the "blocker" tag
[13:48] <natefinch> katco: cool
[13:57] <katco> sinzui: xwwt: are we still expecting to cut beta1 tomorrow?
[14:01] <wwitzel3> jam: hey, sorry, normally I am on earlier, I just had some errands to do this morning
[14:01] <natefinch> sinzui: can you help me assign this bug to the right milestones etc?  I have no clue how to make launchpad set it to be correctly targeted.  https://bugs.launchpad.net/juju-core/+bug/1452285
[14:02] <mup> Bug #1452285: logs don't rotate <juju-core:In Progress by natefinch> <juju-core 1.23:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1452285>
[14:02] <mgz_> natefinch: done it
[14:02] <natefinch> mgz_: thanks
[14:02] <sinzui> katco, maybe. This release is taking a long time. We need to talk about a 1.23.3 release
[14:02] <katco> natefinch: stand up
[14:03] <sinzui> natefinch, I don't see a problem with it. which milestone offends you?
[14:04] <wwitzel3> jam: I'll be online until 12AM, May 7th UTC
[14:04] <natefinch> sinzui: mgz_ fixed it
[14:05]  * mgz_ too fast
[14:05] <natefinch> sinzui, mgz_:  I don't know how to add more milestones after creating it (or choosing more than one when creating it).
[14:06] <sinzui> natefinch, ah, because you need to "Target to series" to add tasks, when assign the a milestone to each task
[14:06] <mgz_> natefinch: it's "Target to series" for reference. then leave the main heading at current master (1.25 here) and add the older branches that we may want backports for
[14:19] <katco> natefinch: wwitzel3: ericsnow: awesome, "the video call ended because of authentication issues"
[14:19] <mgz_> katco: just making you log in with sso again? that seems like a weekly thing
[14:20] <katco> mgz_: it just kicked me off in the middle of a meeting... refresh, and went right back in w/o any interaction from me
[14:20] <mgz_> random...
[14:21] <alexisb> team I see a blessed on 1.24, well done all!
[14:21] <alexisb> nice way to come back from the dead :)
[14:21] <natefinch> huzzah!
[14:22] <sinzui> katco, alexisb : I think we need to cut the vmware announcement from the release notes because it is still incomplete: https://docs.google.com/document/d/1qKWvSZ06Vx3ZI2RxYg6P7sWdIvOD5QXPfvpUNEtImMA/edit
[14:24] <alexisb> sinzui, ug, yeah we can follow-up with altoros on that today. can we add the notes before stable goes out?
[14:25] <sinzui> alexisb, absolutely. We always add to the notable with beta releases.
[14:25] <alexisb> sinzui, pull them then
[14:25] <mup> Bug #1452285 was opened: logs don't rotate <juju-core:In Progress by natefinch> <juju-core 1.23:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1452285>
[14:35] <katco> alexisb: sinzui: eric is assigned to the work, but he has critical bugs he needs to take care of today. i would expect those release notes to slip to next week based on what he has on his plate.
[14:36] <katco> alexisb: hope you're feeling better btw
[14:40] <voidspace> jam: right, that sounds like the right thing to do
[14:40] <voidspace> jam: IP addresses should not be merely lexicographically sorted when setting in state
[14:40] <voidspace> *merely be
[14:41] <jam> voidspace: yeah, the sort order seemed to match what jamespage found on the last post to the bug. 99 coming after 110
[14:41] <jam> or whatever the numbers were, it was 9* vs 1**
[14:41] <voidspace> jam: so change the algorithm to preserve the first and sort the rest...
[14:42] <jamespage> jam: sorted is a bit broken tho
[14:42] <jamespage> jam: as it makes the assumption that the 'lowest' ip address is actually the one configured
[14:42] <jamespage> why would the agent switch to a private-address that it knows is not actually configured on the machine?
[14:47] <alexisb> katco, I really want to push altoros to help with that, I can follow-up with sergey today, and understood on eric's commitments
[14:57] <katco> alexisb: ok sounds good
[14:58] <voidspace> jamespage: so that's two issues then - the address changing unnecessarily, and an incorrect address being used
[14:58] <voidspace> jamespage: *both* seem wrong, and would have different causes (fixing either might mask the other for your case)
[14:58] <katco> rick_h_: ping
[14:58] <rick_h_> katco: pong
[14:59] <katco> rick_h_: are you aware of this: https://docs.google.com/document/d/1vcpc1xLMdxvo_edMMlB2RS-h4I9eefkk5-a_Ey8ZoQE/edit# ?
[14:59] <katco> rick_h_: we have committed to this for the cycle, and it looks like there are a lot of tasks for your team
[15:00] <rick_h_> katco: will look after standup. The feature's come up before but not seen the latest revision of the spec for it.
[15:00] <katco> rick_h_: sounds good... just don't want you caught blindsided
[15:00] <rick_h_> katco: appreciate the warning
[15:15] <alexisb> jam, if you are still around katco could use your assistance
[15:37] <mup> Bug #1441904 changed: jujud won't start if apt-get of juju-mongodb package fails <canonical-is> <upgrade-juju> <juju-core:Fix Released by menno.smits> <juju-core 1.23:Fix Committed by menno.smits> <juju-core 1.24:Fix Released by menno.smits> <https://launchpad.net/bugs/1441904>
[17:01] <wwitzel3> ericsnow: ping
[17:01] <ericsnow> wwitzel3: hey
[17:04] <mup> Bug #1452381 was opened: Failed to deploy vivid LXCs on vivid host <juju-core:New> <https://launchpad.net/bugs/1452381>
[17:34] <mup> Bug #1452393 was opened: Use a dependency injection approach in the bootstrap command <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1452393>
[17:47] <bac> sinzui: ping
[17:47] <sinzui> hi bac
[18:04] <mup> Bug #1451385 was opened: LDS 15.04 - OpenStack - lxc fails to retrieve tmpl to clone <canonical-bootstack> <juju-core:New> <Landscape Server:Incomplete> <https://launchpad.net/bugs/1451385>
[19:00] <katco> wwitzel3: ericsnow: you guys are kicking butt. wwitzel3: way to step up and help ericsnow out.
[19:00] <ericsnow> wwitzel3: +1
[19:04] <perrito666> hello all
[19:05] <perrito666> mgz_: better here?
[19:06] <perrito666> or do we turn this into an email
[19:06] <perrito666> ?
[19:06] <perrito666> and by we I mean you?
[19:06] <perrito666> :p
[19:06] <mgz_> perrito666: we fine
[19:06] <mgz_> perrito666: so, `juju authorised-keys import --help`
[19:07] <mgz_> we can't break cli in that the command still needs to work as written
[19:07] <mgz_> but we can certainly do stuff like making the errors printed saner if we get structured data back over new api
[19:07] <mgz_> or add a -v flag to do something other than silence in the success case
[19:08] <perrito666> I would go for an extra flag
[19:08] <perrito666> I have to ssume that someone is expecting the current output
[19:08] <mgz_> for printing stuff to stdout, sure
[19:08] <mgz_> not for changing the error message output
[19:08] <mgz_> we've already done that
[19:08] <mgz_> twice
[19:09] <perrito666> fair
[19:09] <mgz_> very few scripts are going to pipe stderr somewhere then care about its contents, and certainly not for manual-ish commands like this
[19:10] <mgz_> (it is being scripted by the plugin mentioned in the bug, but that's a straight exec type thing)
[19:12] <perrito666> mgz_: ok so, fwport the fix from 1.23 to 1.24 and then master gets the revamped one, makes sense?
[19:13] <mgz_> yup
[19:13] <katco> rick_h_: got a minute to chat about juju min version?
[19:14] <rick_h_> not at the moment otp
[19:14] <rick_h_> katco: ^
[19:14] <katco> rick_h_: no worries... ping me when you're free?
[19:14] <rick_h_> katco: sure thing
[19:32] <mup> Bug #1452422 was opened: Cannot boostrap from custom image-metadata-url or by specifying metadata-source <sts> <juju-core:New> <https://launchpad.net/bugs/1452422>
[19:34] <katco> i need a volunteer to triage bug 1452422 that is NOT already working on critical issues
[19:34] <mup> Bug #1452422: Cannot boostrap from custom image-metadata-url or by specifying metadata-source <sts> <juju-core:New> <https://launchpad.net/bugs/1452422>
[19:36] <katco> cherylj: perrito666: ^^
[19:39] <mgz_> katco: I got it
[19:39] <katco> mgz_: ty
[20:05] <rick_h_> katco: still free?
[20:05] <katco> rick_h_: yep
[20:20] <mup> Bug #1450706 changed: juju-core 1.23.2 fails with an error on destroying a local environment on vivid <destroy-environment> <systemd> <upstart> <vivid> <juju-core:Triaged> <juju-core 1.23:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1450706>
[20:29] <mup> Bug #1450706 was opened: juju-core 1.23.2 fails with an error on destroying a local environment on vivid <destroy-environment> <systemd> <upstart> <vivid> <juju-core:Triaged> <juju-core 1.23:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1450706>
[20:32] <mup> Bug #1450706 changed: juju-core 1.23.2 fails with an error on destroying a local environment on vivid <destroy-environment> <systemd> <upstart> <vivid> <juju-core:Triaged> <juju-core 1.23:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1450706>
[21:10] <davecheney> thumper: did the hangout drop for anyone else ?
[21:10] <thumper> davecheney: nope
[21:10] <davecheney> maybe it's google deciding i need to refresh my credentials
[21:15] <davecheney> sinzui: https://bugs.launchpad.net/ubuntu/+source/golang/+bug/1452457
[21:15] <mup> Bug #1452457: Please import golang-1.4.2 from debian/sid <golang (Ubuntu):New> <https://launchpad.net/bugs/1452457>
[21:15] <davecheney> bug for raising the version of go in W
[21:15] <davecheney> sinzui: how do I target this to W only ?
[21:16] <sinzui> davecheney, we don't have permission to nominate a series
[21:17] <sinzui> davecheney, maybe we should subscribe strikov and rbasak
[21:17] <davecheney> sound good
[21:17] <davecheney> i love giving others work, remotely
[21:18] <sinzui> and done
[21:19] <davecheney> mazel tov
[21:28] <davecheney> alexisb: thanks for the linaro connect, the linaro folks are being very responsive
[21:28] <alexisb> davecheney, you are most welcome and I am very glad
[21:29] <alexisb> I also got your hardware order in and am working shipping details with an apm ops lady - who is also very responsive and nice
[21:29] <thumper> o/ alexisb
[21:29] <thumper> alexisb: did you want to catch up today?
[21:29] <alexisb> so hopefully arm hardware woes are past us
[21:29] <alexisb> thumper, we should
[21:29] <alexisb> about to go into an hour of meetings
[21:29] <alexisb> but I can ping you when I am done
[21:30] <thumper> sure
[21:56] <davecheney> alexisb: aaand, i'm in
[21:56] <davecheney> 30 muntes to get access to linaro arm hardware
[21:56] <davecheney> 3 months to get access to canonical arm hardware ...
[21:57] <alexisb> yay!
[21:57] <alexisb> well on the access part
[21:58] <davecheney> they appear to be running a very similar kernel
[21:58] <davecheney> i wonder if i'll be able to trigger the bug ...
[21:58] <davecheney> kernel bug that is
[22:02] <mup> Bug #1435644 changed: private cloud:( environment is openstack )index file has no data for cloud <metadata> <juju-core:Triaged> <https://launchpad.net/bugs/1435644>
[22:10] <sinzui> wallyworld, re: bug 1442719. This is a case where the affected series is very old. and even if we try to fix it, there is no guarantee that users will get a 1.20.15
[22:10] <mup> Bug #1442719: juju sync-tools fails with windows streams <sync-tools> <windows> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1442719>
[22:10] <wallyworld> sinzui: maybe mark as won't fix?
[22:10] <sinzui> wallyworld, I think we need to confirm the issue is not in 1.21 and above and maybe move my work around into the description
[22:11] <wallyworld> sinzui: sounds reasonable
[22:11] <sinzui> wallyworld, well I don't see how the bug can be in 1.21 because that is the series that introduced windows streams
[22:11] <wallyworld> yes
[22:12] <sinzui> wallyworld, yes, it is not possible because generate-tools made the data
[22:12] <sinzui> wallyworld, so, wont fix and update work around
[22:12] <wallyworld> +1
[22:15] <wallyworld> alexisb: sorry, google hates me, still trying to get in
[22:16] <alexisb> lol
[22:16] <alexisb> I thought it was on my side
[22:16] <alexisb> I just restarted chrome
[22:20] <sinzui> waigani_, We think bug 1384549 is out of scope for 1.24. I want to delete the 1.24 task on the bug that says you are working on it now
[22:20] <mup> Bug #1384549: Running Juju ensure-availability twice in a row adds extra machines <canonical-bootstack> <canonical-is> <ha> <maas-provider> <juju-core:Triaged> <juju-core 1.24:In Progress by waigani> <https://launchpad.net/bugs/1384549>
[22:22] <ericsnow> wallyworld: we have several fixes up that aren't blockers but need to land for the next 1.24 release...
[22:22] <wallyworld> ericsnow: otp, be with you soon
[22:22] <ericsnow> wallyworld: np
[22:26] <mup> Bug #1442719 changed: juju sync-tools fails with windows streams <sync-tools> <windows> <juju-core:Won't Fix> <https://launchpad.net/bugs/1442719>
[22:28] <waigani_> sinzui: yep. I've unassigned myself. Thanks for the heads up.
[22:29] <sinzui> np waigani_
[22:32] <voidspace> gah, adding logging to golxc - by default logs to stdout, which results in the logging lines going to the tools version output by jujud so I can't bootstrap (invalid tools version)
[22:33] <voidspace> have to reconfigure logging for golxc
[22:41] <thumper> voidspace: ahh... wat?
[22:41] <thumper> voidspace: IIRC, no
[22:41] <thumper> voidspace: happy to chat about logging with you
[22:42] <voidspace> thumper: hey, hi
[22:42] <voidspace> thumper: I just changed a logging call in golxc from logger.Tracef to Warningf and suddenly couldn't bootstrap
[22:42] <voidspace> ERROR failed to bootstrap environment: cannot upload bootstrap tools: invalid version "2015-05-06 22:20:30 WARNING golxc.run.lxc-config golxc.go:448 run: lxc-config [lxc.lxcpath]\n2015-05-06 22:20:30 WARNING golxc.run.lxc-config golxc.go:448 run: lxc-config [lxc.lxcpath]\n1.23.3.1-trusty-amd64" printed by jujud
[22:43] <voidspace> thumper: so what do you mean by "no"
[22:43] <thumper> voidspace: haha
[22:43] <thumper> ah
[22:43] <thumper> voidspace: hangout?
[22:43] <voidspace> thumper: sure
[22:44] <thumper> voidspace: https://plus.google.com/hangouts/_/canonical.com/golxc
[22:45] <voidspace> thumper: omw
[22:48] <thumper> export JUJU_LOGGING_CONFIG=juju=DEBUG;golxc=TRACE
[22:57] <thumper> juju set-env logging-config=...
[22:59] <alexisb> thumper, I am free for a while if you are available to chat
[22:59] <wallyworld> ericsnow: so, thse fixes, you going to land them?
[22:59] <thumper> alexisb: yep
[22:59] <thumper> alexisb: our normal hangout?
[22:59] <ericsnow> wallyworld: landing is blocked
[22:59] <wallyworld> oh, i see, didn't realise
[22:59] <alexisb> yep
[23:00] <sinzui> ericsnow, wallyworld I don't see any critical blockers
[23:00] <wallyworld> sinzui: me either
[23:00] <wallyworld> i just checked
[23:01] <wallyworld> ericsnow: why do you say landings are blocked?
[23:01] <ericsnow> "Build failed: Does not match ['fixes-1444861', 'fixes-1451297']"
[23:01] <sinzui> That isn't even a ci bug
[23:02] <wallyworld> ericsnow: that isn't blocking 1.24
[23:02]  * sinzui checks code on server
[23:02] <wallyworld> but it does block 1.23
[23:02] <ericsnow> wallyworld: ah, I was trying to merge into 1.23 (and then forward-port)
[23:02] <wallyworld> i'll reduce to high
[23:02] <wallyworld> no reason to be critical for 1.23 and high for 1.24 IMO
[23:03] <sinzui> bug 1451297 is fix release in master and 1.24. the bug is closed from CI's view
[23:03] <mup> Bug #1451297: Upgrade from 1.18 to 1.23 fails: password for machine agent can't be set <blocker> <regression> <juju-core:Fix Released by menno.smits> <juju-core 1.23:Fix Committed by menno.smits> <juju-core 1.24:Fix Released by menno.smits> <https://launchpad.net/bugs/1451297>
[23:04] <sinzui> wallyworld, that bug was only critical while there wasn't a fix, but still, 1.24 and master haven't been blocked for 1.5 days
[23:04] <wallyworld> sinzui: ericsnow was trying to land in 1.23 first. that was blocked but i degraded a bug to high
[23:04] <sinzui> me too :)
[23:05] <wallyworld> to match it's severity on 1.24 and master
[23:05] <wallyworld> lol
[23:05] <wallyworld> ericsnow: try again
[23:05] <sinzui> severity is different for each branch
[23:05] <ericsnow> wallyworld: trying
[23:05] <wallyworld> sinzui: agreed, but in this case....
[23:05] <wallyworld> i think high is ok
[23:07] <sinzui> ah ericsnow wallyworld are you using the check blocker's script from 2 weeks ago. The current script has a different command line
[23:07] <wallyworld> sinzui: i just use a lp query
[23:08] <wallyworld> i guess i could or should use the script
[23:12] <sinzui> wallyworld, You will probably be angry because it wants you to login even for anon requests.
[23:12] <sinzui> we haven't fixed it yet
[23:12] <wallyworld> sinzui: np, i'll stick with my bookmark :-)
[23:14] <mup> Bug #1452490 was opened: jujud version fetched with combined output for bootstrap tools <papercut> <juju-core:New> <https://launchpad.net/bugs/1452490>
[23:31] <alexisb> davecheney, I am on our 1x1 hangout if you would like to meet today
[23:41] <wallyworld> sinzui: so bug 1444912, just confirming, we will mark as Incomplete
[23:45] <davecheney> alexisb: oh, is that today ?
[23:45] <davecheney> it's not on my calendar
[23:45] <davecheney> but you're ill and i have nothing to say
[23:45] <davecheney> so let's skip it
[23:45] <alexisb> davecheney, heh ok
[23:45] <alexisb> davecheney, I trust you know how to reach out to me if needed
[23:46] <davecheney> alexisb: history has shown that to be true :)
[23:47] <alexisb> :)