[00:06] Bug #1567598 changed: storage-get causes state server to 'error: bad request'

[00:08] perrito666: ping? [00:09] damn you schema.ForceInt [00:09] schema.Int -> int64 [00:09] scheam.ForceInt -> int [00:09] for no good reason [00:09] bah [00:10] mwhudson, it is very much past his eod, if you can open a bug with the info you have that owuld be most helpful [00:11] alexisb: ok [00:11] alexisb: was actually typing up a bug report now, as it happens :-) [00:11] perfect :) [00:14] alexisb: https://bugs.launchpad.net/juju-core/+bug/1567708 [00:15] Bug #1567708: unit tests fail with mongodb 3.2 [00:15] mwhudson, thank you! [00:15] np [00:15] some of the errors are clearly quite silly [00:16] (like the error message mongo gives when reporting an auth failure has changed) [00:16] i don't know if any are deep [00:21] Bug #1567708 opened: unit tests fail with mongodb 3.2 [00:31] evening all [00:33] Bug #1567708 changed: unit tests fail with mongodb 3.2 [00:36] axw: yt? [00:36] Bug #1567708 opened: unit tests fail with mongodb 3.2 [00:51] Bug #1567712 opened: [juju create-model] Specifying a cloud when referring to a credential is redundant

[00:51] redir_afk: "yt"? [00:53] cherylj: http://pad.lv/1566303 [00:53] did this pass CI testing ? [00:54] i have access to a windows machine now and can investigate if it's still failing [00:55] I am [00:55] axw: yt == you there [00:55] redir: oh, well, you have your answer ;) [00:55] axw: do you have a minute for a hangout? [00:55] redir: sure, see you in the tanzanite hangout [00:55] k [00:57] Bug #1567712 changed: [juju create-model] Specifying a cloud when referring to a credential is redundant

[01:03] * thumper heads out to walk the dog [01:06] Bug #1567712 opened: [juju create-model] Specifying a cloud when referring to a credential is redundant

[01:15] davecheney: no, the windows test failed again: http://reports.vapour.ws/releases/3863 [01:20] cherylj: thanks, i'll try to get on the windows test machine now [01:21] cherylj: i don't understand that page [01:21] where is the windows failure ? [01:21] run-unit-tests-win2012-amd64 [01:21] ok i see it [01:27] Bug #1567458 changed: destroy-controller message and failure is not user friendly [01:36] Bug #1567458 opened: destroy-controller message and failure is not user friendly [01:37] cherylj: so you started landing those updates? [01:37] help text updates. [01:37] redir: I made an Executive Decision [01:37] and pulled the trigger [01:37] :) [01:37] OK [01:38] menn0: https://bugs.launchpad.net/juju-core/+bug/1474607 [01:38] Bug #1474607: worker/uniter/relation: HookQueueSuite.TestAliveHookQueue failure

[01:38] so I should fix up that other one and then resubmit or just merge? [01:38] this bug is fixed on master bug fires on 1.25 [01:38] cherylj: ^^ [01:38] from memory it was a _lot_ of work to fix on master [01:38] redir: as long as you test that the help text looks right, then i'd say just merge [01:39] cherylj: OK. And have you settled on some formatting? indents all with line breaks etc? [01:40] redir: basically, I copied what was in the bug for the most part, taking care to make sure lines were < 80 characters [01:40] davecheney: that bug doesn't ring any bells for me sorry [01:40] OK. I'll do that, too, for the most part:) [01:42] cherylj: ^ [01:42] thanks, redir :) [01:44] menn0: i think this was fixed by william's manifold thinggy [01:45] davecheney: it won't be the manifold (dependency engine) stuff directly. that's got nothing to do with the uniter's internals. [01:45] Bug #1567458 changed: destroy-controller message and failure is not user friendly [01:45] davecheney: there have been many other improvements in the uniter recently though [01:45] Bug #1567719 opened: help text for juju list-shares needs improving

