[01:36] Bug #1494542 opened: config-changed error does not cause error state

[07:01] jam, ping - 1:1 ? [08:04] dimitern: sorry I missed you, maybe chat after standup? [08:04] jam, ok, sure [09:01] jam, frobware, TheMue, standup? [09:03] sorry, phone call, will join in a moment [09:08] fwereade, ping? [09:08] mattyw, pong [09:09] fwereade, hey hey, would you have 10 minutes for a little chat about http://reviews.vapour.ws/r/2746/ [09:09] mattyw, in 10-20 mins? meeting atm [09:10] fwereade, ping me when you're around [09:20] 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] dimitern, dooferlad: I'm back... I also scheduled a planning session in 30 mins. [09:33] frobware: ack [09:34] frobware, I guess you didn't get my earlier message === perrito667 is now known as perrito666 [09:34] dimitern, nope [09:34] 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] dimitern, fair enough and as long as we have enough scheduled until then. [09:35] frobware, I think we do [09:38] jam, do you think "storage.fast" needs to be part of the constraints accepted syntax for maas? [09:39] jam, I was thinking the constraints should be generic and the bindings define the specific parts, like fabric class [09:40] 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] dimitern: i would have actually expected the constraints to match the binding syntax [09:40] dimitern: from the model of "constraints are just about placement" [09:41] 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] which are what bindings will be used for services deployed to that machine [09:41] (or containers on that machine) [09:43] jam, are you saying we should support [@|^][.] in constraints? [09:43] I think this unnecessarily complicates things [09:52] dimitern: I'm not suggesting "plug" in constraints [09:53] 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] you need a way to "add-machine" that is in the right spaces and fabrics to be able to "deploy plug@" [09:54] jam, right, then constraints like spaces=foo.bar are passed literally to maas [09:54] right [09:55] jam, ok, we're in agreement then :) [09:55] jam, I'll update the docs to reflect this [09:57] dimitern: python is there in the default Ubuntu image that MAAS installs. [09:58] dimitern: i.e. images/ubuntu/amd64/generic/trusty/release/root-tgz so I guess that is a default cloud image [09:58] 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] dooferlad, awesome! [09:59] jam: good to know. I thought it had to be there, but I just wanted to check === akhavr1 is now known as akhavr [10:43] 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] dimitern: will do [10:51] dooferlad, cheers [11:08] dimitern, published some comments. Given the size of the script you could also run it through http://www.shellcheck.net/about.html [11:09] frobware, I didn't know that checker, will do - thanks for the review! [13:05] Bug #1506866 opened: Juju delays ~15min to update the unit public address with a Nova floating IP === cmars` is now known as cmars [13:20] dimitern: how exactly do you want me to test that branch? [13:28] dooferlad, you have your maas working right? [13:28] dooferlad, 1.9 [13:28] dimitern: I am on 1.8 [13:28] dooferlad, ah, I see [13:28] dimitern: do you want me to upgrade? [13:29] dooferlad, well, it should work on 1.8 (haven't tested) [13:30] 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] 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] dooferlad, it applies only without the feature flag [13:30] dimitern: OK, will do. [13:31] dimitern: I don't like that we have juju-br0, but that is for another time! [13:31] 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] 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] 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] dooferlad, but it's a good idea to upgrade to 1.9 soon :) === akhavr1 is now known as akhavr [13:59] Bug #1507601 opened: TestStartTerminationWorker fails on gccgo

=== BradCrittenden is now known as Guest53960 [14:56] Bug #1507637 opened: Bootstrap and provisioning fail with internal error tagging instance

[15:05] Bug #1507644 opened: backup i/o timeout

[15:14] Bug #1507644 changed: backup i/o timeout

[15:17] Bug #1507644 opened: backup i/o timeout

[15:57] what could provoke for juju agent to uninstall itself? [16:02] perrito666: bug 1464304 [16:02] Bug #1464304: Sending a SIGABRT to jujud process causes jujud to uninstall (wiping /var/lib/juju)

=== Makyo is now known as Guest23950 [16:41] 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] Bug #1491592: local provider uses the wrong interface

[16:42] mgz, and is also fixed in 1.24.7 [16:42] frobware: just fix committed if it'll be in the next 1.25 [16:43] frobware: were there particular commits that got landed? [16:44] I can retroactively add it to the 1.24.7 milestone if needed [16:44] 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] mgz, not sure; might have been this fix https://bugs.launchpad.net/juju-core/+bug/1435283 [16:44] Bug #1435283: juju occasionally switches a units public-address if an additional interface is added post-deployment

[16:44]

[16:45] that seems likely [16:45] I'm tempted to just dupe into that bug [16:45] mgz, your call. was just trying to close it out now I know where we stand. [16:45] frobware: I'll poke things [16:45] mgz, gracias [16:55] mgz: I was not aware that was still standing [16:56] perrito666: as of today, it's not :) [16:57] mgz: am I lucky [16:58] or you're just fashionably late :9) [17:06] Bug #1491592 changed: local provider uses the wrong interface

[17:09] Bug #1491592 opened: local provider uses the wrong interface

[17:15] Bug #1491592 changed: local provider uses the wrong interface

[18:43] meh, no dimitern [19:56] morning [19:58] thumper: morning, early? [19:58] not really [19:58] clocks went forward some weeks back [19:58] almost 9am here now [19:58] wow ok [21:09] Bug #1507771 opened: Juju deploy fails when template container cannot be started

[21:18] Bug #1507771 changed: Juju deploy fails when template container cannot be started

[21:21] Bug #1507771 opened: Juju deploy fails when template container cannot be started

[21:40] sinzui: will uploading the revising juju packaging with deps interfer with your 1.24.7 efforts in any way? [21:40] mgz: No, 1.25 is a separate effort [21:52] 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] 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] Bug #1506680: `juju environments` fails due to missing ~/.juju/current-environment

[21:59] 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] wallyworld: the many commits to master, 1.25, and feature-payloads prevent your two branches from being tested. [21:59] cherylj: +1 [22:01] :-( [22:02] 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] no they are not [22:02] but [22:03] i really am looking forward to not having feature branches wither on the vine [23:09] mgz: thanks for fixing the gccgo build failure [23:11] axw: no worries [23:16] wallyworld: my camera decided to stop working, trying to fix now [23:16] ok