[00:41] Bug #1521017 opened: adding a ssh key to juju does not take a file path [00:41] Bug #1521020 opened: juju authorized-keys import fails without any output [00:44] Bug #1521017 changed: adding a ssh key to juju does not take a file path [00:44] Bug #1521020 changed: juju authorized-keys import fails without any output [00:54] https://github.com/godbus/dbus/issues/45 [00:54] no love [00:54] guess we'll be fixing that one [00:55] quit [00:56] Bug #1521017 opened: adding a ssh key to juju does not take a file path [00:56] Bug #1521020 opened: juju authorized-keys import fails without any output === marcoceppi_ is now known as marcoceppi [01:54] wallyworld or axw: I suspect this might make you happy: http://reviews.vapour.ws/r/3269/ [01:54] yay [01:55] menn0: i did go to review your PR from last week but it already had a shipit by the time i got there [01:56] wallyworld: yep, no worries. already landed. this new one depended on that one. [02:01] menn0: lgtm [02:04] wallyworld: cheers [02:21] wallyworld: BTW, I've renamed params.RelationUnitsChange to params.RemoteRelationUnitsChange, because we'll use tokens and so on [02:21] ok [02:21] wallyworld: so I think there shouldn't be a concern about overlap with the existing RelationUnitsChange any more [02:22] that sounds right === Ursinha__ is now known as Ursinha_ [04:33] axw: could you have a quick look at this one please: http://reviews.vapour.ws/r/3270/ [04:33] menn0: sure [04:33] axw: there's another upgradesteps cleanup PR ready straight after this one [04:37] menn0: LGTM [04:37] axw: cheers [04:56] axw: last cleanup PR here: http://reviews.vapour.ws/r/3271/ [04:57] looking [05:05] menn0: done [05:48] axw: thanks [09:00] jam: rebooting... be there in a bit... === psivaa-afk is now known as psivaa [09:11] dimitern: looks like I finally connected... [09:16] voidspace, welcome ;) [09:22] dimitern: shall I just recreate that branch based on a clean patch? [09:22] dimitern: no need for you to do it [09:24] voidspace, yes please - that will be easiest I think [09:24] doing it [09:34] dimitern: http://reviews.vapour.ws/r/3273/ [09:34] voidspace, cheers, looking [09:34] dimitern: it's already had a "Ship It" as a previous PR, so need to look again particularly [09:34] dimitern: I'm doing a full test run here [09:34] dimitern: and we need to talk about implementation strategy for listing spaces on bootstrap [09:34] dimitern: we can topic that at/after standup though [09:35] voidspace, LGTM [09:35] voidspace, sure [09:38] dimitern: ta [09:38] dimitern: waiting for the test run here to finish before I hit $$merge$$ [09:40] voidspace, ack === Makyo is now known as Guest57414 [09:45] anyone seen this failure with the lxd client test? [09:45] ERROR juju.utils cannot find network interface "lxcbr0": no such network interface [09:45] this is on maas-spaces feature branch, so there may already be a fix on master that we haven't picked up === JoseeAntonioR is now known as jose [10:01] jam: fwereade: dimitern: standup? [10:01] frobware, voidspace, fwereade, omw - 1m [10:33] frobware: I need coffee [10:34] voidspace, me too. 5 mins? [10:35] frobware: sounds good [10:41] frobware: ready when you are === ahasenac` is now known as ahasenack [11:29] frobware: I get the same failures on master, so no *requirement* for an urgent rebase [11:29] voidspace, ack [13:26] hello all btw [14:46] Bug #1519527 opened: juju 1.25.1: lxc units all have the same IP address

[14:46] Bug #1521217 opened: TestWorkerAcceptsBrokenRelease fails

[14:55] Bug #1521220 opened: TestShortPollIntervalExponent fails

[15:01] Bug #1521220 changed: TestShortPollIntervalExponent fails

[15:03] dimitern: is the issue with bug 1519527 just that in 1.25.1 juju uses some new MAAS functionality which is not working as expected? [15:03] Bug #1519527: juju 1.25.1: lxc units all have the same IP address - changed to claim_sticky_ip_address

by mpontillo>

[15:03] cherylj, that's my understanding (proved by mpontillo as well) [15:04] or at least observed to not work as expected [15:04] dimitern: what about other levels of MAAS? does the functionality exist on older levels, but works there? [15:06] cherylj, yes, it exists in 1.8 and is confirmed to work there as expected, so it's a maas 1.9beta2+ regression [15:06] dimitern: thanks! [15:16] Bug #1521220 opened: TestShortPollIntervalExponent fails

[15:17] dimitern: sorry to bug you again :) a note from mgz indicated that you might be working on bug 1516989? [15:18] Bug #1516989: juju status broken

