[01:36] <mup> Bug #1494542 opened: config-changed error does not cause error state <hooks> <juju-core:In Progress by axwalk> <juju-core 1.24:Fix Released by thumper> <juju-core 1.25:Fix Released by thumper> <https://launchpad.net/bugs/1494542>
[07:01] <dimitern> jam, ping - 1:1 ?
[08:04] <jam> dimitern: sorry I missed you, maybe chat after standup?
[08:04] <dimitern> jam, ok, sure
[09:01] <dimitern> jam, frobware, TheMue, standup?
[09:03] <TheMue> sorry, phone call, will join in a moment
[09:08] <mattyw> fwereade, ping?
[09:08] <fwereade> mattyw, pong
[09:09] <mattyw> fwereade, hey hey, would you have 10 minutes for a little chat about http://reviews.vapour.ws/r/2746/
[09:09] <fwereade> mattyw, in 10-20 mins? meeting atm
[09:10] <mattyw> fwereade, ping me when you're around
[09:20] <dimitern> frobware, TheMue, I've suggested to skip the planning today and instead do it as scheduled on friday, with a "double retro" for this and the last iteration
[09:33] <frobware> dimitern, dooferlad: I'm back... I also scheduled a planning session in 30 mins.
[09:33] <dooferlad> frobware: ack
[09:34] <dimitern> frobware, I guess you didn't get my earlier message
[09:34] <frobware> dimitern, nope
[09:34] <dimitern> frobware, TheMue, I've suggested to skip the planning today and instead do it as scheduled on friday, with a "double retro" for this and the last iteration
[09:34] <frobware> dimitern, fair enough and as long as we have enough scheduled until then.
[09:35] <dimitern> frobware, I think we do
[09:38] <dimitern> jam, do you think "storage.fast" needs to be part of the constraints accepted syntax for maas?
[09:39] <dimitern> jam, I was thinking the constraints should be generic and the bindings define the specific parts, like fabric class
[09:40] <dimitern> jam, so in order to get to the arguments we need to pass to acquire node, we combine constraints and bindings (the latter overriding the more generic former)
[09:40] <jam> dimitern: i would have actually expected the constraints to match the binding syntax
[09:40] <jam> dimitern: from the model of "constraints are just about placement"
[09:41] <jam> and if we want to deploy 2 services on a machine, then that machine needs to be somewhere that can match these constraints
[09:41] <jam> which are what bindings will be used for services deployed to that machine
[09:41] <jam> (or containers on that machine)
[09:43] <dimitern> jam, are you saying we should support [<plug>@|^]<space>[.<class>] in constraints?
[09:43] <dimitern> I think this unnecessarily complicates things
[09:52] <jam> dimitern: I'm not suggesting "plug" in constraints
[09:53] <jam> but you need a way to say "I'm about to create a machine, for which I'm going to deploy services on it"
[09:53] <jam> you need a way to "add-machine" that is in the right spaces and fabrics to be able to "deploy plug@"
[09:54] <dimitern> jam, right, then constraints like spaces=foo.bar are passed literally to maas
[09:54] <jam> right
[09:55] <dimitern> jam, ok, we're in agreement then :)
[09:55] <dimitern> jam, I'll update the docs to reflect this
[09:57] <dooferlad> dimitern: python is there in the default Ubuntu image that MAAS installs.
[09:58] <dooferlad> dimitern: i.e. images/ubuntu/amd64/generic/trusty/release/root-tgz so I guess that is a default cloud image
[09:58] <jam> dooferlad: traditionally ubuntu used upstart which is python based so it *had* to have python, I'm not sure if it could be removed now, but IIRC python is still part of a bunch of core bits
[09:59] <dimitern> dooferlad, awesome!
[09:59] <dooferlad> jam: good to know. I thought it had to be there, but I just wanted to check
[10:43] <dimitern> dooferlad, when you have some time, I'd appreciate if you can independently test my juju-br0 script changes on your maas(es?) with 1.25: https://github.com/juju/juju/pull/3539
[10:44] <dooferlad> dimitern: will do
[10:51] <dimitern> dooferlad, cheers
[11:08] <frobware> dimitern, published some comments. Given the size of the script you could also run it through http://www.shellcheck.net/about.html
[11:09] <dimitern> frobware, I didn't know that checker, will do - thanks for the review!
[13:05] <mup> Bug #1506866 opened: Juju delays ~15min to update the unit public address with a Nova floating IP <juju-core:New> <https://launchpad.net/bugs/1506866>
[13:20] <dooferlad> dimitern: how exactly do you want me to test that branch?
[13:28] <dimitern> dooferlad, you have your maas working right?
[13:28] <dimitern> dooferlad, 1.9
[13:28] <dooferlad> dimitern: I am on 1.8
[13:28] <dimitern> dooferlad, ah, I see
[13:28] <dooferlad> dimitern: do you want me to upgrade?
[13:29] <dimitern> dooferlad, well, it should work on 1.8 (haven't tested)
[13:30] <dimitern> dooferlad, how about this: bootstrap --upload-tools --to somenode.maas on 1.8 and then add-machine/deploy+add-unit --to lxc:0
[13:30] <dooferlad> dimitern: I was more asking about the juju changes. Is it a case of turning off the addressable containers flag and deploying a machine?
[13:30] <dimitern> dooferlad, it applies only without the feature flag
[13:30] <dooferlad> dimitern: OK, will do.
[13:31] <dooferlad> dimitern: I don't like that we have juju-br0, but that is for another time!
[13:31] <dimitern> dooferlad, basically, I've tested: 1)bootstrap --to (with various network setups on a NUC with 2 NICs - second one usb2eth adapter); 2) add-machine/add-unit --to lxc and kvm
[13:32] <dimitern> and made sure all machines come up (eventually, I'm experiencing slow downs due to c-i waiting 120+ secs before yielding the node to juju after provisioning) with the proper IPs
[13:33] <dimitern> dooferlad, use your CI script - it should be easy to test with the feature flag and without on 1.8 (to ensure no regressions)
[13:33] <dimitern> dooferlad, but it's a good idea to upgrade to 1.9 soon :)
[13:59] <mup> Bug #1507601 opened: TestStartTerminationWorker fails on gccgo <ci> <gccgo> <ppc64> <regression> <test-failure> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1507601>
[14:56] <mup> Bug #1507637 opened: Bootstrap and provisioning fail with internal error tagging instance <bootstrap> <ci> <ec2-provider> <intermittent-failure> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1507637>
[15:05] <mup> Bug #1507644 opened: backup i/o timeout <backup-restore> <ci> <intermittent-failure> <juju-core:New> <https://launchpad.net/bugs/1507644>
[15:14] <mup> Bug #1507644 changed: backup i/o timeout <backup-restore> <ci> <intermittent-failure> <juju-core:New> <https://launchpad.net/bugs/1507644>
[15:17] <mup> Bug #1507644 opened: backup i/o timeout <backup-restore> <ci> <intermittent-failure> <juju-core:New> <https://launchpad.net/bugs/1507644>
[15:57] <perrito666> what could provoke for juju agent to uninstall itself?
[16:02] <mgz> perrito666: bug 1464304
[16:02] <mup> Bug #1464304: Sending a SIGABRT to jujud process causes jujud to uninstall (wiping /var/lib/juju) <sts> <juju-core:Fix Committed by axwalk> <juju-core 1.25:Fix Committed by axwalk> <https://launchpad.net/bugs/1464304>
[16:41] <frobware> mgz, regarding https://bugs.launchpad.net/juju-core/+bug/1491592 - the bug has already been fixed in 1.25. Is it best to set the state for that to "Invalid", or something else?
[16:41] <mup> Bug #1491592: local provider uses the wrong interface <charmers> <customer-support> <kvm> <local-provider> <networking> <juju-core:In Progress by frobware> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1491592>
[16:42] <frobware> mgz, and is also fixed in 1.24.7
[16:42] <mgz> frobware: just fix committed if it'll be in the next 1.25
[16:43] <mgz> frobware: were there particular commits that got landed?
[16:44] <mgz> I can retroactively add it to the 1.24.7 milestone if needed
[16:44] <mgz> if it's just we fixed this at some point and don't really know when, just mark fix released and remove milestone
[16:44] <frobware> mgz, not sure; might have been this fix https://bugs.launchpad.net/juju-core/+bug/1435283
[16:44] <mup> Bug #1435283: juju occasionally switches a units public-address if an additional interface is added post-deployment <addressability> <bug-squad> <network> <openstack-provider>
[16:44] <mup> <juju-core:Fix Released by mfoord> <juju-core 1.24:Fix Released by mfoord> <juju-core 1.25:Fix Released by mfoord> <https://launchpad.net/bugs/1435283>
[16:45] <mgz> that seems likely
[16:45] <mgz> I'm tempted to just dupe into that bug
[16:45] <frobware> mgz, your call. was just trying to close it out now I know where we stand.
[16:45] <mgz> frobware: I'll poke things
[16:45] <frobware> mgz, gracias
[16:55] <perrito666> mgz: I was not aware that was still standing
[16:56] <mgz> perrito666: as of today, it's not :)
[16:57] <perrito666> mgz: am I lucky
[16:58] <mgz> or you're just fashionably late :9)
[17:06] <mup> Bug #1491592 changed: local provider uses the wrong interface <charmers> <customer-support> <kvm> <local-provider> <networking> <juju-core:Fix Released> <juju-core 1.24:Fix Released> <https://launchpad.net/bugs/1491592>
[17:09] <mup> Bug #1491592 opened: local provider uses the wrong interface <charmers> <customer-support> <kvm> <local-provider> <networking> <juju-core:Fix Released> <juju-core 1.24:Fix Released> <https://launchpad.net/bugs/1491592>
[17:15] <mup> Bug #1491592 changed: local provider uses the wrong interface <charmers> <customer-support> <kvm> <local-provider> <networking> <juju-core:Fix Released> <juju-core 1.24:Fix Released> <https://launchpad.net/bugs/1491592>
[18:43] <perrito666> meh, no dimitern
[19:56] <thumper> morning
[19:58] <rick_h_> thumper: morning, early?
[19:58] <thumper> not really
[19:58] <thumper> clocks went forward some weeks back
[19:58] <thumper> almost 9am here now
[19:58] <rick_h_> wow ok
[21:09] <mup> Bug #1507771 opened: Juju deploy fails when template container cannot be started <cdo-qa> <juju-core:New> <https://launchpad.net/bugs/1507771>
[21:18] <mup> Bug #1507771 changed: Juju deploy fails when template container cannot be started <cdo-qa> <juju-core:Triaged> <https://launchpad.net/bugs/1507771>
[21:21] <mup> Bug #1507771 opened: Juju deploy fails when template container cannot be started <cdo-qa> <juju-core:Triaged> <https://launchpad.net/bugs/1507771>
[21:40] <mgz> sinzui: will uploading the revising juju packaging with deps interfer with your 1.24.7 efforts in any way?
[21:40] <sinzui> mgz: No, 1.25 is a separate effort
[21:52] <sinzui> mgz:  and I now know We need a wily machine to make source packages. I will get something to test, then solve future building needs
[21:54] <sinzui> cherylj: I just targted this: you can choose to remove it from 1.25 if it isn't a goal https://bugs.launchpad.net/juju-core/+bug/1506680
[21:54] <mup> Bug #1506680: `juju environments` fails due to missing ~/.juju/current-environment <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1506680>
[21:59] <cherylj> thanks, sinzui.  I'm thinking it should be targeted to 1.25.1, since I don't think we're going to be removing the JES feature flag until 1.26
[21:59] <sinzui> wallyworld: the many commits to master, 1.25, and feature-payloads prevent your two branches from being tested.
[21:59] <sinzui> cherylj: +1
[22:01] <wallyworld> :-(
[22:02] <sinzui> wallyworld: 1.25 and master were tested 20 times, payloads 4 times and chicago-cubs 2 times. Your branches are not more important than master
[22:02] <wallyworld> no they are not
[22:02] <wallyworld> but
[22:03] <wallyworld> i really am looking forward to not having feature branches wither on the vine
[23:09] <axw> mgz: thanks for fixing the gccgo build failure
[23:11] <mgz> axw: no worries
[23:16] <axw> wallyworld: my camera decided to stop working, trying to fix now
[23:16] <wallyworld> ok