[00:10] Bug #1563590 opened: 1.25.4, xenial, init script install error race

[00:23] * thumper takes a deep breath [00:23] and sighs [00:23] * thumper tackles a big piece of pie [00:34] revieeeew! https://github.com/juju/charm/pull/203 [00:37] Bug #1563607 opened: Handle multi-series charms in 1.25 [00:37] Bug #1563609 opened: cannot add lxcs on juju 1.25.4 w/ xenial [maas]

[00:37] Bug #1563611 opened: juju destroy-controller hides error message when multiple models exist [00:49] Bug #1563609 changed: cannot add lxcs on juju 1.25.4 w/ xenial [maas]

[00:49] Bug #1563614 opened: destroy-controller warns about security group in a confusing way [00:49] Bug #1563615 opened: destroy-controller blocks when you've not removed an empty default model [01:00] axw: are you interruptable for a juju/charm review? [01:01] mgz: sure, just gotta dash downstairs and will take a look [01:01] Bug #1563614 changed: destroy-controller warns about security group in a confusing way [01:01] Bug #1563615 changed: destroy-controller blocks when you've not removed an empty default model [01:01] Bug #1563609 opened: cannot add lxcs on juju 1.25.4 w/ xenial [maas]

[01:01] axw: merci [01:05] mgz: LGTM [01:05] axw: thanks! [01:07] Bug #1563609 changed: cannot add lxcs on juju 1.25.4 w/ xenial [maas]

[01:07] Bug #1563615 opened: destroy-controller blocks when you've not removed an empty default model [01:08] meph, charm.v5 doesn't have a dependencies.tsv [01:08] I think I might fudge this [01:16] what's the best way to start over when this happens http://pastebin.ubuntu.com/15556331/ [01:18] tvansteenburgh: ignore it and make a new lxd controller.... that happened to several of us. I think it was when LXD changed out from under us, and now new juju can't access the old environment. === natefinch-afk is now known as natefinch [01:19] natefinch: okay, thanks [01:19] tvansteenburgh: at some point we'll figure out the incantation to blow away the old lxd containers, but we're all slammed getting 2.0 out [01:19] natefinch: i hear ya, thanks for the reply [01:34] well, turns out updating the charm.v5 deps probably would have been easier than this... [01:34] heh [01:40] and the test suite fails, unless specifically mongodb is installed, not just juju-mongodb? screw you charmstore [01:41] lol [01:41] charmstore requires elasticsearch too [01:43] my favorite is that charmrepo is dependent on the charmstore (for testing)...and the charmstore is dependent on charmrepo, and they *both* use dependencies.tsv. [01:55] thumper: https://bugs.launchpad.net/juju-core/+bug/1563628 [01:55] Bug #1563628: all: mutex's copied by value [01:55] ^ very bad and affects many provideros [01:56] oh c rap [01:56] ew [01:56] hmm [01:56] bugger... [01:57] nice addition to go vet [02:03] so, funny story whats the difference between [02:03] func (e *env) foo() { env = env.getSnapshot() ; .. } [02:03] and [02:03] func (e env) { ... } [02:03] ^ basically nothing [02:04] except the first form is super hard to understand a looks correct if you're not paying attention [02:07] Bug #1563628 opened: all: mutex's copied by value [02:10] juju dep update: https://github.com/juju/juju/pull/4918 [02:13] thumper: axw: frobware: http://reviews.vapour.ws/r/4358/ (MAAS 1.9 AZ fix for bug 1559099) [02:13] Bug #1559099: JUJU_AVAILABILITY_ZONE not set in MAAS