[01:45] Bug #1567721 opened: help text for juju set-default-credential needs improving

[01:46] menn0: that's what i'm worried about [01:46] we cannot backport them all [01:48] Bug #1567719 changed: help text for juju list-shares needs improving

[01:48] Bug #1567721 changed: help text for juju set-default-credential needs improving

[01:54] Bug #1567719 opened: help text for juju list-shares needs improving

[01:54] Bug #1567721 opened: help text for juju set-default-credential needs improving

[02:07] Bug #1567722 opened: help text for juju list-credentials needs improving

[02:07] Bug #1567724 opened: help text for juju add-cloud needs improving

[02:07] Bug #1567726 opened: help text for juju disable-user needs improving

[02:10] Bug #1567722 changed: help text for juju list-credentials needs improving

[02:10] Bug #1567724 changed: help text for juju add-cloud needs improving

[02:10] Bug #1567726 changed: help text for juju disable-user needs improving

[02:12] cherylj: I think I've figured out that local charm hash mismatch bug and I don't think it'll be hard to fix [02:13] menn0: excellent [02:13] menn0: there's plenty more for you once you're done with it ;) [02:13] cherylj: oh I know :) [02:14] menn0: I also still have that mgopurge problem from mario that I haven't done and could use help with :) [02:15] cherylj: ok, I can pick that up next [02:16] Bug # opened: 1567722, 1567724, 1567726, 1567728, 1567730, 1567732, 1567734 [02:25] menn0: I'm intending to add the names of top-level machines and services to modelDoc, so we can safely advance from Alive to Dead if a model is empty [02:26] menn0: just FYI, in case that would cause problems for model migration [02:26] menn0: also probably will change the hosted-model refcount to references to UUIDs, to avoid ABA problem at destroy-controller time [02:27] axw: that might have model migration implications. thumper wrote the import and export code. [02:27] thumper: thoughts? [02:27] * thumper looks up [02:28] Bug # changed: 1567728, 1567730, 1567732, 1567734 [02:28] axw: what names? [02:28] thumper, axw: it should be easy enough to account for, and tests should start failing when you add fields (but maybe only in the model-migration branch [02:28] if you add fields, tests will fail [02:28] menn0 thumper: i.e. when you add-machinem we'll $addToSet a "machines" field on the model doc [02:29] and $pull when we remove the machine [02:29] why? [02:29] thumper: https://bugs.launchpad.net/juju-core/+bug/1567228 [02:29] Bug #1567228: "juju destroy-controller" can leak hosted models [02:30] that's part of it [02:30] thumper: https://bugs.launchpad.net/juju-core/+bug/1563615 that's the other part [02:30] Bug #1563615: destroy-controller blocks when you've not removed an empty default model

[02:30] thumper: basically we should short-circuit if the controller only has empty models, but we can't do that safely at the moment [02:31] because the machines and services don't refcount or anything on the model [02:31] ok [02:32] if you do this, you'll need to make sure the value is added when the model description is imported [02:32] the export code probably won't need to change as the precondition is that the model is alive and all machines are alive [02:32] and no pending cleanups [02:32] so populating the field when importing should be "iterate through the machines" [02:33] * axw nods [02:34] thumper: where's the import code? [02:34] axw: state/migration_import.go [02:34] ta [02:34] thumper or axw: I need a quick hangout to bounce some ideas for a bug fix off someone. either of you keen? [02:34] menn0: sure [02:35] menn0 thumper: call me in if it's helpful, otherwise I want to get this sorted [02:35] kk [02:35] menn0: 1:1 ? [02:35] thumper: yep [02:37] Bug # opened: 1567728, 1567730, 1567732, 1567734 [02:48] base_windows.go makes me sad [02:48] 1. because the registiry api is nuts [02:49] 2. because the way that code enables the api to continue to be nuts, is weird, codependant and unhealtht [03:07] Bug #1566339 changed: `juju run` needs a --all-machine, --all-service, --all-unit

