[00:09] <wallyworld> axw: anastasiamac: may be delayed for standup, will ping
[00:10] <menn0> thumper: another trivial PR, as discussed via email http://reviews.vapour.ws/r/3803
[00:11]  * thumper looks
[00:11] <thumper> shipit
[00:13] <axw> menn0: what magic did you use to get RB to recognise you renamed a file, rather than delete/add?
[00:14] <menn0> axw: I did nothing
[00:15] <menn0> axw: I think if the file is exactly the same and only moved RB does the right thing
[00:15] <menn0> axw: if you move it and then change it, RB gets confused
[00:15] <menn0> axw: that's my guess anyway
[00:15] <axw> menn0: yeah, sounds plausible
[00:15] <menn0> axw: this is the first time I've seen RB do that too
[00:16] <menn0> axw: that PR is just a single "git mv"
[00:16]  * axw nods
[00:32] <davecheney> thumper: cherylj sooo, master and 1.25 are blocked
[00:32] <davecheney> yet my JFDI is third in the queue, hmmmm
[00:32] <thumper> landing bot does non master/12.5 branches too remember
[00:36] <davecheney> ok
[00:42] <davecheney> for review, https://github.com/juju/juju/pull/4361
[01:06] <wallyworld> axw: anastasiamac: free now if you are
[01:06] <axw> wallyworld: coming
[02:39] <thumper> cherylj: still around?
[02:40] <cherylj> thumper: yeah, what's up?
[02:40] <thumper> cherylj: davecheney suggested that we have a quick hangout to sync about client side api error retries
[02:41] <davecheney> meet in the standup hangout ?
[02:41] <cherylj> thumper: sure, give me a minute
[02:42] <thumper> davecheney: ack
[02:55] <axw> anastasiamac: FYI, I can bootstrap/destroy/bootstrap lxd on cloud-credentials without any problems
[02:55] <anastasiamac> axw: i was afraid u'd say that...
[02:56] <anastasiamac> i'll dismiss it as "it's just me" :D
[03:23] <axw> wallyworld: did we discuss dropping the no-args variant of "juju switch"? currently "juju switch" will show the active model name, which feels like a weird command to have to use
[03:24] <axw> wallyworld: IMO we should have a more obvious command specifically for that purpose
[03:24] <axw> wallyworld: "juju current-model", or something like that
[03:25] <axw> maybe just "juju current"
[03:31] <wallyworld> axw: that has come up before, with external stakeholders, and it had traction at one stage. i do agree but had thought we had reverted to accepting juju switch with no args as showing what's current. i'll ask around
[03:32] <anastasiamac> wallyworld: axw: don't we show "current" in list- commands?
[03:32] <anastasiamac> spec says mark them with *
[03:32] <axw> anastasiamac: we do, but we shouldn't have to make an API call to show the current controller/model
[03:32] <axw> anastasiamac: which the list commands require
[03:32] <wallyworld> list-controllers is not an api call
[03:32] <axw> wallyworld: list-models is though
[03:32] <wallyworld> yes
[03:33] <axw> wallyworld: "juju current" would print the current model, not controller
[03:33] <wallyworld> just being clear wrt controllers to avoid potential confusion
[03:33] <axw> ok, sure
[03:37] <anastasiamac> wallyworld: axw: m putting the card for injecting store into command off in favour of list-controllers...
[03:37] <anastasiamac> will get back to it when I (we/anyone) get a chance...
[03:37] <axw> anastasiamac: sure. I was thinking I *might* do that one while I'm working on switch
[03:37] <wallyworld> ok. i think you'll need placeholders for some columns
[03:39] <anastasiamac> axw: sounds awesome - it'll b a fun one to do \o/
[03:45] <thumper> axw: +1 on removing no args juju switch
[03:46] <natefinch-afk> nick natefinch
[03:46] <natefinch> heh
[03:47] <natefinch> so.... what's the command to see what controller my commands will be working against?
[03:48] <axw> natefinch: undecided
[03:48] <natefinch> axw: ok :)
[03:48] <axw> natefinch: you'll be able to see with "juju list-controllers" which are available, and which is active
[03:48] <axw> natefinch: what's undecided is whether there'll be another command to show the current controller/model
[03:49] <axw> one htat's not "juju switch"
[03:49] <natefinch> definitely juju switch was a terribly unintuitive way of seeing what environment you were on
[04:03] <natefinch> ericsnow: thanks for the fixes to those bugs. I was just running into that
[04:03] <ericsnow> natefinch: yep :)
[04:03] <natefinch> ericsnow: lemme see if I can review it real quick so we can get it in
[04:09] <natefinch> ericsnow:  reviewed... a few things to think about, but I think it can land as-is (maybe remove one unneeded log statement)
[04:09] <ericsnow> natefinch: thanks
[04:26] <natefinch> ericsnow: ship it!
[04:27] <natefinch> ericsnow: nvm, I see it's already been shipped.
[04:27] <ericsnow> natefinch: :)
[05:03] <thumper> laters...
[05:03] <axw> wallyworld anastasiamac: just to confirm your changes don't involve adding models to ControllerStore, right?
[05:03] <axw> later
[05:03] <wallyworld> axw: no, i don't want to do that, i think controllers.yaml is judt for controllersd
[05:03] <wallyworld> agree?
[05:04] <wallyworld> axw: but i'm having an issue where i now can't map from model->controller because the info is missing from cache.yaml
[05:04] <axw> wallyworld: right... but ControllerStore will have methods for accessing model info too. because they're related to controllers
[05:04] <wallyworld> i may need a temp solution
[05:05] <axw> wallyworld: what info is that?
[05:05] <wallyworld> axw: given a model name, i need to know the controller name that hosts that model
[05:05] <wallyworld> we used to get that from cache.yaml
[05:07] <axw> wallyworld: you should be using the UUIDs I think?
[05:08] <axw> wallyworld: is your branch on github yet? can I look?
[05:08] <wallyworld> axw: yes, that's what used to happen under the covers. the cli knows the name of it's model; from there it looked up the model uuid, and then got the controller uuid, and from there the api info
[05:08] <wallyworld> but now we don't store controller or model stuff in cache.yaml
[05:09] <wallyworld> we only have controller by name from controller.yaml
[05:09] <wallyworld> my branch is very much wip, lots of stuff commented out
[05:10] <wallyworld> i may have to go back to storing controller and model stuff in cache.yaml for now
[05:10] <wallyworld> but removing that allowed the code to be  lot cleaner
[05:11] <axw> wallyworld: I think it's necessary until we have a model store
[05:11] <wallyworld> sadly so
[05:12] <axw> wallyworld: I'll work on that now, since it's needed for switching
[05:12] <wallyworld> the code to persist controller stuff is much cleaner without having to cater for both cache.yaml and controller.yaml
[05:12] <wallyworld> yep
[05:12] <wallyworld> axw: at least i'll remove the bootstrap config stuff etc
[05:13] <wallyworld> or try to, until i hot the next roadblock
[05:13] <axw> anastasiamac wallyworld: any objections to the name jujuclient.ClientStore as an amalgamation of ControllerStore, ModelStore, etc.?
[05:13] <axw> wallyworld: SGTM
[05:13] <wallyworld> nope, sounds good
[05:13] <wallyworld> my branch is all f*cked up, got to replace stuff back to how it was, sigh
[05:52] <anastasiamac> axw: r we likely to have other stores in jujuclient?
[05:52] <axw> anastasiamac: accounts
[05:53] <axw> anastasiamac: not sure if there's anything else
[05:53] <anastasiamac> axw: so ClientStore is for controllers and models; and AccountStore for accounts?
[05:53] <axw> anastasiamac: ClientStore will be for all of them
[05:54] <axw> anastasiamac: but you can still get specific ones
[05:54] <axw> anastasiamac: i.e. ClientStore is just the combination of all the others
[05:55] <anastasiamac> axw: ClientStore sounds great then \o/
[06:07] <axw> wallyworld: also need accounts.yaml before we can get rid of cache.yaml, because that's where user/pass is
[06:07] <axw> I suppose I'll do that at the same time/directly after
[06:11] <wallyworld> axw: exactly, so i'm adding todos around where we'd use accounts.yaml
[06:11] <wallyworld> it's all a bit of a mess atm
[06:32] <wallyworld> axw: luckily api-info, api-endpoints commands are obsolete so that's a whole world of migration pain i can avoid \o/
[06:33] <axw> wallyworld: really? what are the alternatives?
[06:34] <wallyworld> axw: i need to check the specs, i think we'll work it into the list-controllers cli or something like that
[06:34] <axw> wallyworld: that would make sense. probably just have it in the YAML for scripts to pull out
[06:34] <wallyworld> more or less
[08:27] <axw> wallyworld: I suspect we're going to have a lot of overlap. when are you likely to propose?
[08:28] <wallyworld> axw: i have a shittonne of tests to fix, just got it compiling. i have introduced a temporary ControllerModel struct to hold controller and model uuid stored in the existing cache.yaml file
[08:28] <axw> wallyworld: mmkay
[08:29] <wallyworld> the ControllerModle struct is used in place of the old APIEndpoints struct which contained addresses etc as well as the model and controller uuid
[08:29] <wallyworld> so it's a way of retaining the current recording of association between controller and model using the existing files
[08:29] <axw> O
[08:30] <wallyworld> does that make sense?
[08:30] <axw> wallyworld: that's just temporary tho? what's the long term plan?
[08:30] <wallyworld> to use the stuff you're working on
[08:30] <axw> wallyworld: I was planning to pass controller name, model name, and store
[08:31] <axw> wallyworld: to NewAPI... functions
[08:31] <wallyworld> sometimes we only have the uuid, but i think that will go away
[08:32] <wallyworld> axw: quick chat in standup hangout?
[08:44] <axw> wallyworld: sorry was afk, one minute
[09:03] <dooferlad> frobware:hangout?
[09:26] <voidspace> dimitern: did you see the maas-spaces CI run(s)?
[09:26] <voidspace> dimitern: still a couple of errors " gomaasapi: got error back from server: 400 BAD REQUEST ({"distro_series": ["'trusty' is not a valid distro_series]"
[09:26] <voidspace> dimitern: a bunch of known issues that aren't our fault
[09:27] <voidspace> dimitern: plus another maas one, unrecognised architecture for the centos test
[09:27] <dimitern> voidspace, yeah, it's getting close
[09:27] <dimitern> voidspace, I've merged latest master and set it to land btw
[09:28] <dimitern> voidspace, that should clear the know issues already fixed on master
[09:36] <dimitern> voidspace, and .. oh joy :/ another discovery from yesterday: https://bugs.launchpad.net/maas/+bug/1543968
[09:36] <mup> Bug #1543968: MAAS 1.9.0 allows non-unique space names and shows no space id in a subnet <MAAS:New> <https://launchpad.net/bugs/1543968>
[09:39] <dimitern> dooferlad, you'd love that I'm sure ^^ :)
[09:40] <dooferlad> dimitern: yea...
[09:40] <voidspace> dimitern: cool about master
[09:41] <voidspace> dimitern: to make it worse, when they reference spaces (for example on subnets) - they do it by *name* not by id
[09:41] <dimitern> maas is making really hard for juju to accept its imposed spaces management
[09:41] <voidspace> dimitern: so if we want to use provider id we have to look them up by name to find the id
[09:42] <voidspace> dimitern: and if the names are duplicated that's then impossible :-)
[09:42] <dooferlad> dimitern: I think we just have to say that we can't support spaces on the current MAAS.
[09:42] <dimitern> voidspace, nope, that's not unambiguous - we need to list all spaces and get the ids from there
[09:42] <dimitern> dooferlad, only if ..
[09:42] <voidspace> dimitern: unless they have two spaces with the same name and a different id as your bug report says
[09:43] <voidspace> dimitern: so if it's space "foo", which "foo" is it?
[09:43] <dimitern> voidspace, when you do discovery do you list the spaces or only subnets?
[09:43] <voidspace> dimitern: list spaces which have all subnets
[09:43] <dimitern> voidspace, so you then have all ids and names - duplicates or not
[09:44] <voidspace> dimitern: but when we look up the links on an interface, the referenced subnet tells us the space *name*
[09:44] <dooferlad> dimitern: what else can we do? It is broken. If they fix this and change the restriction on whitespace in a point release then we can just use a minimum MAAS version of 1.9.1
[09:44] <voidspace> dimitern: and this is in provider code, so we can't just ask state
[09:44] <dooferlad> dimitern: without fixing your bug we can't use names that match their names.
[09:44] <voidspace> dimitern: we could list all spaces and subnets and get the id from there
[09:45] <dimitern> voidspace, that's unavoidable I'm afraid
[09:45] <dimitern> we can only do damage control atm
[09:45] <dooferlad> dimitern, voidspace: We can't work around this in a user friendly way. We haven't released yet. Isn't it reasonable to get MAAS fixed and require the fixed version?
[09:46] <voidspace> dooferlad: sounds reasonable to me
[09:46] <dimitern> voidspace, dooferlad, I bet it will still land on us eventually
[09:46] <voidspace> dooferlad: their space naming model doesn't match what we need and I'm sure it's an oversight on their part
[09:46] <dimitern> i.e. "you are not talking - why did you discover this that late" ?
[09:47] <dooferlad> dimitern: we are talking. It is a bug. We didn't notice it because it isn't our job to validate MAAS.
[09:47] <dimitern> dooferlad, I know, but that's what will come to - all I'm saying
[09:48] <dimitern> dooferlad, voidspace, which means our approach with renaming spaces on discovery was the only thing we can do now
[09:48] <dooferlad> dimitern: if we take that attitude we are screwed anyway. We are better off being positive. We found the problem before any Juju + MAAS deployment suffered and it can be fixed before that point.
[09:49] <voidspace> dooferlad: yep, +1 to that
[09:49] <dimitern> let's chat in 10m
[09:49] <dooferlad> dimitern: +1
[09:49] <dooferlad> (no, not 11 minutes)
[09:51] <dimitern> I think the issue stems from the attitude "we don't care how you set up your spaces or name them - you're the admin, you should know (no matter there's juju to care about)"
[11:29] <dimitern> voidspace, dooferlad, I've rebased https://github.com/juju/juju/pull/4354 after the merge btw - still needs a review
[12:11] <voidspace> dimitern: ok
[12:51] <dimitern> voidspace, dooferlad, I hate to be a pest, but did you had a chance to look at that PR?
[12:52] <voidspace> dimitern: I'm looking at it now
[12:53] <dimitern> voidspace, tyvm!
[12:55] <dimitern> voidspace, btw at least I found maas does not allow deleting a space a subnet is using: this: http://paste.ubuntu.com/15008282/
[12:56] <voidspace> dimitern: right, I thought that was the case
[12:56] <voidspace> dimitern: good
[12:57] <dimitern> voidspace, haha! see the comment in bug 1543968: Critical for the lack of uniqueness on space names. That's close to unforgivable
[12:57] <mup> Bug #1543968: MAAS 1.9.0 allows non-unique space names and shows no space id in a subnet <MAAS:Triaged> <https://launchpad.net/bugs/1543968>
[12:57] <dimitern> dooferlad, ^^
[12:58] <voidspace> dimitern: yeah, oops...
[13:07] <voidspace> dimitern: the basic changes all look sound
[13:07] <voidspace> plus the tests
[13:07] <dimitern> voidspace, awesome, thanks!
[13:07] <voidspace> dimitern: lots of "tinkering" with the code makes the diff harder to read (moving stuff around without semantic changes)
[13:07] <voidspace> dimitern: nearly at the end
[13:08] <voidspace> dimitern: alright, LGTM
[13:13] <dimitern> voidspace, yeah, sorry about that churn, but at least makes the tests easier to follow I believe
[14:54] <natefinch> ericsnow, katco: trivial patch for renaming comment to description - http://reviews.vapour.ws/r/3813/
[14:59] <ericsnow> natefinch: ship-it
[15:00] <natefinch> ericsnow: thanks
[15:22] <natefinch> fwereade__: we have a card to fire the upgrade-charm hook when a new resource is uploaded... how do we do that?
[15:47] <perrito666> omg unable to determine the series is like a bad dream that keeps returning
[15:48] <alexisb> wake up perrito666, wake up!
[15:48] <perrito666> honestly, how can we be panicking on the latest stable version of ubuntu, it is insane
[15:49] <natefinch> gah, we talked about that in oakland... we gotta get rid of that stupid line in the version stuff
[15:57] <voidspace> dimitern: ping
[15:57] <dimitern> voidspace, pong
[15:57] <voidspace> dimitern: just to confirm with you - at the moment we are using MAAS space *name* as the provider id
[15:57] <voidspace> dimitern: (see maasEnviron.subnetFromJson)
[15:58] <voidspace> dimitern: in fact we never call the spaces api directly - we fetch all subnets and build the spaces information from the subnets (because we only care about spaces that actually have subnets)
[15:58] <dimitern> voidspace, yeah, we need to fix this soon
[15:58] <voidspace> dimitern: and the subnets api doessn't give us a space id - only the name
[15:58] <dimitern> voidspace, we're already using provider ids in acquireNode though
[15:59] <dimitern> voidspace, yeah, we need to call spaces read in ListSpaces
[15:59] <voidspace> dimitern: where does that id come from?
[16:00] <voidspace> dimitern: for the endpoint bindings for acquireNode ?
[16:00] <voidspace> dimitern: if we take it from the provider id from space in *state* then you have a name
[16:00] <dimitern> voidspace, yeah
[16:00] <dimitern> voidspace, I know :)
[16:00] <dimitern> voidspace, but at least we pass it correctly
[16:01] <dimitern> voidspace, to acquireNode, so once we fix what we store in state, we'll be a step closer
[16:01] <voidspace> dimitern: you mean it's currently broken
[16:06] <voidspace> dimitern: so a maasInstance is a created with a maasObject representing the node
[16:07] <voidspace> dimitern: if the instance needs to call an api method not on the node that may not be possible
[16:07] <voidspace> dimitern: I may need to change the way the instance is created
[16:07] <voidspace> dimitern: just checking if I can get back to the client from the maasObject I have
[16:07] <dimitern> voidspace, sorry, in a call - will get back to you soon
[16:09] <mbruzek> Has anyone here bootstrapped a xenial image?  I am getting a juju error on amazon about the nonce.txt file not being found, and it aborts my bootstrap: http://paste.ubuntu.com/15009092/
[16:11] <natefinch> dimitern: we're trying to look into how the upgrade-charm hook gets fired... we want to have that hook fired when we upload a new resource for a service... it looks like that means we should change the uniter's remotewatcher to watch for resources as well?
[16:12] <natefinch> (when you're done your call)
[16:16] <mbruzek> natefinch: Have you ever seen this nonce.txt error ?
[16:18] <natefinch> mbruzek: hmm.... it definitely sounds familiar, though not something I've experienced personally
[16:19] <natefinch> mbruzek: that's supposed to be created by our cloudinit script
[16:20] <katco> mbruzek: isn't that created when you do --upload-tools ?
[16:20] <katco> or am i remembering something completely different...
[16:21] <mbruzek> natefinch: katco: Yeah it probably is, the cpc team said this was a core issue, but I can ask them again
[16:22] <dooferlad> dimitern, voidspace: one failure on the latest run: http://reports.vapour.ws/releases/3594/job/run-unit-tests-trusty-ppc64el/attempt/4563
[16:22] <dooferlad> allwatcher_internal_test.go:844: TestStateWatcherTwoModels.pN47_github_com_juju_juju_state.allWatcherStateSuite
[16:23] <dimitern> dooferlad, voidspace, yay!
[16:34] <dimitern> natefinch, hey
[16:35] <dimitern> natefinch, so there's definitely a need for a watcher for resources, like for config settings etc.
[16:36] <katco> ericsnow: ^^^
[16:36] <dimitern> natefinch, depending on how the resources of a service are stored in state, it might be a simple notify watcher
[16:37] <dimitern> natefinch, katco, ericsnow, however, it's been *some* time since I was around the uniter code, so where those changes need to go I'm not sure - fwereade__  should be a better source
[16:37] <dimitern> cherylj, ping
[16:38]  * ericsnow girds himself to enter the labyrinth
[16:38] <cherylj> dimitern: pong.  in a standup so responses will be slow
[16:39] <dimitern> cherylj, np, I just had a chat with alexisb about the state of maas-spaces
[16:40] <dimitern> cherylj, and it looks like with the yesterday's changes we're down to 1 failure now (ppc64), and 2 CI issues causing container-networking and aws-deploy-xenial to fail
[16:40] <dimitern> cherylj, so I suggested to wait for another run with today's changes and if it's not worse off tomorrow - do the merge
[16:40] <dimitern> cherylj, since it looks like our best chance this week
[16:41] <dimitern> voidspace, dooferlad ^^
[16:41] <voidspace> great
[16:41] <dimitern> cherylj, if you think that's acceptable, we can do it tomorrow
[16:42] <dimitern> voidspace, btw can you have a look at that TestLoginsDuringUpgrade failure btw
[16:42] <voidspace> dimitern: where?
[16:42] <dimitern> voidspace, it's flaky and connected to spaces discovery
[16:42] <voidspace> dimitern: ah, ok
[16:42] <dimitern> voidspace, in cmd/juju somewhere.. let me have a look
[16:42] <cherylj> dimitern: that's good news.  I know there's one fix I need to get into master
[16:42] <voidspace> dimitern: if it gets a login failure it probably needs to wait and retry
[16:42] <cherylj> dimitern: and I'll probably want your review on it :)
[16:42] <voidspace> dimitern: as if discovery hasn't yet completed it will block temporarily
[16:42] <dimitern> cherylj, awesome! sure - I'll have a look
[16:43] <voidspace> dimitern: either that, or the test can patch discovery to complete immediately
[16:43] <dimitern> voidspace, I tried both of those suggestions, up to the point of patching the worker creation
[16:44] <voidspace> dimitern: well, it was worker creation I was suggesting patching
[16:44] <voidspace> dimitern: to return a dummy worker and a closed channel
[16:44] <dimitern> voidspace, but the test itself is a bit poorly written - it assumes that if it patches the upgrade steps block, it should be able to login almost immediately
[16:45] <voidspace> dimitern: I don't understand that, I'd have to look at the test
[16:45] <voidspace> dimitern: I'll do it after this
[16:45] <voidspace> dimitern: so, another question - the maasInstance can't call the spaces api method because it only has a node maasObject
[16:45] <voidspace> dimitern: and you can't go back from a node object to the client
[16:46] <voidspace> dimitern: so a maasInstance will need either a reference to the maas client or to the environ itself
[16:46] <voidspace> dimitern: which do you prefer?
[16:46] <voidspace> dimitern: a maas instance having a reference to the environ (the provider substrate) seems reasonable
[16:46] <dimitern> voidspace, it's there: ./featuretests/upgrade_test.go:86:func (s *upgradeSuite) TestLoginsDuringUpgrade(c *gc.C) {
[16:47] <voidspace> dimitern: thanks
[16:47] <dimitern> voidspace, ah, let me think for a sec..
[16:48] <dooferlad> dimitern, voidspace: have made progress but am going to call it a day. If I get the urge I will do more hacking later, but I think I have at least solved my current problems.
[16:49] <dimitern> dooferlad, sure, get some rest :)
[16:49] <dooferlad> dimitern: thanks. Hope you get some too at some point!
[16:49] <dimitern> voidspace, so if you have an instance of maasEnviron, you can get the client from there
[16:49] <natefinch> ericsnow, katco: I think making a new watcher shouldn't be a big deal.  We can model it after the unitassigner, which works much the same way... just fires an event when there's a new item in a specific collection
[16:49] <voidspace> dimitern: right
[16:50] <dimitern> dooferlad, :) ta
[16:50] <voidspace> dimitern: the maasInstance doesn't have that - my suggestion is to add it
[16:50] <cherylj> dimitern: http://reviews.vapour.ws/r/3816/
[16:50] <voidspace> dooferlad: o/
[16:50] <natefinch> ericsnow, katco: also, unitassigner is very easy to grep for.  The watcher created in state/watcher.go  WatchForUnitAssignment
[16:51] <katco> natefinch: that may be so. i think we should have a plan and then query wallyworld_, axw for validity
[16:51] <natefinch> katco: sounds like a good idea'
[16:51] <dimitern> voidspace, I've tried that before and I had to change quite a lot of code and tests
[16:51] <dimitern> cherylj, will have a look shortly
[16:51] <katco> natefinch: ericsnow: (or fwereade__ if he's available)
[16:51] <cherylj> thanks, dimitern!
[16:52] <ericsnow> katco: agreed
[16:52] <voidspace> dimitern: it doesn't need to be set, it can be nil - so it shouldn't need to change any tests
[16:52] <voidspace> dimitern: except new tests that *use* it
[16:53] <dimitern> voidspace, yeah I suppose - give it a try
[16:53] <voidspace> dimitern: ok, cool - thanks
[16:53] <dimitern> voidspace, it will be easier to implement a helper taking *MAASObject and extracting the information from there
[16:54] <voidspace> dimitern: you can't get there from an arbitrary *MAASObject
[16:54] <dimitern> voidspace, like I did for maasObjectNetworkInterfaces fwiw
[16:54] <voidspace> dimitern: oh, I see - to actually get the spaces
[16:54] <dimitern> voidspace, yeah - the parsing
[16:54] <voidspace> dimitern: I was thinking of implementing it on the environ, because we'll need it there anyway - and then have the instance just call the environ method
[16:54] <dimitern> voidspace, as for getting it - sure, with the client.GetSubObject("spaces") I guess
[16:55] <dimitern> voidspace, also works, yeah - I'd leave you to it then :)
[16:55] <voidspace> dimitern: not if the MAASObject represents a node - which is how the instance is created
[16:56] <dimitern> cherylj, ah, fwiw we have a better solution in progress for selecting the correct controller addresses and mongo peers
[16:57] <cherylj> dimitern: does it happen at bootstrap?
[16:57] <dimitern> cherylj, but it will get improved in steps
[16:57] <dimitern> cherylj, right after the node boots as one of the first few things the MA will do
[16:58] <cherylj> dimitern: it's good to know, but we need something to fix CI failures we're seeing now :)
[16:58] <dimitern> cherylj, yeah, sure - just a heads up :)
[16:58] <cherylj> thanks :)
[16:59] <dimitern> cherylj, ship it
[16:59] <cherylj> thanks, dimitern!
[16:59] <dimitern> :) np
[17:00] <dimitern> ok folks, eod of me
[17:10] <mup> Bug #1544158 opened: add explicit unit tests for network.MergedAddresses <juju-core:Triaged by cherylj> <https://launchpad.net/bugs/1544158>
[17:21] <cherylj> ehmagerd scp'ing to private fileshare is so slow
[17:25] <perrito666> cherylj: off course it is, for some reason compunting never tried to solve the issue of sharing files decently
[17:26]  * perrito666 found a supplier that will deliver hardware replacement to him on the day... I have never felt more firstworldish
[17:48] <tych0> cherylj: do i need to have anyone's approval to merge https://github.com/juju/juju/pull/4355 ?
[17:51] <cherylj> ericsnow, natefinch can one of you guys review tych0's PR?  ^^
[17:51] <ericsnow> cherylj: I'll take a look
[17:53] <katco> tych0: you know about the whole $$merge$$ thing right?
[17:53] <ericsnow> cherylj, tych0: this one? http://reviews.vapour.ws/r/3800
[17:54] <tych0> katco: yeah, but i don't know about what the rules are about when i can merge and can't :)
[17:54] <tych0> ericsnow: yes, at least the numbers match up :)
[17:54] <katco> tych0: just need a +1 on the reviews.vapour.ws site, and then you can do a $$merge$$ :)
[17:54] <tych0> katco: right. i don't have a +1 yet :(
[17:54] <cherylj> tych0: have you tried building on a clean wily system?  That will let you know if there will be build failures in CI
[17:55] <tych0> cherylj: i have not
[17:55] <tych0> i just deleted gosexy and built
[17:55] <tych0> and it worked
[17:57] <ericsnow> tych0: LGTM with one thing to fix
[17:59] <tych0> ericsnow: ah, there isn't an implementation of it
[17:59] <tych0> ericsnow: there's a lot of those stubs that are unimplemented actually
[18:00] <ericsnow> tych0: oh, I bet we are embedding the interface (if so you can drop that review comment)
[18:00] <tych0> ok
[18:00] <tych0> ericsnow: ok. i just clicked drop. safe to $$merge$$ now?
[18:04] <ericsnow> tych0: yep
[18:04] <tych0> cool, thanks
[19:25] <bogdanteleaga> anybody here using xenial?
[19:59] <jcastro> xenial here
[20:20] <katco> ericsnow: whatcha working on?
[20:21] <katco> natefinch: how's your card coming? anything i can do to help?
[20:21] <ericsnow> katco: oops, forgot to grab the card
[20:21] <katco> ericsnow: np, why i asked :)
[20:29] <natefinch> katco: lotta busywork writing tests.... the functionality is all there, just writing out a million struct literals for tests is a pain (since this thing needs a list of resources for the service and then a list for each unit)
[20:29] <natefinch> katco: getting close though
[20:30] <katco> natefinch: yeah, understand that is a pain =/
[20:30] <katco> natefinch: still think you'll have it done today? hopefully before demo walkthrough?
[20:31] <natefinch> katco: definitely by EOD, but possibly not by demo walkthrough.  I can certainly demo it as-is, it's just the tests left to do
[20:32] <katco> natefinch: cool, i don't think that's a huge deal. still have till friday to clean up demo, so it's fine if that 1 aspect is working
[20:32] <katco> natefinch: thx for the update
[20:48] <natefinch> gah... I don't know what is up with list_charm_resource.go and it's test file... but git really doesn't like rebasing them
[21:02] <katco> natefinch: meeting time
[21:16] <perrito666> you know what is funnier? refactring those kind of tests :p
[21:20] <tych0> hi cherylj, do i need to do anything to trigger the CI here? http://reports.vapour.ws/releases#lxd-container-type
[21:20] <tych0> looks like it hasn't run after my last commit to lxd-container-type
[21:21] <cherylj> tych0: it may take several hours as branches are tested one at a time
[21:22] <tych0> ah, ok
[21:36] <alexisb> wallyworld_, non urgent ping when you are in
[21:54] <marcoceppi> in alpha2, do I still need to use an environments.yaml?
[21:55] <marcoceppi> I ran init and it create .local/share/juju, etc
[21:55] <marcoceppi> but if I try to create-model after "bootstrapping" I get some odd errors
[21:59] <perrito666> marcoceppi: oh, can you pastebin it?
[22:01] <marcoceppi> perrito666: http://paste.ubuntu.com/15011429/
[22:02] <rick_h___> marcoceppi: create model requires passing a yaml -c option currently for the auth tokens and such to use
[22:02] <rick_h___> marcoceppi: the idea being you can change the credentials used for different models
[22:02] <rick_h___> marcoceppi: we've got a request in to wallyworld_ to have it default sanely to the ones used to bootstrap/etc
[22:02] <rick_h___> marcoceppi: but I don't know that's hit yet
[22:02] <marcoceppi> rick_h___: so this goes away when credentials/clouds are the way to roll out instead of environments.yaml ?
[22:02] <rick_h___> marcoceppi: yes
[22:03] <rick_h___> marcoceppi: but it will turn into an option
[22:03] <perrito666> marcoceppi: checking
[22:03] <marcoceppi> rick_h___: cool
[22:03]  * marcoceppi tries
[22:03] <rick_h___> marcoceppi: so for now, create a 'aws.yaml' with the settings it's fussing about and pass iot into create-model with a -c flag
[22:03]  * wallyworld_ in meeting, will read backscroll in a bit
[22:03]  * marcoceppi tries
[22:04] <perrito666> marcoceppi: well those errors are incredibly unhelpful
[22:05] <marcoceppi> rick_h___ perrito666 weee
[22:06] <rick_h___> marcoceppi: woot
[22:06] <marcoceppi> rick_h___: I got tripped up
[22:06] <marcoceppi> rick_h___: because I was doing -c /path/to/file
[22:06] <marcoceppi> but that was not the right thing
[22:06] <marcoceppi> and I was about to make :( at you all
[22:06] <marcoceppi> but then I checked myself
[22:06] <marcoceppi> prior to wrecking myself
[22:06] <marcoceppi> and I created a model
[22:06] <marcoceppi> it's glorious
[22:07] <rick_h___> marcoceppi: good to hear
[22:07] <marcoceppi> rick_h___: will nu gui see these models?
[22:08] <rick_h___> marcoceppi: yes, juju deploy the gui into the admin/first model
[22:08] <rick_h___> marcoceppi: and it'll see them, list the models, and you can switch between them
[22:08] <rick_h___> marcoceppi: I've been using that for demos recently
[22:08] <marcoceppi> it was totally worth installing golang on this computer
[22:08] <rick_h___> marcoceppi: :)
[22:08] <perrito666> marcoceppi: it is always worth to install golang ;)
[22:09] <marcoceppi> I really wanted to just get a new svg.juju.solutions out but I kind of got sidetracked
[22:22] <marcoceppi> Makyo: you around?
[22:33] <rick_h___> marcoceppi: they're just coming back from team dinner tonight at the sprint
[22:33] <rick_h___> marcoceppi: I'd not count on it, maybe email instead
[22:33] <marcoceppi> rick_h___: no worries, I got it sorted
[22:33] <marcoceppi> rick_h___: http://svg.juju.solutions/?bundle-file=https://raw.githubusercontent.com/whitmo/bundle-kubernetes/master/bundles.yaml
[22:33] <rick_h___> ah cool
[22:51] <axw> katco: sorry I didn't respond to the invite, I was asleep: )
[22:52] <rick_h___> marcoceppi: sexy
[22:54] <katco> axw: no worries at all; you were optional
[22:56] <perrito666> thats a cruel thing to say to axw
[22:57] <perrito666> you are so optional mate
[22:57] <axw> heh :)
[22:57] <axw> job title: superfluous
[23:01] <axw> anastasiamac: accounts.yaml marshal/unmarshal is assigned to you; ok if I assign to myself?
[23:01] <anastasiamac> axw: yes but i was going tos tart on it today
[23:01] <anastasiamac> axw: i have list- and show- proposed
[23:01] <anastasiamac> but want to clean it a bit today too
[23:01] <anastasiamac> it=them*
[23:02] <axw> anastasiamac: only reason I was going to look at it was to complete what we were talking about in mini-meeting yesterday
[23:03] <axw> anastasiamac: so we have the correct final approach for opening API connections
[23:03] <anastasiamac> axw: go ahead if it's buringin then \o/
[23:03] <anastasiamac> sounds good
[23:03] <davecheney> cherylj: what's the status of 1.25.4 ?
[23:04] <davecheney> i'm building up a lot of chagnes on master that should be backported to 1.25
[23:04] <anastasiamac> axw: but if u r lookiing for things to do, I'd love to see what u'd do with file locks :D
[23:05] <axw> anastasiamac: that's fairly low priority atm. important, but we can change it behind the scenes without impacting any other code
[23:14] <perrito666> ok seems that compiling the tests and running hangout might be a bit too much for the laptop
[23:16] <davecheney> whee, just looked at the org chart, i have 6 manager above me
[23:16] <davecheney> only 4 more and we'll be microsoft class
[23:16] <wallyworld_> alexisb: standup if you are free
[23:19] <perrito666> davecheney: I wish, they have lovely cafeterias
[23:42] <davecheney> https://twitter.com/Stephenitis/status/697560639657680896
[23:42] <davecheney> ^ this is good news