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