[03:12] menn0: cherylj [03:12] http://reviews.vapour.ws/r/4486/ [03:17] uh [03:17] oh [03:17] nm [03:17] i should just upgrade to xenial [03:23] mwhudson: if you like pain and suffering, that's a great idea. [03:23] heh it shouldn't be so bad at this point [03:24] I've just heard of a lot of problems with juju-specific things like lxd and having xenial listed as an LTS (though it may not be yet) [03:25] oh yeah, lxd keeps moving things around [03:26] I have OS updates that I'm not installing because there's lxd updates, and currently my LXD actually works. [03:26] huh um juju doesn't build with gccgo on xenial either [03:26] and I don't have time to futz with network BS [03:27] oh maybe only with the tip go tool [03:37] Bug #1567747 opened: "juju metadata generate-image" does not validate architectures [03:38] davecheney: looking [03:39] davecheney: looks good [03:42] davecheney: do you happen to know why this function has an error return? https://golang.org/src/net/http/cookiejar/jar.go?s=2387:2421#L67 it's vexing my current code. I'd like to just ignore it to make my code cleaner, but it worries me that it might one day start returning an error. [03:49] Bug #1567747 changed: "juju metadata generate-image" does not validate architectures [03:55] Bug #1567747 opened: "juju metadata generate-image" does not validate architectures [04:00] night [05:28] Bug #1567763 opened: bootstrapping private openstack, with --metadata-source fails when instance-type constraint is specified [05:35] natefinch ping ? [05:35] hmm, too late [08:42] dimitern, voidspace, dooferlad: going to skip standup today. [08:42] frobware: ok [08:49] is there anyway I can force an upgrade-tools? It works for a while, but subsequent upgrades result in "ERROR some agents have not upgraded to the current model version 2.0-beta4.4: machine-0" [08:50] frobware, ok [08:50] frobware, btw I'm about to finally propose a fix for bug 1564395 [08:50] Bug #1564395: newly created LXD container has zero network devices