[15:18] hi cherylj, dimitern - i just re-deployed with MAAS 1.9b2 + Juju 1.25.0, and all lxc units get unique and working IP addresses. With 1.9b2 + 1.25.1, all lxc units get the same IP. While it may be an underlying MAAS bug, there is definitely a regression in 1.25.1 Juju. Will be adding a generic non-openstack reproducer as soon as this next deploy wraps up. [15:18] cherylj, I haven't started yet, but I plan to start tomorrow on that one [15:18] beisner, it's still a maas issue [15:18] beisner, hey btw :) [15:18] dimitern, i don't disagree. [15:19] dimitern: okay, I can pass it off to onyx since they're on bug squad [15:19] beisner, you can verify by trying to create a device + parent and then claim-sticky-ip-address for it [15:19] dimitern, but i do know that if 1.25.1 lands, my lab will be borked. i presume others who are less-automated will eventually see it too. [15:19] beisner: yeah, we don't plan on moving 1.25.1 out of proposed until the MAAS fix has been released [15:20] cherylj, much appreciated [15:22] cherylj: beisner <3 ty both for working through that. === Makyo is now known as Guest54187 [15:37] dimitern, voidspace: http://reviews.vapour.ws/r/3275/ - I'm still doing some manual testing against MAAS 1.8/1.9 and precise, trustu, vivid & wily but if you could take an initial look would be appreciated. [15:37] / [15:37] / [15:37] frobware, sure, looking [15:38] frobware: cool === Ursinha_ is now known as Ursinha === kwmonroe_ is now known as kwmonroe [15:54] o/ rick_h_ yw, happy to help exercise these things [16:16] frobware, ping [16:17] dimitern, pong [16:18] frobware, I'm a bit confused - do we use bash or python or both? [16:18] dimitern, boht [16:18] both [16:19] dimitern, I could do 90% python. in fact I did for a while. but we will always need the bash shim to run the python script. [16:19] dimitern, want to HO? [16:19] frobware, right [16:19] frobware, got it [16:20] frobware, can do a HO, but the script looks fine [16:20] dimitern, let's do 10 mins anyway. would be good to talk about it. [16:20] frobware, ok [16:21] dimitern, standup HO? [16:21] frobware, sure, omw [16:40] cherylj: dimitern: I'm currently fixing a separate issue in MAAS IP allocation which is blocking me from fully triaging, but from what I saw last week, it's a MAAS issue [16:40] thanks, mpontillo [16:42] cherylj, I think dimitern and Andreas were going to re-setup their MAAS setup from scratch just to be sure though; did that happen? [16:42] mpontillo: I'm not sure. dimitern? [16:54] dimitern: ping if you're still around [17:03] mpontillo, I have rc2 installed from scratch in lxc, will test with it tomorrow as I'm fixing the related juju bug [17:03] cherylj, ^^ [17:03] voidspace, pong [17:04] cherylj, I have a LGTM on 1516891 - is 1.25.2 going to be cut today? [17:04] frobware, cherylj, I'd wait for that until tomorrow TBO [17:04] frobware: I'm not sure. There are a couple bugs we're looking at for that cutoff [17:04] TBH even [17:06] cherylj, if the answer is "possibly not" I might implement some changes dimitern and I just talked about and do some additional testing tomrrow. [17:06] frobware: that should be fine [17:11] dimitern: I may not need you... [17:12] voidspace: how could you say such a thing [17:12] we all need dimitern [17:12] :D [17:12] :-) [17:26] Bug #1521267 opened: After upgrade juju status no longer works [17:35] Bug #1521267 changed: After upgrade juju status no longer works [17:53] Bug #1521267 opened: After upgrade juju status no longer works [17:56] Bug #1521267 changed: After upgrade juju status no longer works [17:59] Bug #1519403 opened: 1.24 upgrade does not set environ-uuid [18:05] Bug #1519403 changed: 1.24 upgrade does not set environ-uuid [18:08] Bug #1519403 opened: 1.24 upgrade does not set environ-uuid [18:58] well that only took 4 hours of retries. [19:16] natefinch: ? [19:17] connecting to freenode [19:18] ah, yes DoS [19:54] could anyone run go test -gocheck.list=true github.com/juju/juju/cmd/jujud/agent/... and paste me their output? [20:05] ping, anyone on call reviewer today ? http://reviews.vapour.ws/r/3266/ [20:08] Ill review it [20:10] davecheney: ship it [20:14] perrito666: ta [20:20] morning [20:21] morning thumper [20:21] morning thumper [20:23] davecheney: hey, look master is cursed due to the race build [20:24] davecheney: I'm hoping we actually caught something new and not a mistake [20:24] oh [20:24] http://reports.vapour.ws/releases/3375/job/run-unit-tests-race/attempt/630 [20:24] not a race [20:24] just a different failure [21:14] Bug #1517992 changed: juju-upgrade to 1.24.7 leaves juju state server unreachable [21:14] Bug #1521327 opened: API client talking to 1.22 server failed: method Service(1).ServicesDeploy is not implemented

