[00:00] <menn0> perrito666: do you mean the DestroyModel method on the Client facade?
[00:01] <perrito666> menn0: ah, Its there, that explain, I was looking for it in ModelManager
[00:01] <perrito666> menn0: tx a lot
[00:01]  * perrito666 takes a moment to learn how to use expensify
[00:01]  * perrito666 fails
[00:14] <menn0> thumper: rogpeppe1 has a PR up to do API login redirection. I haven't looked in detail yet but it looks like what we also need for migrations.
[00:53] <wallyworld> menn0: any reason why destroy model is not on model manager facade?
[00:53] <wallyworld> or should not be?
[00:59] <axw> wallyworld: can talk now if you're free
[00:59] <wallyworld> sure, let's. standup ho will do
[01:21] <menn0> wallyworld: no idea. I had very little to do with that. thumper/
[01:28] <thumper> um... yes
[01:28] <thumper> there was a good reason
[01:29] <axw> anastasiamac: #1167616 is still valid
[01:29] <mup> Bug #1167616: state.SetEnvironConfig should take old and new config values <config> <state> <juju-core:Triaged> <https://launchpad.net/bugs/1167616>
[01:29] <axw> there's a TODO in the code
[01:29] <thumper> it had more to do with who could call it
[01:29] <wallyworld> natefinch: 1 minute late
[01:29] <thumper> but perhaps that isn't a great reason
[01:30] <thumper> but it made sense at the time
[01:30] <axw> thumper: only admins can use the controller facade, right? but shouldn't a non-admin model owner be able to destroy their own model?
[01:30] <thumper> axw: they can
[01:30] <thumper> through the client facade
[01:30] <thumper> the controller facade allows admins to kill other people's models
[01:30] <axw> I see
[01:31] <axw> IMO we should have it on modelmanager, but just do an auth check if auth-user != owner
[01:31] <wallyworld> exactly
[01:31] <axw> check if they're an owner, or a controller admin
[01:31] <wallyworld> and now is the time to make that breaking change. the gui guys will love us
[01:32] <axw> wallyworld: I already broke the ability to create new models, so seems like a good time to change it :)
[01:32] <axw> can't destroy if you can't create
[01:32] <wallyworld> :-)
[01:35] <thumper> do it before beta 10
[01:35] <thumper> then they can't really complain more
[01:49]  * menn0 is drowning in reviews
[02:17] <menn0> wallyworld: I'm looking at http://reviews.vapour.ws/r/5126/
[02:18] <wallyworld> menn0: sorry :-(
[02:18] <menn0> wallyworld: post-bootstrap will there be any way to change the cloud config stored in the controller?
[02:18] <wallyworld> menn0: yes, there will be a command but not done yet
[02:18] <menn0> wallyworld: ok cool
[02:19] <wallyworld> menn0: note that mdels fork (copy) the common config so changing will only affect new models
[02:19] <menn0> wallyworld: that was going to be be my next question :)
[02:19] <wallyworld> in effect, there's no user visiblw change with this work currently therefore
[02:20] <menn0> wallyworld: so if you had something like http-proxy set on a bunch of models
[02:20] <wallyworld> ie stuff works for the user the same as now, except that they don't need to use --config for the shared stuff
[02:20] <menn0> wallyworld: and you wanted to change it
[02:20] <wallyworld> ypu'd need to change all models
[02:20] <menn0> wallyworld: you would have to change it on all the existing models
[02:20] <menn0> ok
[02:20] <menn0> wallyworld: will there be a way to do a mass change across all models?
[02:20] <wallyworld> last week it was inherited, but that got nixed
[02:20] <wallyworld> the ux will need to be discussed, yes
[02:21] <menn0> wallyworld: I guess it's easier to understand if there's no inheritance
[02:21] <wallyworld> exactly
[02:21] <wallyworld> menn0: https://docs.google.com/document/d/1PWUwx9kITQajQQgvHnweUuqTGmBo9p35bVwd-uLKAi4/edit?ts=57626636#heading=h.ppor8yz4jan0
[02:21] <wallyworld> that's from mark
[02:21] <menn0> (well it's prototypical inheritance I guess)
[02:22] <wallyworld> there will be various sources of shared config
[02:22] <wallyworld> right now, we've just the 2 of them
[02:23] <wallyworld> menn0: i have to pop afk for 30 minutes to relocate (long story), will be online again in a bit
[02:23] <menn0> wallyworld: no problems. you've answered my questions. that doc helps too.
[02:23] <wallyworld> excellent
[03:09] <davecheney> menn0: i've fixed your review comments and stress tested my patch
[03:09] <davecheney> i'm going to try landing it
[03:18] <menn0> davecheney: awesome
[03:34] <natefinch> ahh full stack external tests... change one line of code, get 4 tests failing in incredibly obscure ways
[03:36] <wallyworld> axw: i can't do the settings write and model source updates in one txn - the settings is a separate struct which completes in own work before existing
[03:36] <wallyworld> settings.Write()
[03:37] <natefinch> wallyworld: well, that fix worked perfectly well in a manual test, but it breaks 4 tests in bizarre ways.
[03:37] <axw> wallyworld: settings.Write() is implemented in terms of txn.Ops...
[03:37] <wallyworld> it is, but it's a method on a separate struct with its own semantics
[03:37] <axw> wallyworld: so if you split the txn.Op building from transaction running, you can do them in one transaction
[03:38] <wallyworld> that breaks encapsulation
[03:38] <axw> wallyworld: so? you can still compose transactions. they either all run or none
[03:38] <natefinch> wallyworld: we don't have any other way to compose multiple actions into a transaction
[03:38] <wallyworld> so in this case, there's no harm spliting them as per my comment in the code
[03:38] <axw> wallyworld: we're inside the package, there's no encapsulation. having an inconsistent model is worse than exposing the ops
[03:39] <natefinch> we should really have most of our actions like this returning ops rather than running their own transaction
[03:39] <wallyworld> natefinch: so you'll just have to fix the tests i guess
[03:39] <wallyworld> except when we want to provide a fully encapsulated access to state
[03:40] <axw> wallyworld: nobody's suggesting we expose ops *outside* of state. I'm saying that UpdateModelSettings should either update the settings *and* the sources, or *neither*
[03:41] <axw> if we update the settings and then later the sources, we leave ourselves open to having lies in the model
[03:41] <wallyworld> ok, i'll need to break apart settinsg.Write()
[03:42] <wallyworld> moving ModelDestroy() off client is a pita - all the call sites in shared code use *state.State instead of interfaces, sigh
[03:43] <natefinch> I spent a lot of time fixing service creation and unit assignment so that we can't get into an inconsistent state.... and there's still some improvements to make... but the most obvious takeaway was that returning ops is composable, and hiding the ops is not.  Hopefully they can be encapsulated into a single state method call, so no one outside of state needs to worry about it... but inside of state... defaulting to returning ops rather than
[03:43] <natefinch> executing a transaction should probably be the default for most code.
[03:43] <axw> wallyworld: I've been looking at the GCE issue, and it's a bit of a pain. the issue is that we assume there's a one-to-one mapping between credentials.yaml contents and credentials in model config
[03:43] <axw> wallyworld: so not sure what I should do. it will be fixed hwen my in-progress stuff is done, but that's a ways off
[03:44] <wallyworld> natefinch: yeah, so long as we are on mongo it seems that's what we must do
[03:44] <axw> wallyworld: there's a workaround: don't use jsonfile
[03:45] <wallyworld> axw: damn. using json file will be the most common case, especially when people use autoload
[03:45] <wallyworld> i wonder if we can special case something for beta 10
[03:46] <axw> wallyworld: perhaps, just wondering if it's worthwhile expending the effort.
[03:46] <wallyworld> axw: the issue AFAICT is that our users would be using autoload-credentials mostly
[03:46] <wallyworld> and they will be screwed with this beta
[03:47] <axw> wallyworld: I'll fix the empty auth-types one, and then come back to this
[03:47] <wallyworld> ok
[03:59] <thumper> wallyworld: hi ho
[03:59] <wallyworld> yo
[04:05]  * wallyworld relocating back home, bbiab
[04:20] <natefinch> axw: I made a tiny change to the azure provider's StartInstance to fix a bug Ian had added to it when he split out the controller config... and now I'm getting this weird test failure (and 3 others similar to it): http://pastebin.ubuntu.com/17679429/
[04:22] <natefinch> axw: any ideas what is going on?  The bug was that we weren't setting the apiport unless it was during bootstrap, which obviously falls down for machines added for HA: https://github.com/juju/juju/pull/5590/files#diff-8a18f1cda410ddced1438bf9bc8e8eb9R476
[04:22] <natefinch> axw: I just don't understand the error from the test
[04:42] <natefinch> wallyworld: do you understand the azure tests?
[04:42] <wallyworld> have never looked at them
[04:42] <wallyworld> axw does
[04:43] <wallyworld> you getting failures right
[04:43] <natefinch> yeah
[04:43] <natefinch> wallyworld: http://pastebin.ubuntu.com/17679429/
[04:44] <natefinch> that's one of them... the others look pretty similar, so probably same root cause
[04:46] <wallyworld> my guess off the top of my head is that the test does not set apiport in start instance params
[04:46] <wallyworld> hence the correct security groups are not created
[04:46] <wallyworld> but just a guess
[04:49] <menn0> thumper: http://reviews.vapour.ws/r/5132/
[04:59] <mup> Bug #1589774 changed: Ghost models exist after being destroyed <juju-core:Incomplete> <https://launchpad.net/bugs/1589774>
[05:01] <axw> natefinch: sorry was having lunch, reading backlog now
[05:03] <axw> natefinch: the azure tests set up a list of expected requests. they're not matching. you'll probably need to modify some calls to "startInstanceSenders" to pass true instead of false
[05:04] <axw> natefinch: i.e. that a controller instance is being started
[05:05] <natefinch> axw: oh yes, I see
[05:06] <natefinch> axw: though I don't really understand why that needs to change due to the change I made to the code
[05:07] <axw> natefinch: if you push the change I'll take a look, if you like
[05:09] <natefinch> axw: https://github.com/natefinch/juju/commit/3534aa71f7aac1eb364ecdb32e51e3c8220c163e
[05:10] <axw> natefinch: we shouldn't be doing it unless it's a controller. so check "else if args.InstanceConfig.Controller != nil"
[05:11] <axw> natefinch: possibly we can ignore the Bootstrap case, I forget if APIInfo is set at bootstrap time
[05:11] <axw> natefinch: if it is, we should do that
[05:14] <mup> Bug #1589774 opened: Ghost models exist after being destroyed <juju-core:Incomplete> <https://launchpad.net/bugs/1589774>
[05:18] <natefinch> mna, I hate the way we use pointers in our config options and you just have to know if they're expected to be nil or not
[05:20] <mup> Bug #1589774 changed: Ghost models exist after being destroyed <juju-core:Incomplete> <https://launchpad.net/bugs/1589774>
[05:28] <wallyworld> axw: there's other places in the code where we use that args.InstanceConfig.Bootstrap != nil check - they all probably need to be cleaned up a bit
[05:29] <wallyworld> some do use the isController() check
[05:29] <axw> wallyworld: quite possibly. I think in some cases it is valid, e.g. in gce I think we set up a firewall rule that applies to all machines in the model
[05:29] <mup> Bug #1594211 changed: creating hosted model: model already exists <juju-core:New> <https://launchpad.net/bugs/1594211>
[05:30] <wallyworld> axw: yeah, i think it's just a 2 i did - ec2 and openstack. i'll do a drive by in the current pr
[05:30] <wallyworld> *this
[05:30] <natefinch> wallyworld: we really should put helper methods on that struct, rather than relying on institutional knowledge of what it means for one of the values to be nil or non-nil
[05:31] <wallyworld> no argument there, is tech debt
[05:31] <wallyworld> axw: you even have a todo in the rwckspace proviser
[05:32] <wallyworld> damn, can't type
[05:32] <axw> wallyworld: yeah it was broken before I think?
[05:32] <wallyworld> i think so
[05:32] <axw> I think I added a bug for it
[05:32] <wallyworld> axw: i'll fix now and push to the model config pr so we can get it landed
[05:34] <natefinch> axw: thusly? http://pastebin.ubuntu.com/17681411/  Also, do we need to check the length of ports or is it safe to assume it's non-empty?
[05:37] <axw> natefinch: it should always be one-and-only-one. I just noticed that instancecfg.ControllerConfig's Config field has an APIPort() method tho, that's probably more appropriate to use
[05:38] <axw> wallyworld: is ^^ set at bootstrap time?
[05:38] <axw> (I think it should be, if it's not)
[05:38] <wallyworld> axw: i think so, i'm double checking now
[05:38] <wallyworld> as i am doing
[05:38] <wallyworld> 		if isController(args.InstanceConfig) {
[05:38] <wallyworld> 			apiPort = args.InstanceConfig.APIInfo.Ports()[0]
[05:38] <wallyworld> 		}
[05:39] <wallyworld> i deleted the bootstrap bit
[05:39] <natefinch> wallyworld: I tried that and get index out of range at bootstrap.. ports is zero-length
[05:39] <natefinch> wallyworld: at least in the azure tests
[05:40] <wallyworld> the tests may not set things up correctly
[05:40] <axw> wallyworld: tests probably need updating, but I was talking about args.InstanceConfig.Controller.APIPort()
[05:40] <axw> sorry, Controller.Config.APIPort()
[05:40] <wallyworld> jeez we have so many bit of duped data
[05:40] <axw> tell me about it
[05:41] <axw> natefinch: I think you just want this: http://paste.ubuntu.com/17681608/
[05:41] <axw> err, you'll need to assign and take pointer, but you get the idea
[05:42] <wallyworld> axw: yeah, that should work with the recent landing the past few days
[05:42] <natefinch> axw: ControllerConfig doesn't have a Config field
[05:42] <natefinch> unless I'm out of date?
[05:43] <axw> natefinch: must be, it's there on master
[05:43] <natefinch> ha, I guess I anm
[05:43] <axw> https://github.com/juju/juju/blob/master/cloudconfig/instancecfg/instancecfg.go#L160
[05:48] <axw> wallyworld: your branch LGTM, let me know when you've added the fixes
[05:48] <wallyworld> ty, testing live on aws now
[05:49] <natefinch> -y
[05:51] <natefinch> I have to run to bed.  The tests pass, but I don't have time to do a manual test right now... also we should probably add a test that'll ensure this doesn't break again, but I have no clue how to do that with the code as is.
[05:54] <natefinch> will do more manual tests in the morning and see if I can put a unit test in there to catch this if it breaks again.
[05:56] <mup> Bug #1559299 changed: cannot obtain provisioning script <bootstrap> <ci> <manual-provider> <regression> <xenial> <juju-core:Invalid> <juju-core 1.25:Fix Committed by anastasia-macmood> <juju-core api-call-retry:Fix Released by axwalk> <https://launchpad.net/bugs/1559299>
[05:56] <mup> Bug #1575940 changed: LXC containers under MAAS get no "search <domain>" entry in resolv.conf when deployed with juju2 <cdo-qa-blocker> <landscape> <juju-core:Incomplete> <https://launchpad.net/bugs/1575940>
[06:11] <mup> Bug #1482074 changed: worker:  environSuite.TestInvalidConfig fails on go 1.6 <ci> <go1.6> <intermittent-failure> <unit-tests> <juju-core:Invalid> <juju-core 1.25:Invalid> <https://launchpad.net/bugs/1482074>
[06:12] <mup> Bug #1581579 changed: resource-get fails with duplicate key error <juju-core:Incomplete> <https://launchpad.net/bugs/1581579>
[06:12] <mup> Bug #1588784 changed: juju/state: intermittent test failure in SubnetSuite with mongod 3.2 <mongodb> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1588784>
[06:46] <wallyworld> axw: pushed, i tested enable-ha on ec2. i also changed azure with no failing tests, not sure what nate was seeing
[06:53] <axw> wallyworld: reviewed
[06:54] <wallyworld> ta
[06:58] <wallyworld> axw: i hit the commit button too soon, that error is fixed. i'll remove the IsController helper - that was there i guess before we had a Controller attribute and had to check jobs
[07:00] <wallyworld> axw: i'm down a rabbit hole with moving DestoryModel() to apiserver/modelmanager. all the stuff in common.modeldestroy.go uses state.State and the tenticles reach into metrics and everywhere. i may have to type cast the api.state attribute on modelmanager facade to state.State for now
[07:05] <urulama_> wallyworld, axw: good evening ... looking at what perrito666 mentioned as a breaking change. is there anything else besides https://github.com/juju/juju/commit/9933a39c799639084bd822ea3ee8e6345131bac7 ?
[07:06] <wallyworld> urulama: well hello. another change we discovered today - i am looking to move DestroyModel() off the client facade onto the ModelManager facade.
[07:07] <wallyworld> i didn'tt hink you wer ehere today?
[07:07] <urulama> wallyworld: i am just happy to have 2 days off :D
[07:07] <wallyworld> that destoy model api is the only one on the client facade, it just should not be there
[07:07] <wallyworld> we have create and list model on the model manager facade already
[07:07] <wallyworld> 2 days off, luxury
[07:11] <axw> wallyworld: there's also a breakage of the CreateModel API call, which I've mailed Francesco about
[07:11] <axw> err urulama^^
[07:11] <axw> urulama: would you like me to forward the details to you?
[07:12] <wallyworld> axw: i did already :-)
[07:12] <axw> ok cool
[07:14] <urulama> ok, thanks, will sync with frankban|afk ... see, even 2 days off is a risk! :D
[07:20] <urulama> wallyworld: do you have a track of all the breaking changes somewhere? as in a list? if not, we'll make it so we don't miss anyone and share it with other clients as well
[07:21] <wallyworld> urulama: it will be complicated by tim's work - there's only one api change as such - create model. well 2 if i can get detroy model landed. but then tim's stuff potentially alters the json attributes all over. i can get a diff of the tag changes
[07:21] <wallyworld> add model i mean
[07:22] <urulama> wallyworld: no, no, not in such detail. tim's change is well defined ... no worries, i'll make a list
[07:25] <rogpeppe> axw: what's changed in the CreateModel API call?
[07:26] <axw> rogpeppe: no more ConfigSkeleton for one thing
[07:26] <rogpeppe> axw: great!
[07:26] <rogpeppe> axw: is the new API documented anywhere?
[07:26] <axw> rogpeppe: there's a "name" field on the params struct now, and it's an error to have it in the config bag
[07:26]  * rogpeppe goes and generates the API docs again
[07:26] <axw> rogpeppe: and you can specify a region and/or credential name, but they'll have defaults if you're an admin
[07:27] <rogpeppe> axw: this has landed, right?
[07:27] <anastasiamac> axw: wallyworld: m meant not to be able to bootstrap maaas on tip of master? m getting with auth-type "oauth1" is not supported (expected one of ["empty"])
[07:27] <axw> rogpeppe: yes, post beta9
[07:27] <anastasiamac> for maas deployment that worked before..
[07:27] <axw> anastasiamac: I'm fixing it
[07:27] <anastasiamac> \o/
[07:27] <axw> anastasiamac: https://bugs.launchpad.net/juju-core/+bug/1593566
[07:27] <mup> Bug #1593566: Bootstrap reports oath1 not supported with maas 2.0 <bootstrap> <cdo-qa> <cdo-qa-blocker> <maas-provider> <juju-core:In Progress by axwalk> <https://launchpad.net/bugs/1593566>
[07:27] <wallyworld> anastasiamac: you need to add auth type to your cloud
[07:28] <axw> rogpeppe: https://github.com/juju/juju/blob/master/apiserver/params/internal.go#L86
[07:28] <anastasiamac> axw: tyvm - trying now
[07:33] <rogpeppe> axw: http://s3.amazonaws.com/rogpeppe-scratch/juju-api-doc.html#ModelManager :)
[07:33] <axw> rogpeppe: nice!
[07:36] <axw> wallyworld anastasiamac: http://reviews.vapour.ws/r/5133/
[07:36] <wallyworld> ok
[07:42] <wallyworld> axw: ty, lgtm
[07:46] <anastasiamac> axw: looking (and workaround worked)
[07:46] <anastasiamac> wallyworld: is it a state of origin night again? \o/
[07:46] <wallyworld> yes indeed
[07:48] <anastasiamac> :)
[08:10] <frankban> wallyworld: this is the mega-wather response I am getting from current master: {'RequestId': 1, 'Response': {'watcher-id': '1'}}
[08:10] <frankban> wallyworld: so it seems that we still have some CamelCase there?
[08:11] <wallyworld> frankban: i think RequestId / Response may be part of the api infrastructure, so maybe missed tim's changes, not sure
[08:12] <frankban> wallyworld: same for the request top level fields, like Params, Request, RequestId, Type, Version
[08:12] <wallyworld> thumper: ^^^^ ?
[08:13] <thumper> that is a different level
[08:13] <thumper> :(
[08:13] <thumper> didn't touch that bit
[08:14] <frankban> thumper: are you going to handle that as well?
[08:14] <thumper> I hadn't thought about it, but could do
[08:15] <thumper> we probably should... right?
[08:15] <frankban> thumper: I think so, as otherwise the API style is still inconsistent
[08:16] <thumper> frankban: ack, will look at it tomorrow
[08:16] <frankban> thumper: thanks!
[08:17] <axw> thumper: I think atm you can connect to a 2.0 server with a 1.25 client, and you'll be told that the client is incompatible. If we totally change the arg casing, that would be broken... or we'd need to handle both
[08:17] <dimitern> frankban: FWIW those RequestId and Response fields are not part of the API contract, but the RPC layer
[08:17] <thumper> axw: yeah... interesting
[08:17] <dimitern> thumper: I was unable to add a machine after your API changes landed
[08:17]  * thumper will consider
[08:18] <dimitern> thumper: some of the decisions re adding omitempty seem inconsistent
[08:19]  * urulama has a feeling that should end up as a breaking test somewhere :-/
[08:19] <dimitern> thumper: and there are a few omissions, e.g. an embedded Entities gets a `json:"entities"` (IIRC GetAgentEntitiesResults?), while an embedded Address in HostPort doesn't
[08:19] <frankban> dimitern: from clients perspective you still get some CamelCase fields and other lower-case ones, which feels inconsistent, and consistency is teh only reasoning for this change
[08:20] <dimitern> frankban: agreed, just saying simply tagging all params types/fields explicitly does not apply to the RPC transport layer
[08:28] <thumper> but we could
[08:29] <thumper> urulama: correct, there should be a test for that
[08:29] <thumper> dimitern: was it an existing controller and a new client?
[08:29]  * thumper should leave
[08:29] <thumper> it's late
[08:30] <frankban> thumper: I am starting the GUI API migration today, should I consider all lower-case then? including RPC top level fields?
[08:30] <thumper> frankban: let's say yes, and I'll let you know if I break too much and can't do it
[08:31] <frankban> thumper: sounds good, thanks a good night
[08:32] <urulama> night, thumper
[08:32] <thumper> night
[08:33] <thumper> urulama: what days are you at the sprint next week?
[08:35] <urulama> thumper: from Sunday evening to Wednesday noon
[08:37] <thumper> cool
[08:37] <thumper> urulama: see you sunday then
[08:37] <thumper> laters
[08:37] <dimitern> thumper: no, newly bootstrapped controller
[08:42] <axw> wallyworld: I'm running out of ideas for a quick-fix for gce. I could do a nasty hack in cmd/juju/commands/bootstrap.go, to convert jsonfile to oauth2
[08:42] <wallyworld> axw: yeah, i was thinking that may haveto be the temporary answer
[08:43] <wallyworld> frankban: moving DestrroyModel off client facade is a pita - but we need to do it. it will likely miss the beta10 cutoff tomorrow
[08:45] <frankban> wallyworld: ah so it will be beta11 ModelManager.Destroy() ?
[08:46] <wallyworld> frankban: i fear so, i will get it done later tonight but then it needs review etc
[08:46] <wallyworld> i will try
[08:46] <frankban> wallyworld: no problem, the GUI will not work for beta10 tomorrow, so there is no rush on our side
[08:47] <wallyworld> ok, let's aim for beta 11. i'll let you know how i go. i first need to debug another issue as well
[08:54] <dimitern> frobware: when you can, please have a look at http://reviews.vapour.ws/r/5134/
[09:01] <frankban> wallyworld: FYI it seems that also all the mega-watcher fields are still CamelCased: for instance http://pastebin.ubuntu.com/17686685/
[09:01] <wallyworld> damn
[09:01] <wallyworld> i'll tell tim
[09:03] <dimitern> frobware, voidspace, jam: standup?
[09:03] <frobware> dimitern: will do
[09:04] <axw> wallyworld:  please to be reviewing: github.com/juju/juju/pull/5692
[09:04] <axw> wallyworld: tested live, bootstrapped gce successfully with a jsonfile cred
[09:06] <wallyworld> sure borat
[09:07] <wallyworld> axw: i'm retesting the api port fix on ec2, am seeing both slave controllers stay pending. seems to be intermittent
[09:07] <axw> wallyworld: hrm, anything in cloud-init-output.log?
[09:08] <wallyworld> just started looking, added debuggin and trying again
[09:08] <axw> wallyworld: ok. I need to go make dinner, will be back in a little while
[09:08] <wallyworld> ok
[09:29] <frobware> dooferlad: please could you try http://reviews.vapour.ws/r/5136/ on your h/w - thanks!
[09:30] <dimitern> frobware: you've got a review btw
[09:31] <frobware> dimitern: ah, yes. will do
[09:31] <dimitern> frobware: ta!
[09:45] <dooferlad> frobware: on it
[10:17] <babbageclunk> dimitern: updated http://reviews.vapour.ws/r/5123/ - have another look?
[10:18] <babbageclunk> cherylj: ping?
[10:18] <dimitern> babbageclunk: I did look briefly, looks much better, thanks!
[10:18] <babbageclunk> dimitern: cheers!
[10:18] <dimitern> babbageclunk: LGTM
[10:30]  * dimitern is out for a while
[10:41] <axw> wallyworld: how goes it?
[10:41] <wallyworld> qld behind 2-4
[10:41] <wallyworld> oh, you mean work
[10:42] <axw> wallyworld: heh yeah :)
[10:43] <wallyworld> axw: have interfaces / mocks more or less sorted for moving destory model. having a mix of state.State and interfaces sorta sucks
[10:44] <axw> wallyworld: the api-port thing though? sorted?
[10:45] <wallyworld> axw: yeah, so this is an existing issue - config that comes via an api call has ints unmarshalled as float64 and mustInt() fails
[10:46] <wallyworld> we just have never come across it
[10:46] <axw> wallyworld: I just saw your change. I'm sure we handle that in schema.Coerce. maybe related to the recent introduction of controller.Config?
[10:46] <axw> does that *always* go through schema.Coerce, or only at bootstrap time?
[10:46] <wallyworld> the latter i think
[10:47] <wallyworld> i can do a better change for beta 11 if needed
[10:47] <axw> wallyworld: yeah that's what I thought. I think we can back that change out when controller config is fully separated
[10:47] <wallyworld> yep, will do for now to unblock the beta
[10:48] <axw> wallyworld: yeah no worries, I'd just like to simplify later if possible. all good for now
[10:48] <wallyworld> +1
[11:16] <babbageclunk> dimitern: ping?
[11:27] <dimitern> babbageclunk: pong
[11:28] <babbageclunk> dimitern: hey - I was trying to understand the tests in https://github.com/juju/juju/blob/master/cmd/juju/status/status_test.go#L338
[11:28] <babbageclunk> dimitern: Why are they written like this (as series of steppers) instead of function calls?
[11:29] <dimitern> babbageclunk: they're almost like defined in their own DSL
[11:30] <dimitern> babbageclunk: well, I did that after getting excited about how the uniter tests were written at that time
[11:30] <dimitern> babbageclunk: but now I wouldn't have done it like this
[11:30] <babbageclunk> dimitern: But why not just function calls for the different kinds of steps?
[11:30] <babbageclunk> dimitern: ok - I think I follow.
[11:31] <dimitern> babbageclunk: as for debugging tips - since everything is one big table-based test, it's best to comment out all cases you don't care about (temporarily)
[11:31] <babbageclunk> dimitern: yeah, that sounds v useful
[11:32] <dimitern> to reduce the insane amount of cruft you need to sift through on failure
[11:33] <babbageclunk> dimitern: should be ok though - my new fields only show up if they're populated, so adding them shouldn't break any other tests.
[11:34] <dimitern> babbageclunk: yeah, it sounds like you need to add 2 cases only - to exercise application workload-version w/ and w/o '*' suffix
[11:35] <babbageclunk> dimitern: Do you think I need to test the suffix again here? I'm not doing any formatting at the command level.
[11:35] <dimitern> babbageclunk: however, if 'workload-version' is not json-tagged as ',omitempty', you'd need to change all existing cases to include an empty w-v
[11:37] <babbageclunk> dimitern: It seemed right to tag workload-version as omitempty, though - otherwise it'll be noise for all the charms that don't set it (all of them at the moment).
[11:37] <dimitern> babbageclunk: I think it's good to test both cases, for completeness, and they can act like functional/integration tests for the feature
[11:37] <babbageclunk> dimitern: Yeah, fair enough. Not very hard to.
[11:38] <dimitern> babbageclunk: charms won't be affected - mostly tests with pre-canned 'expected' responses could be affected
[12:03] <mup> Bug #1592101 changed: Error connecting with cached addresses <juju-core:Fix Released> <https://launchpad.net/bugs/1592101>
[12:03] <mup> Bug #1575940 opened: LXC containers under MAAS get no "search <domain>" entry in resolv.conf when deployed with juju2 <cdo-qa-blocker> <landscape> <juju-core:Incomplete> <https://launchpad.net/bugs/1575940>
[12:03] <mup> Bug #1595155 opened: new systemd and dbus dependencies are broken <blocker> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1595155>
[12:09] <mup> Bug #1575448 changed: trusty juju 1.25.5 HA availability issues <canonical-bootstack> <juju-core:Fix Released by anastasia-macmood> <juju-core 1.25:Fix Committed by anastasia-macmood> <https://launchpad.net/bugs/1575448>
[12:24] <frankban> wallyworld: FYI Client.CharmInfo response is still in camel case, maybe I should write an email to Tim with my findings
[12:26] <wallyworld> frankban: that would be most excellent
[12:27] <frankban> wallyworld: doing that, I'll send it before my EOD
[12:27] <dimitern> frankban: try adding a machine as well
[12:28] <frankban> dimitern: do you want me to try if it works?
[12:28] <dimitern> frankban: I found that to be broken; e.g. 'juju add-machine --series trusty' or 'add-machine lxd:0'
[12:28] <frankban> dimitern: ok I'll look if I can add a machine through the API
[12:29] <dimitern> frankban: yes, please, if you can - I'm still not sure if the above is maas-specific (where I've seen it after thumper's change) or not..
[12:30] <mup> Bug #1575448 opened: trusty juju 1.25.5 HA availability issues <canonical-bootstack> <juju-core:Fix Released by anastasia-macmood> <juju-core 1.25:Fix Committed by anastasia-macmood> <https://launchpad.net/bugs/1575448>
[12:33] <frankban> dimitern: it seems to be working on lxd: http://pastebin.ubuntu.com/17693847/
[12:33] <mup> Bug #1575448 changed: trusty juju 1.25.5 HA availability issues <canonical-bootstack> <juju-core:Fix Released by anastasia-macmood> <juju-core 1.25:Fix Committed by anastasia-macmood> <https://launchpad.net/bugs/1575448>
[12:34] <dimitern> frankban: hmm.. is that the correct version for 2.0 btw?
[12:35] <dimitern> frankban: thanks for confirming though, it seems it might be maas-specific
[12:35] <frankban> dimitern: what do you mean correct version for 2.0?
[12:39] <dimitern> frankban: I though all API facade versions where incremented in juju 2.0
[12:40] <dimitern> frankban: so seeing Version: 1 in your paste seemed wrong, but I'm not sure if the Client facade version was also bumped
[12:41] <frankban> dimitern: I am not aware of any version bump in juju2, here are the facades returned when logging in: http://pastebin.ubuntu.com/17694260/
[12:43] <perrito666> wow the test suite really kills my laptop
[12:44] <dimitern> frankban: well, comparing this to 1.25 you'll notice the bumps
[12:45] <dimitern> frankban: but I've just remembered Client was originally Version: 0
[12:45] <frankban> dimitern: sure, but Client is version 1
[12:45] <frankban> dimitern: cool ok
[12:58] <frobware> cherylj: do I need extra extra extra magic runes for landing in 1.25? - https://github.com/juju/juju/pull/5693
[12:59] <cherylj> frobware: you just have to really mean it
[12:59] <cherylj> $$__JFDI__$$
[12:59] <frobware> cherylj: ohhhhhhhhhh
[12:59] <frobware> duh
[12:59] <frobware> ok
[12:59] <cherylj> :)
[13:00] <dimitern> it still looks like $$__JEDI__$$ to me :D
[13:04] <frobware> dimitern: remind me again... do I care about removing "vlan_id" from the iface options?  Just porting from 1.25 and want to make sure I don't drop anything along the way.
[13:05] <dimitern> frobware: no, because it's invalid anyway and will be ignored
[13:05] <dimitern> frobware: curtin is to blame for adding it
[13:07] <fwereade> babbageclunk, katco: https://github.com/juju/juju/pull/5695 doesn't seem to have been picked up by RB, but should be trivial
[13:12] <dimitern> frobware: updated http://reviews.vapour.ws/r/5134/
[13:12] <dimitern> voidspace, babbageclunk, dooferlad: I'd appreciate a second look on the above as well
[13:21] <frobware> dimitern: done
[13:35] <dimitern> frobware: thanks!
[13:58] <perrito666> I am getting a lot of timeouts on my tests, did the mongo --nojournal fix land in master?
[14:31] <dimitern> frobware: ping
[14:31] <frobware> dimitern: pong
[14:31] <dimitern> frobware: let me know what you think about my response on your review
[14:31] <frobware> dimitern: does the last or first 'search' win?
[14:31] <dimitern> frobware: the last apparently
[14:32] <frobware> dimitern: <shrug> - ok
[14:32] <dimitern> frobware: how about those 4 points btw?
[14:32] <frobware> dimitern: looking. everthing is so well defined. Not.
[14:33] <dimitern> frobware: yeah, that's the issue I think - not completely defined spec leads to permissive implementations :)
[14:33] <frobware> dimitern: is this valid "nameserver 8.8.4.4 4.4.4.4" without trailing comments?
[14:33] <dimitern> frobware: no
[14:34] <dimitern> frobware: (as far as 'host' is concerned at least.. nslookup as well, haven't tried all dns clients :)
[14:34] <frobware> dimitern: so is search the only one we should then consider as it seems more permissive (e.g., "search foo foo.bar maas. ;baz #bad (baz and bad are ignored)")
[14:36] <frobware> dimitern: any /etc/resolv.conf I edit by hand I always put nameserver entries on a line by themselves.
[14:36] <frobware> dimitern: search not so, hence why I was asking
[14:36] <dimitern> frobware: neither search nor nameserver are defined as allowing comments after the values.. interestingly enough vim's syntax highlighting seems to catch most of the corner cases I tried
[14:37] <frobware> dimitern: whodathunkit!
[14:38] <dimitern> frobware: so, anyway - if those 4 suggestions for changing the behavior seem reasonable, I'll do them and let's get it landed
[14:39] <frobware> dimitern: I responded in the review - ok for some, the others I simply dunno.
[14:40] <dimitern> frobware: '(2.1) disagree' - meaning it should be a parse error out of ParseResolvConf() or we should allow multiple values and not ignore the whole line?
[14:41] <frobware> dimitern: I don't think we should allow multiple values per nameserver entry. separate lines, but this is just based on the way I've always done it.
[14:41] <frobware> dimitern: what a mess
[14:41] <dimitern> :)
[14:41] <frobware> dimitern: drop all searches, use 8.8.8.8. :-D
[14:42] <dimitern> frobware: It was surprising for me that IPv6 addresses are not allowed for nameserver btw
[14:42]  * frobware thinks the problem with free form text is you now have two problems
[14:42] <dimitern> yeah..
[14:43] <dimitern> https://xkcd.com/927/
[14:43] <frobware> dimitern: it's missing several orders of magnitude.
[14:44] <dimitern> frobware: hmm.. so re IPv6 it's deeper than that
[14:44] <frobware> dimitern: or wider. :-D
[14:46] <natefinch> OMG azure is so slow
[14:47] <dimitern> `With BIND 8.3.3, the DNS client can connect to IPv6 DNS servers using an IPv6 transport. To enable such a connection, enter an IPv6 address after nameserver in the resolv.conf file.`
[14:47] <dimitern> ffs..
[14:47] <dimitern> nothing can be easy, can it
[14:49] <frobware> dimitern: what does "after" mean here/
[14:50] <dimitern> frobware: after 'nameserver'
[14:50] <frobware> dimitern: on a new line?
[14:50] <frobware> dimitern: so you need context whilst parsing?
[14:50] <dimitern> frobware: ha:)
[14:51] <dimitern> frobware: well it seems to accept 'nameserver ::1' (it doesn't listen there, so it gets ignored)
[14:51] <frobware> dimitern: given where we are with IPv6 I would concentrate on rock-solid IPv4.
[14:51] <dimitern> frobware: but not '2001:db8::1' (fair enough - it's from the range reserved for examples)
[14:52] <dimitern> frobware: I vote for accepting single value IPv6 nameservers
[14:52] <frobware> dimitern: me too, that catches ::1
[14:52] <dimitern> frobware: but return parse errors in the other 3 sub-cases of 2)
[14:53] <frobware> dimitern: how bad/common is 2.3?
[14:53] <dimitern> frobware: rather than ignoring them
[14:53] <frobware> dimitern: 2.4 should be harmless - we do nothing
[14:53] <dimitern> frobware: dunno.. but it can be an honest mistake I guess
[14:54] <frobware> dimitern: but there's nothing for us to add so we accept and move on
[14:54] <frobware> dimitern: if I have 'search    #oops I forgot!' - we add parse but add no domain, correct?
[14:55] <frobware> dimitern: *nix is hard to tool sometimes... :(
[14:56] <dimitern> frobware: so missing values are definitely not allowed (explicitly stated in resolv.conf(5)) and cause parse errors
[14:56] <natefinch> why oh why do I have to switch to the controller model to run enable-ha?  It's not a model command, it's a controller command :/
[14:56] <frobware> dimitern: well, that helps!
[14:57] <frobware> dimitern: dem da rulez!
[14:57] <dimitern> frobware: re 'search #oops I forgot' - the same as no value as far as 'host' is concerned
[14:58] <dimitern> frobware: and I'd rather return an error in all cases of 2), but still allow 2.2) (ipv6 addrs)
[14:58] <frobware> dimitern: do we consider the "domain" keyword at all?
[14:59] <dimitern> frobware: there are 2 additional limitations, which I won't even bother to handle specifically - more than 3 nameserver and more than 6 domains in 'search' (or len of all values >256)
[14:59] <frobware> dimitern: ah, well I think we should leave the limitations up to resolvconf
[15:00] <dimitern> frobware: not yet ('domain' is mutually exclusive with 'search' per the spec)
[15:00] <frobware> dimitern: if those rules change we would have to change juju - which seems wrong
[15:00] <dimitern> frobware: exactly
[15:01] <dimitern> frobware: and returning parse errors is better than silently ignoring a bad resolv.conf (when we can tell the user about it)
[15:01] <frobware> dimitern: ok, but I think 'domain' is something we should consider - last one wins (either search or domain)
[15:01] <katco> natefinch: standup time
[15:01] <dimitern> frobware: yeah, when we add support for 'domain', that's what we should do I think
[15:02] <frobware> dimitern: with the additional DNS support in MAAS 2.0 is this something we can potentially get?
[15:03] <dimitern> frobware: that depends on whether maas/cloud-init/curtin renders resolv.conf including 'domain' (not seen this thus far)
[15:04] <frobware> dimitern: me neither
[15:04] <frobware> dimitern: but I don't use MAAS 2.0 very much
[15:06] <dimitern> frobware: I mostly test on 2.0 now
[15:07] <frobware> dimitern: which is good because between us we cover both
[15:49] <natefinch> cherylj: want me to look at https://bugs.launchpad.net/juju-core/+bug/1595155 ?
[15:49] <mup> Bug #1595155: new systemd and dbus dependencies are broken <blocker> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1595155>
[15:53] <cherylj> natefinch: we're talking about that now and it may not be an issue
[15:55] <cherylj> natefinch: can you backport the fix for bug 1581157?
[15:56] <mup> Bug #1581157: github.com/juju/juju/cmd/jujud test timeout on windows <blocker> <ci> <regression> <test-failure> <unit-tests> <windows> <juju-core:Fix Committed by natefinch> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1581157>
[16:06] <natefinch> cherylj: sure
[16:08] <perrito666> bbl
[16:21] <frobware> dimitern, babbageclunk, dooferlad, voidspace: forward port of the bridge script changes from 1.25: http://reviews.vapour.ws/r/5140/
[16:22] <dimitern> frobware: will look shortly
[16:23] <frobware> dimitern: thanks; will check back later
[16:23] <babbageclunk> frobware: looking now
[16:27] <frobware> babbageclunk: the essence of the change is 1) revert to using ifdown and 2) that means the real diff is like this: http://pastebin.ubuntu.com/17704158/
[16:27] <frobware> babbageclunk: the revert to using ifdown is commit http://pastebin.ubuntu.com/17704158/
[16:28] <frobware> babbageclunk: and the other change is http://pastebin.ubuntu.com/17704233/
[16:28] <frobware> dimitern: ^^
[16:32] <dimitern> frobware: LGTM
[16:52] <mup> Bug #1595252 opened: regression b8-b9, ERROR empty admin-secret in model configuration <azure-provider> <deploy> <juju-core:New> <https://launchpad.net/bugs/1595252>
[16:57] <natefinch> cherylj: backport is pending merge into 1.25.  Anything else I should look at?  I have limited time left today, due to taking a half day, but willing to start work on something that is ok to finish tomorrow.
[16:58] <cherylj> natefinch: I'll find something for you to pick up when you come back tomorrow :)
[17:03] <dimitern> frobware: still there?
[17:03] <frobware> dimitern: nope
[17:03] <frobware> dimitern: well, very briefly
[17:04] <dimitern> frobware: I'm finally done with the changes, pushing hopefully the final version, as discussed - wanna have a last look before I set it to land?
[17:04] <frobware> dimitern: might have to be later - we can land tomorrow
[17:05] <dimitern> frobware: ok
[17:05] <frobware> dimitern: did you push the changes?
[17:07] <dimitern> frobware: any minute now..
[17:07] <dimitern> frobware: done
[17:52] <mup> Bug #1595276 opened: TestDestroyControllerErrors failure with out of order errors <azure-provider> <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1595276>
[18:04] <mup> Bug #1593812 opened: Failed to bootstrap: missing controller UUID <blocker> <bootstrap> <juju-gui> <juju-core:Triaged by wallyworld> <https://launchpad.net/bugs/1593812>
[18:04] <mup> Bug #1595278 opened: Openstack invalid port range 0:0 <blocker> <ci> <openstack-provider> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1595278>
[18:48] <jhobbs> Is there a working juju daily ppa somewhere? https://launchpad.net/~juju/+archive/ubuntu/daily looks like it's out of date. I need to get a close to tip juju and I was hoping for a PPA so I don't need to learn how to build it
[19:04] <mup> Bug #1595252 changed: regression b8-b9, ERROR empty admin-secret in model configuration <azure-provider> <deploy> <juju-core:Invalid> <https://launchpad.net/bugs/1595252>
[19:22] <cherylj> jhobbs: you can get the binaries built from our last CI run:  http://reports.vapour.ws/releases/4092/binaries
[19:22] <jhobbs> thanks cherylj
[19:26] <cherylj> katco: would you be able to review this today?  https://github.com/juju/juju/pull/5057
[19:27] <katco> cherylj: let me see how big it is
[19:27] <katco> cherylj: errrr a bash script...
[19:28] <katco> cherylj: i'll give it a go
[19:30] <katco> cherylj: wow, i'm not well versed enough in bash to do this thing justice
[19:32] <katco> cherylj: sorry, someone who knows bash will have to TAL.
[19:34] <mup> Bug #1593394 changed: model already exists but can't be destroyed because it's not found - lots of "lease manager stopped" errors <v-pil> <juju-core:Triaged> <https://launchpad.net/bugs/1593394>
[19:34] <mup> Bug #1593812 changed: Failed to bootstrap: missing controller UUID <blocker> <bootstrap> <juju-gui> <juju-core:Fix Released by wallyworld> <https://launchpad.net/bugs/1593812>
[19:40] <mup> Bug #1593394 opened: model already exists but can't be destroyed because it's not found - lots of "lease manager stopped" errors <v-pil> <juju-core:Triaged> <https://launchpad.net/bugs/1593394>
[19:40] <mup> Bug #1593812 opened: Failed to bootstrap: missing controller UUID <blocker> <bootstrap> <juju-gui> <juju-core:Fix Released by wallyworld> <https://launchpad.net/bugs/1593812>
[19:43] <mup> Bug #1593394 changed: model already exists but can't be destroyed because it's not found - lots of "lease manager stopped" errors <v-pil> <juju-core:Triaged> <https://launchpad.net/bugs/1593394>
[19:44] <mup> Bug #1593812 changed: Failed to bootstrap: missing controller UUID <blocker> <bootstrap> <juju-gui> <juju-core:Fix Released by wallyworld> <https://launchpad.net/bugs/1593812>
[20:08] <mup> Bug #1595314 opened: maas controller.go:80 read version failed: &errors.Err{message:"", cause:(*json.SyntaxError)(0xc82040a1a0), previous:(*errors.Err)(0xc8202b6c30) <juju-core:New> <https://launchpad.net/bugs/1595314>
[20:13] <cherylj> jhobbs: ping?
[20:13] <jhobbs> hi cherylj
[20:13] <cherylj> hey there.  Regarding bug #1594958
[20:13] <mup> Bug #1594958: Bootstrapping on OpenStack fails with juju 2 <v-pil> <juju-core:Incomplete> <https://launchpad.net/bugs/1594958>
[20:13] <cherylj> are you using exactly "--config image-metadata-url=<url>" ?
[20:14] <jhobbs> cherylj: the command i ran is in the pastebin
[20:14] <jhobbs> http://paste.ubuntu.com/17713435/
[20:14] <jhobbs> i'm using --config --image-metadata-url
[20:14] <jhobbs> i see
[20:14] <jhobbs> doh
[20:14] <jhobbs> thanks for pointing that out
[20:14] <cherylj> ah yeah, sorry.  Missed the link
[20:15] <jhobbs> i will try again with the right argument, thanks
[20:16] <cherylj> np, feel free to ping me here if you have other problems.
[21:22] <wallyworld> ericsnow: it seems there's a core issue about recording last sent id vs timestamp - once sorted out, we're close to being able to land stuff?
[21:23] <ericsnow> wallyworld: yep
[21:23] <mup> Bug #1595330 opened: When deploying a bundle, num_units defaults to zero if not specified <bundles> <juju-release-support> <usability> <juju-core:Triaged> <https://launchpad.net/bugs/1595330>
[21:23] <wallyworld> ericsnow: i do like id - if they are monotonically increasing, it's unambiguous
[21:24] <ericsnow> wallyworld: yep
[21:28] <katco> wallyworld: i was ocr today; spent first half reviewing, then worked on observer PR. making good headway there
[21:28] <wallyworld> awesome
[21:50] <redir> katco: are you accessing user info anywhere for auditing?
[21:51] <katco> redir: kind of. the observers for auditing hold current api user in state
[21:51] <katco> redir: but just the tag's name
[21:54] <redir> katco and there's no way that you would lookup a user after the fact, IIUC.
[21:55] <redir> katco: making sure there's no impending need to access deleted user information.
[21:56] <redir> and auditing is the only place I can think of where that might happen in the near future.
[21:57] <katco> redir: no, i don't think so. the audit message would include the user name as a string, so no dereferencing needed
[22:02] <alexisb> thumper, ping
[22:15] <redir> going for some air. bbiab.
[22:16] <anastasiamac> natefinch: ping
[22:30] <wallyworld> menn0: very tiny change to modify slightly a previous fix if you have a sec (blocker for beta 10) http://reviews.vapour.ws/r/5143/
[22:30] <menn0> wallyworld: looking
[22:32] <menn0> wallyworld: ship it
[22:33] <wallyworld> menn0: tyvm
[22:49] <mgz> wallyworld: I think you're misreading the bug
[22:50] <mgz> you don't need to set the port everywhere, you just can't pass an uninitialised int over the api
[22:50] <mgz> because that's a zero
[22:50] <wallyworld> mgz: i just reverted to previous behaviour
[22:51] <mgz> wallyworld: yeah, the fix is fine. the review description is just perplexing
[22:51] <mgz> non-controllers don't need the api port opened
[22:51] <mgz> they just need to not be told to open an invalid port range
[22:51] <wallyworld> which we were always doing
[22:51] <wallyworld> ie opening port
[22:52] <wallyworld> so least risk just to go to old behaviour for now
[22:52] <mgz> wallyworld: yeah, I agree
[22:52] <wallyworld> but i agree with you too
[22:52] <mgz> the right fix is presumably to change SetUpGroups or something though
[22:52] <mgz> but that doesn't need to happen here
[22:56] <wallyworld> mgz: yeah, it's all a bit messed up
[23:07]  * thumper crosses fingers
[23:16] <alexisb> thumper, ??
[23:17] <thumper> alexisb: trying to get something to work
[23:17] <thumper> btw, it isn't working
[23:17] <alexisb> should I cross my fingers too?
[23:17] <alexisb> would that help
[23:19] <thumper> maybe...
[23:24] <thumper> I'm pleased that lxd bootstraps so fast...
[23:24] <thumper> if 2 minutes is fast
[23:24]  * thumper waits some more
[23:29] <thumper> hmm...
[23:29] <thumper> kinda working
[23:29] <thumper> but I have surprising data...
[23:30] <alexisb> surprising how
[23:31] <thumper> unexpected
[23:31] <thumper> I need to work out how to pull this apart...