[08:51] voidspace, frobware: I've got HR induction from 10-11 so I won't be in the meeting this morning (at least the first part - I'll jump in if it's still going when I get out). [08:52] babbageclunk, ack [08:52] voidspace: what I did is in the document from yesterday, though. [08:58] * thumper is in the hangout [08:58] babbageclunk: good luck [09:01] * thumper wonders if he will be sitting alone.... [09:03] babbageclunk: ok [09:03] thumper: omw [09:07] dimitern, happy to be a guinea pig for 1564395 [09:07] dimitern, that's one less reboot, for there are many today. :/ [09:07] dimitern, did your change with my /e/n/i *cough* hack... ? [09:08] dimitern, did your change work with my ... [09:13] frobware, testing always appreciated :) yes - it uses the /e/n/i hack [09:14] dimitern, not sure my hack is working today; newer lxd since weds... [09:15] frobware, I did a dist-upgrade this morning, so I have rc9 I think [09:15] yep [09:16] dimitern, I'm trying to find the right place and time to delete the lxd supplied (and mandatory) eth0.cfg [09:17] dimitern, and ensure any ifup brings up our definition of eth0 [09:17] dimitern, I was gettting provisioning errors earlier where it failed to write to /var/lib/lxd/container//rootfs/... [09:27] dimitern, the other thing is I'm only testing/trying this with trusty and xenial. I guess I should try precise and wily at some point. [10:03] dimitern: babbageclunk: PR to merge maas2 onto master http://reviews.vapour.ws/r/4487/ [10:11] voidspace, I'll swap it for this - http://reviews.vapour.ws/r/4488/ :) [10:14] voidspace, LGTM [10:14] dimitern: thanks - looking [10:15] voidspace, ta! [10:15] fwereade, hey, are you about? [10:16] frobware, ^^ pushed the fix [10:17] dimitern, you rebased? [10:17] yep [10:17] dimitern, I was just looking at your changes since I pulled from earlier [10:17] dimitern, ok [10:21] frobware, not removing /e/n/i.d/eth0.cfg doesn't seem to cause any harm - even rebooting the host/container is ok [10:21] dimitern, I'm trying to determine whether that's just luck based on the 'source .../*.cfg' order [10:21] dimitern, stgraber advised me to delete it [10:23] frobware, well, that's even better - a proper fix, but just saying what i've seen so far [10:24] dimitern, me too. but have you rebooted a lot? [10:24] frobware, i did reboot a few times, nothing fancier though [10:24] dimitern, I'm stuck with upgrade not working for me at the moment which make for slow progress [10:26] frobware, that upgrade-juju issue - that's on trusty or xenial? [10:30] dimitern: I don't really like adding unused code [10:30] dimitern: why not add the gate in the PR that uses it? [10:31] dimitern, xenial [10:33] voidspace, well, it's used by discoverspaces, but not yet by others [10:34] voidspace, actually I did this because I thought I might need it in this PR [10:34] voidspace, but fair enough, I'll pull gate out of this PR [10:36] dimitern: it's up to you - other than that LGTM [10:36] dimitern, voidspace: seems like the right thing to do as it make reverting the PR saner - should it ever need to [10:37] frobware, it's pretty easy with gh web ui [10:38] dimitern, what I mean is you would only be reverting stuff pertinent to the original fix [10:38] dimitern, anyway, back to ENI - the interfaces do not always come up for me. :( [10:40] frobware, with my fix ? [10:40] dimitern, nope, mine [10:41] dimitern, the times I've bootstrapped and added a new machine without reboot seems to work fine with your fix \o/ [10:42] frobware, I found out something else (probably related to what jamespage was seeing - if say eth0 is unconfigured, but has children which are not - it breaks [10:42] frobware, awesome! [10:42] dimitern, removal of eth0.cfg in cloud-init and taking down / bringing up the 00-juju.cfg does not work reliably. or so it seems. [10:42] dimitern, I raised a bug for that [10:43] dimitern, https://bugs.launchpad.net/juju-core/+bug/1566791 [10:43] Bug #1566791: VLANs on an unconfigured parent device error with "cannot set link-layer device addresses of machine "0": invalid address