[02:13] anastasiamac: looking [02:14] axw: wow \o/ tyvm [02:14] dep update review please! http://reviews.vapour.ws/r/4357/ [02:14] mgz: looking too [02:15] mgz: you can probably self stamp those ones, LGTM tho [02:16] anastasiamac: LGTM, thanks [02:17] we all need to have a long talk about the immutability guarentees of provider configs [02:17] axw: amaazing \o/ [02:17] or the actaul lack of any such guarentee ... [02:17] axw: yeah, I like someone checking I'm not an idiot though :) [02:17] mgz: I thought that's what CI does ;p [02:17] davecheney: what's not immutable in provider config? [02:18] see, that's especially why *I* need checking, most other people don't have the chance to be the idiot on both sides :P [02:18] hehe [02:20] axw: everything that isn't the provider config [02:20] davecheney: que? example? [02:20] axw: grep getSnapshot in any of the providers [02:21] ok [02:21] davecheney: right I understand, I thought you meant an environs/config.Config could be mutated [02:21] but an Environ's SetConfig might be called at any time and swap a Config [02:21] ...at least I think I understand [02:22] config.Config can't be mutated [02:22] right, but look at how the getSnapshot methods, which powers env.Config is being used [02:22] it can only be recreated [02:24] davecheney: yeah actually I don't understand. it returns a copy of the config at that time. what's wrong with that? [02:24] https://github.com/juju/juju/blob/master/provider/vsphere/environ_broker.go#L39 [02:24] for instance [02:24] I'm pretty sure that was all from not understanding what needs protecting and what doesn't [02:25] so, we have a copy of the environ, being passed down to a bunch of methods [02:25] including it's own copy of the clients slice [02:25] and the lock that doesn't protect said slice ... [02:25] there are two locks in that tye [02:25] neither protect *clients [02:25] I see, so that's just rubbish code [02:26] the pattern is OK in some of the other providers at least [02:26] hadn't seen that particular one [02:26] that's what Imean by "immutable config" [02:26] you read the code, see taht getSnapshot returns a copy of something [02:26] so you think oh, I can use a snapshot everywhere, that sounds like a good idea [02:26] bzzt [02:26] * axw nods [02:27] davecheney: FWIW, I ripped that pattern out of the azure provider for that reason [02:27] felt it was giving the impression of too strong a guarantee [02:27] it's grown like a cancer to about 4 other providers [02:28] I'm happy to see it go [02:28] when do we EVER need that method? [02:28] i think we don't [02:28] it hints at a guarentee that it cannot provide [02:28] it seems like any time we might, we're just doing something wrong [02:28] anastasiamac: I'm working on testing your az fix with a 1.8 maas. The ones in CI have been ill, so haven't been able to get something to bootstrap until now [02:29] we always need the code to be goroutine safe, but a mutex lock would be fine [02:29] that is, just around accessing/modifying the bits we need, not on the entire env [02:29] cherylj: u r awesome \o/ [02:30] man I wish we didn't split providers up into multiple files. It makes it so much harder to see the whole thing [02:31] cherylj: the fix is landing for master since 1.8 is not relevant there.. [02:31] cool, thanks [02:31] menn0: axw https://github.com/juju/juju/pull/4920 [02:31] looking [02:32] https://github.com/juju/juju/pull/4920/files#diff-18a1316b5d2e8df51820e3be56144eb4L80 [02:32] ^ false, does not do what you think it does [02:33] https://github.com/juju/juju/pull/4920/files#diff-18a1316b5d2e8df51820e3be56144eb4R80 [02:33] comment is also wrong, config can change after creation [02:35] davecheney: my only concern is about multiple methods using different versions of config, e.g. if SetConfig is set half-way through a call. but I don't think that's an issue yet [02:36] davecheney: LGTM [02:36] personally, I wouldn't put a lot of stock in SetConfig's guatenetee of immutablity [02:36] i think when we wrote it three years ago, nobody knew what they were doing [02:36] but provider config changes happen so infrequently it's not a bit deal [02:37] and consdiering that there is really nothing stopping you creating several provider/environ types in one go, shit the tests make thousands [02:37] it's just not a big deal [02:41] axw: wow, https://github.com/juju/juju/blob/master/provider/maas/storage.go#L57 [02:43] anastasiamac: everything looks good on the 1.8 maas! [02:44] cherylj: excellent \o/ I'll land the fix in 1.25 too \o/ [02:44] anastasiamac: thanks!! [02:44] davecheney: it's like someone doesn't know how pointers work [02:48] https://github.com/juju/juju/blob/master/provider/maas/environ.go#L299 [02:48] umm, no [02:48] that's not what that does [02:48] lol [02:50] gotta have a mutex around that aligned 8 byte load from memory [02:53] https://i.memecaptain.com/gend_images/LxtBzw.jpg [02:54] davecheney: oh dear... [02:59] menn0: axw, https://github.com/juju/juju/pull/4922 [02:59] davecheney: looking [02:59] turns out we don't need any of that jazz [03:00] the value is immutable [03:00] you don't need to lock an immutable value [03:00] especially only one that contains pointers [03:03] davecheney: looks good [03:11] wow, the whole outboard motor model of locking in the maas provider is really double you tee eff [03:47] two hour CI backlog [03:47] might be time for lunch [06:29] any juju-dev folks seen issues bootstrapping a model with beta3 on a Xenial machine [06:29] http://paste.ubuntu.com/15557810/ [06:29] it is s390 machine [06:30] arosales: hard to have that at home :) [06:30] seems to want to launch a trusty image which should fail for s390 as there is not trusty s390 image [06:31] urulama: indeed. Have to have a raised air cooled floor able to support multiple tons [06:31] arosales: you need to set default series to xenial [06:32] mgz even for a Xenial host it defaults to Trusty? [06:32] yeah, if I'm bootstrapping from win2012 it doesn't mean I want a win2012 state server [06:35] arosales: just pass `--series xenial` when bootstrapping, should do [06:35] mgz: ah I just tried --bootstrap-series=xenail with no luck [06:35] http://paste.ubuntu.com/15557820/ [06:36] * arosales trying --series xenial now [06:36] arosales: thanks for testing with the beta3 :) [06:36] sleep time for me now [06:36] error: flag provided but not defined: --series [06:36] :-/ [06:37] mgz good night thanks for the help [07:53] Bug #1563705 opened: cmd/juju: "juju enable-ha" fails if you're not operating on the admin model

