| wallyworld | axw: anastasiamac: may be delayed for standup, will ping | 00:09 |
|---|---|---|
| menn0 | thumper: another trivial PR, as discussed via email http://reviews.vapour.ws/r/3803 | 00:10 |
| * thumper looks | 00:11 | |
| thumper | shipit | 00:11 |
| axw | menn0: what magic did you use to get RB to recognise you renamed a file, rather than delete/add? | 00:13 |
| menn0 | axw: I did nothing | 00:14 |
| 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:15 |
| menn0 | axw: that PR is just a single "git mv" | 00:16 |
| * axw nods | 00:16 | |
| 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:32 |
| davecheney | ok | 00:36 |
| davecheney | for review, https://github.com/juju/juju/pull/4361 | 00:42 |
| wallyworld | axw: anastasiamac: free now if you are | 01:06 |
| axw | wallyworld: coming | 01:06 |
| === ses is now known as Guest22318 | ||
| thumper | cherylj: still around? | 02:39 |
| 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:40 |
| davecheney | meet in the standup hangout ? | 02:41 |
| cherylj | thumper: sure, give me a minute | 02:41 |
| thumper | davecheney: ack | 02:42 |
| 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:55 |
| anastasiamac | i'll dismiss it as "it's just me" :D | 02:56 |
| 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:23 |
| 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:24 |
| axw | maybe just "juju current" | 03:25 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:37 |
| anastasiamac | axw: sounds awesome - it'll b a fun one to do \o/ | 03:39 |
| thumper | axw: +1 on removing no args juju switch | 03:45 |
| natefinch-afk | nick natefinch | 03:46 |
| === natefinch-afk is now known as natefinch | ||
| natefinch | heh | 03:46 |
| natefinch | so.... what's the command to see what controller my commands will be working against? | 03:47 |
| 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:48 |
| 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 | 03:49 |
| 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:03 |
| 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:09 |
| natefinch | ericsnow: ship it! | 04:26 |
| natefinch | ericsnow: nvm, I see it's already been shipped. | 04:27 |
| ericsnow | natefinch: :) | 04:27 |
| 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:03 |
| 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:04 |
| 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:05 |
| axw | wallyworld: you should be using the UUIDs I think? | 05:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| axw | wallyworld: I think it's necessary until we have a model store | 05:11 |
| wallyworld | sadly so | 05:11 |
| 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:12 |
| 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:13 |
| anastasiamac | axw: r we likely to have other stores in jujuclient? | 05:52 |
| axw | anastasiamac: accounts | 05:52 |
| 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:53 |
| 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:54 |
| anastasiamac | axw: ClientStore sounds great then \o/ | 05:55 |
| 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:07 |
| 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:11 |
| wallyworld | axw: luckily api-info, api-endpoints commands are obsolete so that's a whole world of migration pain i can avoid \o/ | 06:32 |
| axw | wallyworld: really? what are the alternatives? | 06:33 |
| 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 | 06:34 |
| axw | wallyworld: I suspect we're going to have a lot of overlap. when are you likely to propose? | 08:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| axw | wallyworld: to NewAPI... functions | 08:31 |
| wallyworld | sometimes we only have the uuid, but i think that will go away | 08:31 |
| wallyworld | axw: quick chat in standup hangout? | 08:32 |
| axw | wallyworld: sorry was afk, one minute | 08:44 |
| === blahdeblah_ is now known as blahdeblah | ||
| dooferlad | frobware:hangout? | 09:03 |
| 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:26 |
| 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:27 |
| dimitern | voidspace, that should clear the know issues already fixed on master | 09:28 |
| 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:36 |
| dimitern | dooferlad, you'd love that I'm sure ^^ :) | 09:39 |
| dooferlad | dimitern: yea... | 09:40 |
| voidspace | dimitern: cool about master | 09:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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)" | 09:51 |
| dimitern | voidspace, dooferlad, I've rebased https://github.com/juju/juju/pull/4354 after the merge btw - still needs a review | 11:29 |
| voidspace | dimitern: ok | 12:11 |
| dimitern | voidspace, dooferlad, I hate to be a pest, but did you had a chance to look at that PR? | 12:51 |
| voidspace | dimitern: I'm looking at it now | 12:52 |
| dimitern | voidspace, tyvm! | 12:53 |
| 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:55 |
| voidspace | dimitern: right, I thought that was the case | 12:56 |
| voidspace | dimitern: good | 12:56 |
| 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:57 |
| voidspace | dimitern: yeah, oops... | 12:58 |
| 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:07 |
| voidspace | dimitern: alright, LGTM | 13:08 |
| dimitern | voidspace, yeah, sorry about that churn, but at least makes the tests easier to follow I believe | 13:13 |
| natefinch | ericsnow, katco: trivial patch for renaming comment to description - http://reviews.vapour.ws/r/3813/ | 14:54 |
| ericsnow | natefinch: ship-it | 14:59 |
| natefinch | ericsnow: thanks | 15:00 |
| natefinch | fwereade__: we have a card to fire the upgrade-charm hook when a new resource is uploaded... how do we do that? | 15:22 |
| === akhavr1 is now known as akhavr | ||
| perrito666 | omg unable to determine the series is like a bad dream that keeps returning | 15:47 |
| 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:48 |
| natefinch | gah, we talked about that in oakland... we gotta get rid of that stupid line in the version stuff | 15:49 |
| 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:57 |
| 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:58 |
| dimitern | voidspace, yeah, we need to call spaces read in ListSpaces | 15:59 |
| voidspace | dimitern: where does that id come from? | 15:59 |
| 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:00 |
| 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:01 |
| voidspace | dimitern: so a maasInstance is a created with a maasObject representing the node | 16:06 |
| 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:07 |
| 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:09 |
| 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:11 |
| natefinch | (when you're done your call) | 16:12 |
| mbruzek | natefinch: Have you ever seen this nonce.txt error ? | 16:16 |
| natefinch | mbruzek: hmm.... it definitely sounds familiar, though not something I've experienced personally | 16:18 |
| natefinch | mbruzek: that's supposed to be created by our cloudinit script | 16:19 |
| katco | mbruzek: isn't that created when you do --upload-tools ? | 16:20 |
| katco | or am i remembering something completely different... | 16:20 |
| mbruzek | natefinch: katco: Yeah it probably is, the cpc team said this was a core issue, but I can ask them again | 16:21 |
| 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:22 |
| dimitern | dooferlad, voidspace, yay! | 16:23 |
| dimitern | natefinch, hey | 16:34 |
| dimitern | natefinch, so there's definitely a need for a watcher for resources, like for config settings etc. | 16:35 |
| 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:36 |
| 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:37 |
| * ericsnow girds himself to enter the labyrinth | 16:38 | |
| cherylj | dimitern: pong. in a standup so responses will be slow | 16:38 |
| dimitern | cherylj, np, I just had a chat with alexisb about the state of maas-spaces | 16:39 |
| 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:40 |
| dimitern | voidspace, dooferlad ^^ | 16:41 |
| voidspace | great | 16:41 |
| dimitern | cherylj, if you think that's acceptable, we can do it tomorrow | 16:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| voidspace | dimitern: thanks | 16:47 |
| dimitern | voidspace, ah, let me think for a sec.. | 16:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| dimitern | cherylj, ah, fwiw we have a better solution in progress for selecting the correct controller addresses and mongo peers | 16:56 |
| 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:57 |
| 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:58 |
| dimitern | cherylj, ship it | 16:59 |
| cherylj | thanks, dimitern! | 16:59 |
| dimitern | :) np | 16:59 |
| dimitern | ok folks, eod of me | 17:00 |
| mup | Bug #1544158 opened: add explicit unit tests for network.MergedAddresses <juju-core:Triaged by cherylj> <https://launchpad.net/bugs/1544158> | 17:10 |
| cherylj | ehmagerd scp'ing to private fileshare is so slow | 17:21 |
| perrito666 | cherylj: off course it is, for some reason compunting never tried to solve the issue of sharing files decently | 17:25 |
| * perrito666 found a supplier that will deliver hardware replacement to him on the day... I have never felt more firstworldish | 17:26 | |
| tych0 | cherylj: do i need to have anyone's approval to merge https://github.com/juju/juju/pull/4355 ? | 17:48 |
| cherylj | ericsnow, natefinch can one of you guys review tych0's PR? ^^ | 17:51 |
| ericsnow | cherylj: I'll take a look | 17:51 |
| katco | tych0: you know about the whole $$merge$$ thing right? | 17:53 |
| ericsnow | cherylj, tych0: this one? http://reviews.vapour.ws/r/3800 | 17:53 |
| 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:54 |
| tych0 | cherylj: i have not | 17:55 |
| tych0 | i just deleted gosexy and built | 17:55 |
| tych0 | and it worked | 17:55 |
| ericsnow | tych0: LGTM with one thing to fix | 17:57 |
| 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 | 17:59 |
| 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:00 |
| ericsnow | tych0: yep | 18:04 |
| tych0 | cool, thanks | 18:04 |
| bogdanteleaga | anybody here using xenial? | 19:25 |
| jcastro | xenial here | 19:59 |
| === akhavr1 is now known as akhavr | ||
| katco | ericsnow: whatcha working on? | 20:20 |
| 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:21 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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 | 20:48 |
| katco | natefinch: meeting time | 21:02 |
| perrito666 | you know what is funnier? refactring those kind of tests :p | 21:16 |
| 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:20 |
| cherylj | tych0: it may take several hours as branches are tested one at a time | 21:21 |
| tych0 | ah, ok | 21:22 |
| alexisb | wallyworld_, non urgent ping when you are in | 21:36 |
| === akhavr1 is now known as akhavr | ||
| === _thumper_ is now known as thumper | ||
| marcoceppi | in alpha2, do I still need to use an environments.yaml? | 21:54 |
| 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:55 |
| === natefinch is now known as natefinch-afk | ||
| perrito666 | marcoceppi: oh, can you pastebin it? | 21:59 |
| marcoceppi | perrito666: http://paste.ubuntu.com/15011429/ | 22:01 |
| 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:02 |
| 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:03 | |
| perrito666 | marcoceppi: well those errors are incredibly unhelpful | 22:04 |
| marcoceppi | rick_h___ perrito666 weee | 22:05 |
| 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:06 |
| rick_h___ | marcoceppi: good to hear | 22:07 |
| marcoceppi | rick_h___: will nu gui see these models? | 22:07 |
| 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:08 |
| === blahdeblah_ is now known as blahdeblah | ||
| marcoceppi | I really wanted to just get a new svg.juju.solutions out but I kind of got sidetracked | 22:09 |
| marcoceppi | Makyo: you around? | 22:22 |
| 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:33 |
| axw | katco: sorry I didn't respond to the invite, I was asleep: ) | 22:51 |
| rick_h___ | marcoceppi: sexy | 22:52 |
| katco | axw: no worries at all; you were optional | 22:54 |
| perrito666 | thats a cruel thing to say to axw | 22:56 |
| perrito666 | you are so optional mate | 22:57 |
| axw | heh :) | 22:57 |
| axw | job title: superfluous | 22:57 |
| 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:01 |
| axw | anastasiamac: only reason I was going to look at it was to complete what we were talking about in mini-meeting yesterday | 23:02 |
| 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:03 |
| 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:04 |
| axw | anastasiamac: that's fairly low priority atm. important, but we can change it behind the scenes without impacting any other code | 23:05 |
| perrito666 | ok seems that compiling the tests and running hangout might be a bit too much for the laptop | 23:14 |
| 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:16 |
| perrito666 | davecheney: I wish, they have lovely cafeterias | 23:19 |
| davecheney | https://twitter.com/Stephenitis/status/697560639657680896 | 23:42 |
| davecheney | ^ this is good news | 23:42 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!