[21:33] wwitzel3: ericsnow: sorry i'm taking so long; nothing for you today. we'll have lots to discuss in tomorrow's standup [21:44] Bug #1521354 opened: juju should check common failure conditions before upgrading [21:46] cherylj, davecheney: did you notice that the race detector CI job is failing due to a shell script issue: http://data.vapour.ws/juju-ci/products/version-3370/run-unit-tests-race/build-627/consoleText [21:46] katco: ok, np [21:47] Bug #1521354 changed: juju should check common failure conditions before upgrading [21:50] Bug #1521354 opened: juju should check common failure conditions before upgrading [22:05] thumper: yup, sadly not a real failure, just fat fingers [22:14] Bug #1513492 opened: add-machine with vsphere triggers machine-0: panic: juju home hasn't been initialized

[22:16] thumper: xenial, go 1.5 build is not passing [22:16] s/not/now [22:17] \o/ [22:18] Bug #1513492 changed: add-machine with vsphere triggers machine-0: panic: juju home hasn't been initialized

[22:21] Bug #1513492 opened: add-machine with vsphere triggers machine-0: panic: juju home hasn't been initialized

[22:23] thumper: juju/container contains it's own on disk lock .... [22:25] thumper: in addition to juju/utils.fslock ... [22:33] ugh [22:33] hang on [22:33] I added that [22:33] wait [22:33] wat? [22:33] yup [22:33] a different lock type? [22:33] slightly different [22:33] but not different enough [22:43] thumper: https://github.com/juju/juju/pull/3859 [22:45] Bug #1521327 changed: API client talking to 1.22 server failed: method Service(1).ServicesDeploy is not implemented

[22:45] davecheney: there are issues with this, but I'm otp right now [22:46] mkay [22:46] * davecheney waits [22:57] Bug #1521327 opened: API client talking to 1.22 server failed: method Service(1).ServicesDeploy is not implemented

[23:00] Bug #1521327 changed: API client talking to 1.22 server failed: method Service(1).ServicesDeploy is not implemented

[23:11] sinzui: ping [23:12] thumper: ping, still otp ? [23:12] yes [23:14] mkay [23:15] anastasiamac: axw: perrito666: 1 minute late, finishing another meeting [23:15] * perrito666 clocks wallyworld to make sure its 1 minute [23:16] perrito666: otp [23:19] davecheney: off the phone now, gimmie 5 minutes? [23:20] sure [23:20] hi perrito666 [23:21] sinzui: hi, I just came back from a short week off and am curious about the mongo3 package :) [23:21] perrito666: still working on it. I am right now looking at "testbed auxverb failed with exit code 255" [23:22] lovely [23:23] perrito666: I think it will be a few more days to see packages being used in tests. We are still waiting on arm hardware, so we wont be sure we are done until it is available to us (which shoudl be this week) [23:23] k, tx a lot, just needed a status upgrade [23:24] davecheney: 1:1 hangout? [23:25] thumper: why [23:25] fine, I"ll just put it here [23:25] thanks [23:26] I believe that the lock in container prefers flock, and falls back to fslock on windows [23:26] and was done because there were too many failures with fslock during container template creation [23:26] I'm going to email juju-dev about replacing fslock [23:27] I think we are spending too much time trying to fix a broken system [23:27] instead of investing a little effort into making a good, OS agnostic, dies with the process, lock [23:27] email coming soon from me about that [23:28] thumper: no argument there [23:28] i've said I want to use the linux facility to do this [23:28] sure, it's linux only [23:29] but really, so is juju to a first approximation [23:29] wrt most of that PR [23:29] What I want is an OS abstraction [23:29] i argue it's still fine to move that coed out of container [23:29] thumper: sure [23:29] davecheney: your branch doesn't change the package name of the windows build file [23:29] but if you want it to be os agnostic that will come with a reduced readter set [23:29] it'll fail for windows [23:29] right, tahnks [23:29] i'll fix that [23:29] reduced 'feature' set [23:30] I'm fine with that [23:30] thinks like fslock.IsLocked is racy [23:30] it cannot be used safely [23:30] davecheney: the xenial unit tests vote. you rock [23:30] for hte same reason there is no os.IsExists [23:30] sinzui: thanks [23:30] davecheney: is it difficult to do the same for 1.25 which will get a few more releases? [23:30] davecheney: some of the fslock "features" were added because they could, not because they should [23:30] also [23:31] thumper: precisely [23:31] they were added to work around the problem of the lock not being released when the process dies [23:31] i want to kill the with fire [23:31] * sinzui wants wily unit tests on master passing more that 1.25 on xenial [23:31] sinzui: no idea [23:31] but I can look at the failures [23:48] * thumper heading out for dogwalk