[10:44] frobware, cheers, I'll be tackling this as well with the changes we discussed with thumper - adding 2 workers to do the NIC provisioning, devices creation, and updating provider network config after provisioning, as well as releasing container addresses as needed [10:46] frobware, in fact, I'm already thinking how we can do the job of the bridge script but in a worker instead, properly with a lot more useful context and less workarounds [10:46] dimitern, but the script runs in cloud-init [10:46] frobware, it doesn't have to, does it? [10:47] dimitern, well, as I'm finding out again, the combo of: ifdown, copy-in-new-file; ifup -a, is not guaranteed. [10:47] frobware, we can do it with proper retrying, etc. - bridge by bridge, based on what NICs we observe at run-time [10:48] dimitern, I'm generally -1 on this atm, particularly if MAAS models bridges. [10:48] in the near future [10:48] frobware, perhaps some if-[pre|post]-down script was lingering? [10:48] dimitern, bbiab - 20 mins. [10:48] frobware, well, they will be at some point, but we need to think about other providers [11:17] babbageclunk: dimitern: frobware: well that took a long time! I now have a test that can successfully call StartInstance against MAAS 2 code. [11:18] voidspace, \\o// great! [11:19] * dimitern should really install a 2.0 maas locally now :) [11:19] * fwereade cheers at voidspace [11:19] fwereade: :-) [11:19] testing it all will take a while to construct, it's not exactly a small code path - but I can call it now without it blowing up [11:20] voidspace, very NICE! [11:37] dimitern, https://bugs.launchpad.net/juju-core/+bug/1567676 [11:37] Bug #1567676: windows: networker tries to update invalid device and blocks machiner from working [11:37] help? :D [11:38] bogdanteleaga, hey - the networker is gone for a while now; which version of juju? [11:39] dimitern, latest, I wasn't sure what terminology to use [11:39] bogdanteleaga, I see (might have helped to actually read the bug desc first :) [11:39] bogdanteleaga, I know the issue [11:40] bogdanteleaga, but that's already fixed in master IIRC - is that on a feature branch? [11:41] dimitern, it's from yesterday's master [11:41] dimitern, https://github.com/juju/juju/commit/b631875ff9ed67ec321f1d6fa90bc65d839b9e93 [11:43] bogdanteleaga, so the error in comment #1 is no longer happening [11:43] bogdanteleaga, but the "" value of the address is troubling [11:45] dimitern, I'll try the latest master [11:47] bogdanteleaga, it might be better to use --config logging_config='=TRACE' to bootstrap to get more context (and paste in the bug please) [11:49] * dimitern steps out for a couple of hours [11:59] * perrito666 steps out for an hour too [12:36] an update to juju-core to fix the resources API used by charmrepo: http://reviews.vapour.ws/r/4490/ [12:37] should be trivial and I've very much like to get it landed to day if poss... [12:37] so reviews welcome :) [12:58] fwereade: I'm EODing, but if you have any time up your sleep, this PR has some gnarly state changes that I'd appreciate a review of if you have some time today: http://reviews.vapour.ws/r/4491/ [13:08] Bug #1567925 opened: help text for juju add-unit needs improving

[13:09] babbageclunk: frobware: dimitern: maas2 has landed on master - all further maas2 work to be against master [13:17] Bug #1567934 opened: uploadSuite.TestMockBuildTools relies on exact archive/zip output [13:17] Bug #1567938 opened: juju bootstrap requires network ID as config option on command line although it's specified in clouds.yaml [13:27] morning all [13:29] alexisb: o/ [13:30] voidspace: nice! [13:30] yaaaay life-giving internet [13:30] katco, hey [13:30] katco: morning [13:30] alexisb: hey [13:30] heh [13:30] voidspace: morning from across the way [13:30] is what I mean [13:30] katco: o/ [13:32] alexisb: my neighborhood is 1 short street and they've been replacing the sidewalks 1 section at a time over the past month or so. we've had 3 outages now... o.0 [13:33] katco, sounds like it is time to move ;) [13:33] * katco wry smile [13:34] perrito666: i have a patch to propose for the keystone issue... will you have a chance to tal? [13:36] alexisb, katco: morning! [13:36] babbageclunk: o/ [13:36] babbageclunk: good to hear from you again. how are you getting on with things? [13:38] katco: settling in ok, I think. Heaps and heaps to learn, obviously! [13:38] babbageclunk: that's what makes it fun :D [13:39] katco: :) [13:53] Bug #1567951 opened: help text for juju login needs improving

[13:53] Bug #1567952 opened: container/lxd: TestDetectSubnetLocal fails with link/none [13:54] katco: sure, shoot [13:57] perrito666: http://reviews.vapour.ws/r/4492/ [13:58] perrito666: ta [14:03] ericsnow: I think you're gonna like how the charmstore client code turned out... especially the amount of code needed to put into the csclientImpl wrapper type [14:03] cmars, you around yet? [14:04] ericsnow: I still have to update the tests for that code, but shouldn't be too bad. [14:06] katco: shit it with a doubt [14:07] perrito666: lol [14:07] meh [14:07] sorry typo [14:07] perrito666: i think we only care about the major to resolve the client [14:07] jam: you still around? [14:07] perrito666: i.e. if the major is 2, we'd settle on 2.x whatever that may be [14:09] frobware: ping? [14:10] katco: I had miss interpreted your code, sorry [14:11] perrito666: ah no worries... so is it still OK? [14:11]