[07:59] Bug #1563705 changed: cmd/juju: "juju enable-ha" fails if you're not operating on the admin model

[08:08] Bug #1563705 opened: cmd/juju: "juju enable-ha" fails if you're not operating on the admin model

[08:58] morning [08:59] thumper: hey, you still around [09:00] thumper: ah, our standup time - never mind [09:00] thumper: anyway, thanks for your work [09:35] Bug #1563755 opened: juju2 beta3 can't upgrade-charm nor upgrade-juju (uuid renamed to controller-uuid) [10:08] Bug #1563762 opened: "juju upgrade-juju --upload-tools" fails after "juju login" [10:36] Hey voidspace, I'm trying to hit the MAAS 2.0 API with postman so I can see responses. When I request /api/2.0/machines/ I get some reasonable-looking XML - if I add a header to accept json I get an error: Circular reference detected while emitting response [10:36] babbageclunk: postman? [10:36] babbageclunk: I just use the maas CLI that dumps json [10:37] babbageclunk: or I write small programs using the gomaasapi [10:37] voidspace: nice API explorer tool [10:37] https://chrome.google.com/webstore/detail/postman/fhbjgbiflinjbdggehcddcbncdddomop?hl=en [10:37] babbageclunk: if you go to #maas on the canonical server and ping roaxsox he promised to answer in a timely manner :-) [10:37] I'll try the cli [10:37] babbageclunk: cool [10:38] babbageclunk: you'll need to do it *on* the server as you'll need the 2.0 client [10:38] babbageclunk: you login first with: [10:38] babbageclunk: maas login http://192.168.1.0/MAAS [10:38] babbageclunk: and then you can do things like: maas machines read [10:38] I think it's read and not list [10:39] babbageclunk: and it dumps the json [10:39] the CLI commands correspond pretty well to the api endpoints [10:39] voidspace: ok, sounds good - I'll do that. [10:40] babbageclunk: postman sounds good too :-) [10:41] voidspace: yeah, it's pretty neat - nice rendering of the output, save requests that you do all the time. [10:44] voidspace: I get an error from the cli - 'Namespace' object has no attribute 'execute' [10:44] :( [10:44] babbageclunk: is that with version? [10:44] babbageclunk: I get that too [10:44] I filed a bug [10:44] babbageclunk: try machines [10:45] https://bugs.launchpad.net/maas/+bug/1557434 [10:45] Bug #1557434: CLI version command doesn't work (2.0) [10:45] voidspace: with machines, zones, everything I've tried so far. [10:45] babbageclunk: oh dear [10:46] babbageclunk: can you ping roaksox (sp?) on #maas in canonical irc [10:46] babbageclunk: what version of maas 2 do you have? [10:46] the footer of the web ui will say [10:46] voidspace: 2.0.0 (alpha3+bzr4810 [10:46] that's the same one I have [10:46] I'll try logging out and back in [10:46] yeah :-/ [10:48] No luck - ok, I'll ping roaksox [10:52] Although he's in Florida, so he won't be in for a while. [10:54] voidspace: ah, ok - sounds like it's the same as the bug you raise [10:54] d [10:54] babbageclunk: well, my bug was specifically for the version endpoint [10:55] babbageclunk: but it's consistent for me [10:55] babbageclunk: not for thumper though - he can reach that endpoint fine [10:55] so something weird is going on [10:55] voidspace: maybe a consequence of the fact that I installed 1.8.x and then upgraded? [10:55] babbageclunk: shouldn't be [10:56] babbageclunk: try "maas refresh" [10:56] then try again [10:56] Duh, no - that was for the 1.9 instance. [10:58] Running it in a debugger then [11:01] Doh. Was using the tool wrong - forgot the read bit on the end [11:01] you still shouldn't get that error [11:01] but good if it goes away... [11:05] babbageclunk: I've created PRs to merge the blessed revision of master onto drop-maas-1.8 branch and the maas2 branch [11:05] I am getting errors from http://reviews.vapour.ws/ -- I can't close issues. [11:05] babbageclunk: now I'm onto reviewing Tim's work [11:05] dooferlad: ping ericsnow as soon as he's around [11:05] voidspace: thanks [11:14] voidspace: ah, ok - I think I'd need to set up OAuth to use postman here. [11:40] babbageclunk: heh, so my error is the same [11:40] babbageclunk: if I do "maas maas version read" it works [11:40] babbageclunk: I was omitting read as well... (I didn't think the version endpoint needed it) [11:42] I'm going to grab some lunch and run an errand [11:43] babbageclunk: ok, I'll probably be on lunch when you get back - still reviewing Tim's work [11:43] it's good so far [11:47] frankban: o/ [11:48] frankban: m looking at bug 1555083 ... is embedded-gui branch merged into master already?... [11:48] Bug #1555083: Certificate error when visiting the embedded Juju GUI <2.0-count>

