[00:10] <mup> Bug #1563590 opened: 1.25.4, xenial, init script install error race <landscape> <juju-core:New> <https://launchpad.net/bugs/1563590>
[00:23]  * thumper takes a deep breath
[00:23] <thumper> and sighs
[00:23]  * thumper tackles a big piece of pie
[00:34] <mgz> revieeeew! https://github.com/juju/charm/pull/203
[00:37] <mup> Bug #1563607 opened: Handle multi-series charms in 1.25 <juju-core:In Progress by gz> <https://launchpad.net/bugs/1563607>
[00:37] <mup> Bug #1563609 opened: cannot add lxcs on juju 1.25.4 w/ xenial [maas] <kanban-cross-team> <landscape> <juju-core:New> <https://launchpad.net/bugs/1563609>
[00:37] <mup> Bug #1563611 opened: juju destroy-controller hides error message when multiple models exist <juju-core:New> <https://launchpad.net/bugs/1563611>
[00:49] <mup> Bug #1563609 changed: cannot add lxcs on juju 1.25.4 w/ xenial [maas] <kanban-cross-team> <landscape> <juju-core:New> <https://launchpad.net/bugs/1563609>
[00:49] <mup> Bug #1563614 opened: destroy-controller warns about security group in a confusing way <juju-core:New> <https://launchpad.net/bugs/1563614>
[00:49] <mup> Bug #1563615 opened: destroy-controller blocks when you've not removed an empty default model <juju-core:New> <https://launchpad.net/bugs/1563615>
[01:00] <mgz> axw: are you interruptable for a juju/charm review?
[01:01] <axw> mgz: sure, just gotta dash downstairs and will take a look
[01:01] <mup> Bug #1563614 changed: destroy-controller warns about security group in a confusing way <juju-core:New> <https://launchpad.net/bugs/1563614>
[01:01] <mup> Bug #1563615 changed: destroy-controller blocks when you've not removed an empty default model <juju-core:New> <https://launchpad.net/bugs/1563615>
[01:01] <mup> Bug #1563609 opened: cannot add lxcs on juju 1.25.4 w/ xenial [maas] <kanban-cross-team> <landscape> <juju-core:New> <https://launchpad.net/bugs/1563609>
[01:01] <mgz> axw: merci
[01:05] <axw> mgz: LGTM
[01:05] <mgz> axw: thanks!
[01:07] <mup> Bug #1563609 changed: cannot add lxcs on juju 1.25.4 w/ xenial [maas] <kanban-cross-team> <landscape> <juju-core:New> <https://launchpad.net/bugs/1563609>
[01:07] <mup> Bug #1563615 opened: destroy-controller blocks when you've not removed an empty default model <juju-core:New> <https://launchpad.net/bugs/1563615>
[01:08] <mgz> meph, charm.v5 doesn't have a dependencies.tsv
[01:08] <mgz> I think I might fudge this
[01:16] <tvansteenburgh> what's the best way to start over when this happens http://pastebin.ubuntu.com/15556331/
[01:18] <natefinch-afk> 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.
[01:19] <tvansteenburgh> natefinch: okay, thanks
[01:19] <natefinch> 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] <tvansteenburgh> natefinch: i hear ya, thanks for the reply
[01:34] <mgz> well, turns out updating the charm.v5 deps probably would have been easier than this...
[01:34] <natefinch> heh
[01:40] <mgz> and the test suite fails, unless specifically mongodb is installed, not just juju-mongodb? screw you charmstore
[01:41] <natefinch> lol
[01:41] <natefinch> charmstore requires elasticsearch too
[01:43] <natefinch> 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] <davecheney> thumper: https://bugs.launchpad.net/juju-core/+bug/1563628
[01:55] <mup> Bug #1563628: all: mutex's copied by value <juju-core:New for dave-cheney> <https://launchpad.net/bugs/1563628>
[01:55] <davecheney> ^ very bad and affects many provideros
[01:56] <natefinch> oh c rap
[01:56] <thumper> ew
[01:56] <thumper> hmm
[01:56] <thumper> bugger...
[01:57] <natefinch> nice addition to go vet
[02:03] <davecheney> so, funny story whats the difference between
[02:03] <davecheney> func (e *env) foo() { env = env.getSnapshot() ; .. }
[02:03] <davecheney> and
[02:03] <davecheney> func (e env) { ... }
[02:03] <davecheney> ^ basically nothing
[02:04] <davecheney> except the first form is super hard to understand a looks correct if you're not paying attention
[02:07] <mup> Bug #1563628 opened: all: mutex's copied by value <juju-core:New for dave-cheney> <https://launchpad.net/bugs/1563628>
[02:10] <mgz> juju dep update: https://github.com/juju/juju/pull/4918
[02:13] <anastasiamac> thumper: axw: frobware: http://reviews.vapour.ws/r/4358/ (MAAS 1.9 AZ fix for bug 1559099)
[02:13] <mup> Bug #1559099: JUJU_AVAILABILITY_ZONE not set in MAAS <maas-provider> <juju-core:In Progress by anastasia-macmood> <juju-core 1.25:In Progress by anastasia-macmood> <https://launchpad.net/bugs/1559099>
[02:13] <axw> anastasiamac: looking
[02:14] <anastasiamac> axw: wow \o/ tyvm
[02:14] <mgz> dep update review please! http://reviews.vapour.ws/r/4357/
[02:14] <axw> mgz: looking too
[02:15] <axw> mgz: you can probably self stamp those ones, LGTM tho
[02:16] <axw> anastasiamac: LGTM, thanks
[02:17] <davecheney> we all need to have a long talk about the immutability guarentees of provider configs
[02:17] <anastasiamac> axw: amaazing \o/
[02:17] <davecheney> or the actaul lack of any such guarentee ...
[02:17] <mgz> axw: yeah, I like someone checking I'm not an idiot though :)
[02:17] <axw> mgz: I thought that's what CI does ;p
[02:17] <axw> davecheney: what's not immutable in provider config?
[02:18] <mgz> 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] <axw> hehe
[02:20] <davecheney> axw: everything that isn't the provider config
[02:20] <axw> davecheney: que? example?
[02:20] <davecheney> axw: grep getSnapshot in any of the providers
[02:21] <axw> ok
[02:21] <axw> davecheney: right I understand, I thought you meant an environs/config.Config could be mutated
[02:21] <axw> but an Environ's SetConfig might be called at any time and swap a Config
[02:21] <axw> ...at least I think I understand
[02:22] <thumper> config.Config can't be mutated
[02:22] <davecheney> right, but look at how the getSnapshot methods, which powers env.Config is being used
[02:22] <thumper> it can only be recreated
[02:24] <axw> davecheney: yeah actually I don't understand. it returns a copy of the config at that time. what's wrong with that?
[02:24] <davecheney> https://github.com/juju/juju/blob/master/provider/vsphere/environ_broker.go#L39
[02:24] <davecheney> for instance
[02:24] <thumper> I'm pretty sure that was all from not understanding what needs protecting and what doesn't
[02:25] <davecheney> so, we have a copy of the environ, being passed down to a bunch of methods
[02:25] <davecheney> including it's own copy of the clients slice
[02:25] <davecheney> and the lock that doesn't protect said slice ...
[02:25] <davecheney> there are two locks in that tye
[02:25] <davecheney> neither protect *clients
[02:25] <axw> I see, so that's just rubbish code
[02:26] <axw> the pattern is OK in some of the other providers at least
[02:26] <axw> hadn't seen that particular one
[02:26] <davecheney> that's what Imean by "immutable config"
[02:26] <davecheney> you read the code, see taht getSnapshot returns a copy of something
[02:26] <davecheney> so you think oh, I can use a snapshot everywhere, that sounds like a good idea
[02:26] <davecheney> bzzt
[02:26]  * axw nods
[02:27] <axw> davecheney: FWIW, I ripped that pattern out of the azure provider for that reason
[02:27] <axw> felt it was giving the impression of too strong a guarantee
[02:27] <davecheney> it's grown like a cancer to about 4 other providers
[02:28] <axw> I'm happy to see it go
[02:28] <natefinch> when do we EVER need that method?
[02:28] <davecheney> i think we don't
[02:28] <davecheney> it hints at a guarentee that it cannot provide
[02:28] <natefinch> it seems like any time we might, we're just doing something wrong
[02:28] <cherylj> 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] <axw> we always need the code to be goroutine safe, but a mutex lock would be fine
[02:29] <axw> that is, just around accessing/modifying the bits we need, not on the entire env
[02:29] <anastasiamac> cherylj: u r awesome \o/
[02:30] <natefinch> 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] <anastasiamac> cherylj: the fix is landing for master since 1.8 is not relevant there..
[02:31] <cherylj> cool, thanks
[02:31] <davecheney> menn0: axw https://github.com/juju/juju/pull/4920
[02:31] <axw> looking
[02:32] <davecheney> https://github.com/juju/juju/pull/4920/files#diff-18a1316b5d2e8df51820e3be56144eb4L80
[02:32] <davecheney> ^ false, does not do what you think it does
[02:33] <davecheney> https://github.com/juju/juju/pull/4920/files#diff-18a1316b5d2e8df51820e3be56144eb4R80
[02:33] <davecheney> comment is also wrong, config can change after creation
[02:35] <axw> 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] <axw> davecheney: LGTM
[02:36] <davecheney> personally, I wouldn't put a lot of stock in SetConfig's guatenetee of immutablity
[02:36] <davecheney> i think when we wrote it three years ago, nobody knew what they were doing
[02:36] <davecheney> but provider config changes happen so infrequently it's not a bit deal
[02:37] <davecheney> and consdiering that there is really nothing stopping you creating several provider/environ types in one go, shit the tests make thousands
[02:37] <davecheney> it's just not a big deal
[02:41] <davecheney> axw: wow, https://github.com/juju/juju/blob/master/provider/maas/storage.go#L57
[02:43] <cherylj> anastasiamac: everything looks good on the 1.8 maas!
[02:44] <anastasiamac> cherylj: excellent \o/ I'll land the fix in 1.25 too \o/
[02:44] <cherylj> anastasiamac: thanks!!
[02:44] <natefinch> davecheney: it's like someone doesn't know how pointers work
[02:48] <davecheney> https://github.com/juju/juju/blob/master/provider/maas/environ.go#L299
[02:48] <davecheney> umm, no
[02:48] <davecheney> that's not what that does
[02:48] <natefinch> lol
[02:50] <mwhudson> gotta have a mutex around that aligned 8 byte load from memory
[02:53] <natefinch> https://i.memecaptain.com/gend_images/LxtBzw.jpg
[02:54] <menn0> davecheney: oh dear...
[02:59] <davecheney> menn0: axw, https://github.com/juju/juju/pull/4922
[02:59] <menn0> davecheney: looking
[02:59] <davecheney> turns out we don't need any of that jazz
[03:00] <davecheney> the value is immutable
[03:00] <davecheney> you don't need to lock an immutable value
[03:00] <davecheney> especially only one that contains pointers
[03:03] <menn0> davecheney: looks good
[03:11] <davecheney> wow, the whole outboard motor model of locking in the maas provider is really double you tee eff
[03:47] <davecheney> two hour CI backlog
[03:47] <davecheney> might be time for lunch
[06:29] <arosales> any juju-dev folks seen issues bootstrapping a model with beta3 on a Xenial machine
[06:29] <arosales> http://paste.ubuntu.com/15557810/
[06:29] <arosales> it is  s390 machine
[06:30] <urulama> arosales: hard to have that at home :)
[06:30] <arosales> seems to want to launch a trusty image which should fail for s390 as there is not trusty s390 image
[06:31] <arosales> urulama: indeed. Have to have a raised air cooled floor able to support multiple tons
[06:31] <mgz> arosales: you need to set default series to xenial
[06:32] <arosales> mgz even for a Xenial host it defaults to Trusty?
[06:32] <mgz> yeah, if I'm bootstrapping from win2012 it doesn't mean I want a win2012 state server
[06:35] <mgz> arosales: just pass `--series xenial` when bootstrapping, should do
[06:35] <arosales> mgz: ah I just tried --bootstrap-series=xenail with no luck
[06:35] <arosales> http://paste.ubuntu.com/15557820/
[06:36]  * arosales trying --series xenial now
[06:36] <mgz> arosales: thanks for testing with the beta3 :)
[06:36] <mgz> sleep time for me now
[06:36] <arosales> error: flag provided but not defined: --series
[06:36] <arosales> :-/
[06:37] <arosales> mgz good night thanks for the help
[07:53] <mup> Bug #1563705 opened: cmd/juju: "juju enable-ha" fails if you're not operating on the admin model <papercut> <juju-core:Triaged> <https://launchpad.net/bugs/1563705>
[07:59] <mup> Bug #1563705 changed: cmd/juju: "juju enable-ha" fails if you're not operating on the admin model <papercut> <juju-core:Triaged> <https://launchpad.net/bugs/1563705>
[08:08] <mup> Bug #1563705 opened: cmd/juju: "juju enable-ha" fails if you're not operating on the admin model <papercut> <juju-core:Triaged> <https://launchpad.net/bugs/1563705>
[08:58] <TheMue> morning
[08:59] <voidspace> thumper: hey, you still around
[09:00] <voidspace> thumper: ah, our standup time - never mind
[09:00] <voidspace> thumper: anyway, thanks for your work
[09:35] <mup> Bug #1563755 opened: juju2 beta3 can't upgrade-charm nor upgrade-juju (uuid renamed to controller-uuid) <juju-core:New> <https://launchpad.net/bugs/1563755>
[10:08] <mup> Bug #1563762 opened: "juju upgrade-juju --upload-tools" fails after "juju login" <juju-core:In Progress by axwalk> <https://launchpad.net/bugs/1563762>
[10:36] <babbageclunk> 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] <voidspace> babbageclunk: postman?
[10:36] <voidspace> babbageclunk: I just use the maas CLI that dumps json
[10:37] <voidspace> babbageclunk: or I write small programs using the gomaasapi
[10:37] <babbageclunk> voidspace: nice API explorer tool
[10:37] <babbageclunk> https://chrome.google.com/webstore/detail/postman/fhbjgbiflinjbdggehcddcbncdddomop?hl=en
[10:37] <voidspace> babbageclunk: if you go to #maas on the canonical server and ping roaxsox he promised to answer in a timely manner :-)
[10:37] <babbageclunk> I'll try the cli
[10:37] <voidspace> babbageclunk: cool
[10:38] <voidspace> babbageclunk: you'll need to do it *on* the server as you'll need the 2.0 client
[10:38] <voidspace> babbageclunk: you login first with:
[10:38] <voidspace> babbageclunk: maas login <profile-name> http://192.168.1.0/MAAS  <API-KEY>
[10:38] <voidspace> babbageclunk: and then you can do things like: maas <profile-name> machines read
[10:38] <voidspace> I think it's read and not list
[10:39] <voidspace> babbageclunk: and it dumps the json
[10:39] <voidspace> the CLI commands correspond pretty well to the api endpoints
[10:39] <babbageclunk> voidspace: ok, sounds good - I'll do that.
[10:40] <voidspace> babbageclunk: postman sounds good too :-)
[10:41] <babbageclunk> voidspace: yeah, it's pretty neat - nice rendering of the output, save requests that you do all the time.
[10:44] <babbageclunk> voidspace: I get an error from the cli - 'Namespace' object has no attribute 'execute'
[10:44] <babbageclunk> :(
[10:44] <voidspace> babbageclunk: is that with version?
[10:44] <voidspace> babbageclunk: I get that too
[10:44] <voidspace> I filed a bug
[10:44] <voidspace> babbageclunk: try machines
[10:45] <voidspace> https://bugs.launchpad.net/maas/+bug/1557434
[10:45] <mup> Bug #1557434: CLI version command doesn't work (2.0) <MAAS:Incomplete> <https://launchpad.net/bugs/1557434>
[10:45] <babbageclunk> voidspace: with machines, zones, everything I've tried so far.
[10:45] <voidspace> babbageclunk: oh dear
[10:46] <voidspace> babbageclunk: can you ping roaksox (sp?) on #maas in canonical irc
[10:46] <voidspace> babbageclunk: what version of maas 2 do you have?
[10:46] <voidspace> the footer of the web ui will say
[10:46] <babbageclunk> voidspace: 2.0.0 (alpha3+bzr4810
[10:46] <voidspace> that's the same one I have
[10:46] <babbageclunk> I'll try logging out and back in
[10:46] <voidspace> yeah :-/
[10:48] <babbageclunk> No luck - ok, I'll ping roaksox
[10:52] <babbageclunk> Although he's in Florida, so he won't be in for a while.
[10:54] <babbageclunk> voidspace: ah, ok - sounds like it's the same as the bug you raise
[10:54] <babbageclunk> d
[10:54] <voidspace> babbageclunk: well, my bug was specifically for the version endpoint
[10:55] <voidspace> babbageclunk: but it's consistent for me
[10:55] <voidspace> babbageclunk: not for thumper though - he can reach that endpoint fine
[10:55] <voidspace> so something weird is going on
[10:55] <babbageclunk> voidspace: maybe a consequence of the fact that I installed 1.8.x and then upgraded?
[10:55] <voidspace> babbageclunk: shouldn't be
[10:56] <voidspace> babbageclunk: try "maas refresh"
[10:56] <voidspace> then try again
[10:56] <babbageclunk> Duh, no - that was for the 1.9 instance.
[10:58] <babbageclunk> Running it in a debugger then
[11:01] <babbageclunk> Doh. Was using the tool wrong - forgot the read bit on the end
[11:01] <voidspace> you still shouldn't get that error
[11:01] <voidspace> but good if it goes away...
[11:05] <voidspace> babbageclunk: I've created PRs to merge the blessed revision of master onto drop-maas-1.8 branch and the maas2 branch
[11:05] <dooferlad> I am getting errors from http://reviews.vapour.ws/ -- I can't close issues.
[11:05] <voidspace> babbageclunk: now I'm onto reviewing Tim's work
[11:05] <voidspace> dooferlad: ping ericsnow as soon as he's around
[11:05] <dooferlad> voidspace: thanks
[11:14] <babbageclunk> voidspace: ah, ok - I think I'd need to set up OAuth to use postman here.
[11:40] <voidspace> babbageclunk: heh, so my error is the same
[11:40] <voidspace> babbageclunk: if I do "maas maas version read" it works
[11:40] <voidspace> babbageclunk: I was omitting read as well... (I didn't think the version endpoint needed it)
[11:42] <babbageclunk> I'm going to grab some lunch and run an errand
[11:43] <voidspace> babbageclunk: ok, I'll probably be on lunch when you get back - still reviewing Tim's work
[11:43] <voidspace> it's good so far
[11:47] <anastasiamac> frankban: o/
[11:48] <anastasiamac> frankban: m looking at bug 1555083 ... is embedded-gui branch merged into master already?...
[11:48] <mup> Bug #1555083: Certificate error when visiting the embedded Juju GUI <2.0-count> <juju-gui> <lxd> <juju-core:Triaged> <https://launchpad.net/bugs/1555083>
[12:29] <frankban> anastasiamac: yes it is
[12:29] <frankban> anastasiamac: sorry I was afk
[12:48] <mup> Bug #1563843 opened: update-clouds message improvement when fully up to date <juju-core:New> <https://launchpad.net/bugs/1563843>
[13:00] <mup> Bug #1563843 changed: update-clouds message improvement when fully up to date <juju-core:New> <https://launchpad.net/bugs/1563843>
[13:06] <mup> Bug #1563843 opened: update-clouds message improvement when fully up to date <juju-core:New> <https://launchpad.net/bugs/1563843>
[13:06] <mup> Bug #1563845 opened: Region names should be case-insensitive but displayed as lowercase <juju-core:New> <https://launchpad.net/bugs/1563845>
[13:12] <mup> Bug #1563845 changed: Region names should be case-insensitive but displayed as lowercase <juju-core:New> <https://launchpad.net/bugs/1563845>
[13:15] <mup> Bug #1563845 opened: Region names should be case-insensitive but displayed as lowercase <juju-core:New> <https://launchpad.net/bugs/1563845>
[13:27] <mup> Bug #1563853 opened: KVM containers don't use correct parent interface device <network> <juju-core:New for frobware> <https://launchpad.net/bugs/1563853>
[14:27] <mup> Bug #1563888 opened: Repeated network messages dumped to terminal during bootstrap <juju-core:New> <https://launchpad.net/bugs/1563888>
[14:38] <katco> ericsnow: i'm getting weird errors on review board
[14:38] <katco> ericsnow: occasional 500 errors =/
[14:38] <ericsnow> katco: k
[14:39] <mup> Bug #1563888 changed: Repeated network messages dumped to terminal during bootstrap <juju-core:New> <https://launchpad.net/bugs/1563888>
[14:42] <ericsnow> katco: hmm, it's acting like it's out of space, but I cleared it out yesterday :(
[14:43] <katco> ericsnow: =/
[14:45] <mup> Bug #1563888 opened: Repeated network messages dumped to terminal during bootstrap <juju-core:New> <https://launchpad.net/bugs/1563888>
[15:07] <voidspace> babbageclunk: ping
[15:08] <voidspace> babbageclunk: your beard is very grey
[15:15] <mup> Bug #1563918 opened: controller bootstrap process boots node twice <juju-core:New> <https://launchpad.net/bugs/1563918>
[15:22] <voidspace> frobware: can we settle a date for the babbageclunk induction sprint!
[15:28] <frobware> voidspace: supposed to be w/c 18th april. Waiting to hear back about location in London as bluefin is full.
[15:28] <frobware> alexisb: ^^
[15:29] <voidspace> frobware: ah, ok
[15:29] <voidspace> frobware: I did hear a rumour we might redirect to Oxford...
[15:29] <voidspace> that would be cool
[15:29] <voidspace> or Cambridge
[15:30] <voidspace> hell, cardiff or edinburgh would be fun too
[15:45] <mup> Bug # opened: 1563923, 1563924, 1563927, 1563928, 1563932, 1563933, 1563936, 1563938, 1563939
[16:15] <mup> Bug #1563067 changed: deploying from charmstore fails on lxd provider in a restricted network <juju-core:New> <https://launchpad.net/bugs/1563067>
[16:15] <mup> Bug #1563755 changed: juju2 beta3 can't upgrade-charm nor upgrade-juju (uuid renamed to controller-uuid) <juju-core:Won't Fix> <https://launchpad.net/bugs/1563755>
[16:15] <mup> Bug # opened: 1563942, 1563950, 1563956, 1563958
[16:32] <dooferlad> 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] <mup> Bug #1560331: juju-br0 fails to be up when no gateway is set on interface <juju-core:Triaged> <https://launchpad.net/bugs/1560331>
[16:33] <frobware> dooferlad: we did talk about having a release not that insisted on creating a default route
[16:33] <frobware> release note
[16:33] <dooferlad> frobware: looks like we need it.
[16:33] <frobware> dooferlad: yep, the code is weak. :(
[16:34] <frobware> dooferlad: we did something sensible for lack of /etc/resolv.conf
[16:34] <frobware> 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] <dooferlad> frobware: I haven't thought about there being no default route before. It is an entirely valid set up though.
[16:37] <frobware> 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] <dooferlad> frobware: it seems like the only sensible thing to do is bridge everything!
[16:41] <frobware> dooferlad: welcome to Juju 2.0 :)
[17:04] <frobware> 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] <marcoceppi> 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] <rick_h_> marcoceppi: huh?
[17:23] <marcoceppi> rick_h_: I bootstrapped, but juju acquird and deployed every node in my maas
[17:34] <bogdanteleaga> do we have a how-to on metrics?
[17:40] <natefinch> marcoceppi: it's a feature
[17:40] <marcoceppi> natefinch: yeah, I needed to warm my disks up
[18:55] <mup> Bug #1564017 opened: 'juju help glossary' and 'juju help topics' are deprecated <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1564017>
[18:55] <mup> Bug #1564018 opened: juju add-credential should also support plural <docteam> <juju-core:New> <https://launchpad.net/bugs/1564018>
[19:07] <mup> Bug #1564026 opened: Unable to upgrade hosted model with --upload-tools after upgrading controller with --upload-tools <juju-release-support> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1564026>
[19:15] <natefinch> ericsnow: quick review?
[19:15] <natefinch> ericsnow: https://github.com/juju/charmrepo/pull/82
[19:16] <ericsnow> natefinch: sure
[19:22] <ericsnow> natefinch: LGTM
[19:23] <natefinch> ericsnow: cool
[19:31] <mup> Bug #1564054 opened: lxd, maas and manual do not make sense in list-clouds <juju-core:New> <https://launchpad.net/bugs/1564054>
[19:31] <mup> Bug #1564057 opened: juju2: Charms fail with series mismatch when deployed to juju containers in bundle <juju-core:New> <https://launchpad.net/bugs/1564057>
[20:01] <mup> Bug #1564060 opened: panic when running restore -b <backup-restore> <ci> <juju-core:Triaged by cherylj> <https://launchpad.net/bugs/1564060>
[21:58] <mup> Bug #1561300 changed: juju debug-log doesnt honor current model aside from the admin model <2.0-count> <conjure> <debug-log> <juju-release-support> <juju-core:Invalid> <https://launchpad.net/bugs/1561300>
[22:36] <cherylj> Can I get a review?  http://reviews.vapour.ws/r/4365/
[22:40] <mup> Bug #1564060 changed: panic when running restore -b <backup-restore> <ci> <juju-core:Invalid by cherylj> <juju-core 1.25:In Progress by cherylj> <https://launchpad.net/bugs/1564060>
[22:44] <anastasiamac> cherylj: looking :D
[22:46] <mup> Bug #1564060 opened: panic when running restore -b <backup-restore> <ci> <juju-core:Invalid by cherylj> <juju-core 1.25:In Progress by cherylj> <https://launchpad.net/bugs/1564060>
[22:58] <mup> Bug #1564060 changed: panic when running restore -b <backup-restore> <ci> <juju-core:Invalid by cherylj> <juju-core 1.25:In Progress by cherylj> <https://launchpad.net/bugs/1564060>