[12:29] anastasiamac: yes it is [12:29] anastasiamac: sorry I was afk [12:48] Bug #1563843 opened: update-clouds message improvement when fully up to date [13:00] Bug #1563843 changed: update-clouds message improvement when fully up to date [13:06] Bug #1563843 opened: update-clouds message improvement when fully up to date [13:06] Bug #1563845 opened: Region names should be case-insensitive but displayed as lowercase [13:12] Bug #1563845 changed: Region names should be case-insensitive but displayed as lowercase [13:15] Bug #1563845 opened: Region names should be case-insensitive but displayed as lowercase [13:27] Bug #1563853 opened: KVM containers don't use correct parent interface device

[14:27] Bug #1563888 opened: Repeated network messages dumped to terminal during bootstrap [14:38] ericsnow: i'm getting weird errors on review board [14:38] ericsnow: occasional 500 errors =/ [14:38] katco: k [14:39] Bug #1563888 changed: Repeated network messages dumped to terminal during bootstrap [14:42] katco: hmm, it's acting like it's out of space, but I cleared it out yesterday :( [14:43] ericsnow: =/ [14:45] Bug #1563888 opened: Repeated network messages dumped to terminal during bootstrap [15:07] babbageclunk: ping [15:08] babbageclunk: your beard is very grey [15:15] Bug #1563918 opened: controller bootstrap process boots node twice [15:22] frobware: can we settle a date for the babbageclunk induction sprint! [15:28] voidspace: supposed to be w/c 18th april. Waiting to hear back about location in London as bluefin is full. [15:28] alexisb: ^^ [15:29] frobware: ah, ok [15:29] frobware: I did hear a rumour we might redirect to Oxford... [15:29] that would be cool [15:29] or Cambridge [15:30] hell, cardiff or edinburgh would be fun too [15:45] Bug # opened: 1563923, 1563924, 1563927, 1563928, 1563932, 1563933, 1563936, 1563938, 1563939 [16:15] Bug #1563067 changed: deploying from charmstore fails on lxd provider in a restricted network [16:15] Bug #1563755 changed: juju2 beta3 can't upgrade-charm nor upgrade-juju (uuid renamed to controller-uuid) [16:15] Bug # opened: 1563942, 1563950, 1563956, 1563958 [16:32] frobware: could you take a quick look at bug #1560331 - we have no way to cope with there being no default route when bridging. [16:32] Bug #1560331: juju-br0 fails to be up when no gateway is set on interface [16:33] dooferlad: we did talk about having a release not that insisted on creating a default route [16:33] release note [16:33] frobware: looks like we need it. [16:33] dooferlad: yep, the code is weak. :( [16:34] dooferlad: we did something sensible for lack of /etc/resolv.conf [16:34] dooferlad: and we were going to parse `ip route' but then we backed all those changes out of 1.25 earlier in the year [16:35] frobware: I haven't thought about there being no default route before. It is an entirely valid set up though. [16:37] dooferlad: yes, I think we did run into this on the CI machines. It was another case where the switch to use devices and static IP addrs caused unexpected errors. [16:38] frobware: it seems like the only sensible thing to do is bridge everything! [16:41] dooferlad: welcome to Juju 2.0 :) [17:04] dooferlad: you still there? if there's no default route isn't that an error, otherwise how do the juju components talk to each other? [17:21] rick_h_: another thing, that's fun, juju 2.0 + maas 1.9 it basically went and allocated every machine for bootstrap but only used one [17:23] marcoceppi: huh? [17:23] rick_h_: I bootstrapped, but juju acquird and deployed every node in my maas [17:34] do we have a how-to on metrics? [17:40] marcoceppi: it's a feature [17:40] natefinch: yeah, I needed to warm my disks up [18:55] Bug #1564017 opened: 'juju help glossary' and 'juju help topics' are deprecated

[18:55] Bug #1564018 opened: juju add-credential should also support plural

[19:07] Bug #1564026 opened: Unable to upgrade hosted model with --upload-tools after upgrading controller with --upload-tools

[19:15] ericsnow: quick review? [19:15] ericsnow: https://github.com/juju/charmrepo/pull/82 [19:16] natefinch: sure [19:22] natefinch: LGTM [19:23] ericsnow: cool [19:31] Bug #1564054 opened: lxd, maas and manual do not make sense in list-clouds [19:31] Bug #1564057 opened: juju2: Charms fail with series mismatch when deployed to juju containers in bundle