[00:11] cherylj: it looks like gopkg.in/yaml.v1 is missing from the dependencies.tsv [00:24] with juju init deprecated in 2.0, how would one go about setting params for a private openstack cloud? [00:26] the command-changess page links to https://jujucharms.com/docs/devel/juju-config.md as a referenc for the new method, which is a broken link [00:28] Bug #1548564 opened: restart failed upgrade

[00:29] alternatively, is there an another way to fix the "ERROR juju.cmd supercommand.go:429 cannot set initial environ constraints: index file has no data for cloud {RegionOne http://192.168.4.11:5000/v2.0} not found" error? (http://pastebin.com/RXKmg2gC) [00:31] Bug #1548564 changed: restart failed upgrade

[00:41] kilty, by params you mean params that were previously set in environments.yaml? [00:43] Bug #1548564 opened: restart failed upgrade

[00:46] bogdanteleaga: trying to deploy juju on a private openstack cloud - when I install juju-core2, how do I set the auth url, user/pass, tenant name, etc? [00:55] kilty, https://paste.ubuntu.com/15127859/, just at the bottom [00:56] basically the whole configuration got split up amongst more files, or it can be specified from the cli [01:01] awesome [01:01] thank you - I'll give that a shot tomorrow morning [02:03] anastasiamac: yeah, I saw. Thanks! [02:43] grrr [02:43] * thumper deals with icky merge from trunk [02:43] changes to code I have moderately attacked with a machette during refactoring [02:48] * thumper makes a big sad face [03:08] axw: whenever you have a chance https://github.com/juju/romulus/pull/11 [03:09] wallyworld: sure, looking [03:10] wallyworld: hrm, can you hold off a bit? I'm updating the interface to take an account name as well as controller name [03:10] for ModelGetter and friends [03:10] ok [03:10] wallyworld: won't be much more of a change [03:10] np, i'll wait [03:11] cherylj: i'd hardly class that "lxd" not being in list-clouds output as critical [03:11] it's more a kin to a doc issue [03:12] along the same lines as the bootstrap help bug [03:13] is master currently blocked? [03:13] * thumper wants to merge some useful changes [03:14] particularly refactored code I'm using in migrations [03:14] to avoid extra conflicts [03:19] can people please stop changing code? [03:20] that'd be swell [03:20] heh [03:20] I think my manager would get mad ;) [03:20] master is not blocked btw [03:21] wallyworld: StopMongoUntilVersion [03:21] wallyworld: what can you tell me about it? [03:22] it's part of the mongo 2-> 3 migration implementation [03:22] hmm... [03:22] which will have happened by 2.0? [03:22] or not? [03:22] why do we need a worker? [03:22] yes, we are waiting on the deb packaging [03:23] can't we just say "2.0 needs mongo 3.0" [03:23] that's what we are doing [03:23] um... [03:23] but mongo is not packaged and in the archives [03:23] then why encode into state? [03:23] I'm just unclear as to the process [03:23] hangout? [03:23] sure [03:23] wallyworld: 1:1 === ashipika1 is now known as ashipika [08:24] * thumper waits patiently for the local test run to complete before submitting for real muerge [08:36] dimitern, dooferlad: http://reviews.vapour.ws/r/3942/ - choosing to merge blessed builds atm. [08:39] frobware, LGTM, thanks [09:34] fwereade: ping about a config location [09:36] specifically, the LXD provider has always used $HOME/.config/lxc/$NAMESPACE as the directory that holds the information we need for talking to the LXD daemon [09:36] however, our test suite seems to now be appropriately sanitizing $HOME [09:36] which means the lxdclient code is trying to create /.config/lxc/blah [09:37] and that is (correctly) failing [09:37] (note that in the actual providers once you bootstrap, the Juju machine agent was also always using /.config/... because $HOME wasn't set for the Juju agent) [09:38] I'd like to move those files to somewhere more appropriate, and just wanted to run it past you [09:49] jam, I agree they should not be there :) [09:50] fwereade: so far as I can tell none of our other Providers/Brokers need to write something to disk [09:50] so I don't have a lot to reference for where to get the information from and where to save it. [09:51] jam, nor do I really... an agent's datadir feels like the closest equivalent of $HOME? [09:54] fwereade: so there are 2 aspects. 1 is for the "local" LXD provider which is a provider all by itself [09:54] and the other is for the agents that then create LXD containers [10:03] dimitern: standup [12:54] Bug #1548799 opened: bootstrap from windows fails with no such file

[13:30] Bug #1548809 opened: cmd/juju/action: FetchSuite.TestRun takes 18s to run

[13:58] so, juju2.0 doesn't set $JUJU_HOME ? [14:02] voidspace: MAAS ho? [14:03] morning all [14:03] evilnickveitch: I believe JUJU_HOME is called something different in 2.0 [14:04] evilnickveitch: to enable using it side by side w/ 1.25 [14:04] natefinch makes sense, but I can't find what it is :) [14:05] I can't find any JUJU* [14:05] evilnickveitch: JUJU_DATA [14:06] frobware: oops, omw [14:06] evilnickveitch: https://github.com/juju/juju/blob/master/juju/osenv/vars.go#L21 [14:07] natefinch thanks! I will take your word for it. Currently running beta1 and it hasn't set any of those [14:08] evilnickveitch: it is called JUJU_DATA and it is by default $XDG_DATA_HOME/juju or ~/.local/share/juju if XDG_DATA_HOME is not defined [14:08] evilnickveitch: what do you mean by it hasn't set them? These are what a user would set to control where juju stores its data [14:08] evilnickveitch: juju does not Set those [14:08] evilnickveitch: juju uses them if set [14:09] anyhow if neither of thise is set the path is ~/.local/share/juju [14:12] perrito666, natefinch thanks, I will update the reference pages. I didn't think Juju had picked up my setting but i think it was a typo on my part [14:46] anyone know if there's a plan to remove the "unstable" from the charm.v6 repo? [14:46] natefinch: only once the new publish process is signed off and as part of 2.0 changes that require updates like resources work [14:47] natefinch: so "yes, there's a plan" but it's "not yet" [14:47] rick_h_: kk [15:09] frobware: ping? [15:11] natefinch: can you do a quick review for https://github.com/juju/juju/pull/4508 ? It's backporting your proxy fix [15:12] cherylj: no problem [15:12] cherylj: pong [15:13] frobware: hey, just wanted to check on what you guys are working on in the maas-spaces2 branch, and what milestone / release you were targeting [15:14] cherylj: have you run the tests locally? I'm worried bumping the utls revision might have unintended side effects. I mean, certainly we can let CI do the lifting, just curious [15:14] natefinch: yeah, I forked utils off for 1.25 so it didn't pull in the massive amount of changes that have gone in there since 1.25 [15:15] natefinch: and just applied your proxy change to it [15:15] cherylj: want to sync quickly? I have 15 mins [15:15] cherylj: ahh, ok. [15:16] frobware: yes - https://plus.google.com/hangouts/_/canonical.com/cheryl-andy?authuser=0 [15:17] cherylj: in an ideal world we should really make that a separate import path, so there's no confusion, but I understand that's significantly more work than just letting godeps cheat for us. [15:18] cherylj: anyway, LGTM [15:19] thanks, natefinch! [15:34] frobware, ping [15:34] sorry alexisb, I was keeping him [15:34] ah nws, no rush [15:35] * natefinch imagines cherylj with frobware in a curio cabinet. [15:37] natefinch: MRW I had to let him go: http://goo.gl/blhJiO [15:37] cherylj: lol [15:37] I had to set it to wumbo [16:05] good lord someone really needs to write a stringdiff checker for gocheck [16:05] like, don't just tell me these two huge strings are different, show me where [16:06] natefinch: that and pprint for things [16:07] perrito666: yeah, I'd kill for a nicely indented %#v [16:07] perrito666: I think I remember there's a third party package out there that does it [16:09] perrito666: https://godoc.org/github.com/kr/pretty [16:11] there's a few others, but that one seems most like what I would want as output [16:11] there's go-spew as well, but it has ugly output IMO [16:11] https://github.com/davecgh/go-spew [16:27] natefinch: ericsnow: could use a +1 on http://reviews.vapour.ws/r/3916/ [16:28] katco`: I'll take a look [16:28] natefinch: ty... very short review [16:30] katco`: ship it [16:31] natefinch: ty [16:31] ericsnow: are you with us today? :) [16:31] katco`: yep, sorry, missed your message [16:31] ericsnow: no worries, just hadn't seen you yet [16:32] ericsnow: i said good morning, but then my bouncer booted me right away, so don't know if anyone responded [16:32] the perils of no morning standup [16:33] katco`: I think your good morning got swallowed by the internet [16:33] booo internet [16:33] what has it ever done for us [16:33] lol [16:33] smoke signals should be good enough for anyone [16:33] internet: she didn't mean it [16:34] * ericsnow hopes we haven't angered it [16:35] * katco` has quit (Connection timeout and also she smells, ~<3 Internet) [16:35] lol [16:35] katco`, ericsnow: I may have overestimated the time to complete this card: http://reviews.vapour.ws/r/3945/ [16:35] katco`: I could use a quick re-review on both my patches [16:36] natefinch: rock! [16:36] natefinch: could you look over my responses to your comments on http://reviews.vapour.ws/r/3891/? [16:36] natefinch: nice [16:36] ericsnow: sure thing. [16:36] natefinch: ericsnow: i'll be getting to reviews here in a sec. wrapping up my PR for my card [16:36] natefinch: ta [16:36] katco`: np [16:37] actually, I'm on-call reviewer today, so I should spend some time on that anyway [16:49] ericsnow: natefinch: furnace guy is here... will be in and out [16:50] katco`: k [16:50] katco`: good luck [17:07] everything suddenly went almost night dark, so if you dont see me respond is because power went away [17:14] https://pbs.twimg.com/media/Cb6jfLLWEAA_t7O.jpg:large https://pbs.twimg.com/media/Cb6f_tnW4AQySJd.jpg:large <-- 2 PM on summer [17:14] yikes [17:15] katco`, ericsnow: I'll need another card after I do some reviews. What about the extension validating one? [17:16] natefinch: what about the overhead card in the iteration backlog? [17:16] natefinch: i'd rather you pick up the other critical user story [17:18] ericsnow: good point, I was glazing over anything that wasn't a user story. katco`, what do you think? That one will fix multiple fairly ugly bugs. [17:19] natefinch: that's fine too... need to know how long it's going to take [17:20] natefinch: FYI, I've reviewed your patch [17:20] katco`: lemme go investigate for a few, IIRC it was a little annoying to get the left hand to talk to the right hand [17:20] ericsnow: thanks [17:22] ericsnow: good point about using FormattedCharmResource! [17:22] (resuing) [17:23] reusing... feg [17:23] natefinch: np [17:23] feh [17:23] stupid fingers. [17:28] katco`: should be doable by tomorrow afternoon [17:28] katco`: hopefully earlier, but I'm inclined to be conservative at this point. [17:30] natefinch: good deal... flag the card if you don't mind [17:32] they probably have to replace my entire furnace T.T [17:32] right before we move [17:33] not cool, internet. not cool. [17:35] katco`: renting house? [17:35] perrito666: no, we're relocating [17:36] so you have to fix the furnance for the new home? [17:36] no the home we're going to be selling very soon [17:37] ah, it seems its easier to sell it like it is and just make a discount :p [17:37] although I am not entirely sure to what does furnance translate to [17:37] perrito666: that's not really an option since it's not working at all [17:39] perrito666: furnace == heat [17:39] ah yes, sorry [17:39] it's what heats the house [17:39] just googled and I got an idea [17:39] perrito666: no one's going to buy a house without any heat :) [17:39] Ill assume it is not a 300 dollars to replace it as it is here [17:40] perrito666: they just quoted me $2k [17:40] perrito666: depends on what you get, but often like $2500-5000 [17:40] ouch :p [17:40] katco`: that blows, sorry. [17:40] mine just heats wather for the floor heating system, but it was cheap :) [17:43] this is my street after a few mins of rain http://i.imgur.com/CgSlkF3.jpg [17:52] Bug #1548921 opened: credentials.yaml file should have a stub

[18:29] natefinch - i think if oudn the culprit [18:29] natefinch - do you recall yesterday how i was having hashsum mismatches delivering the charm from mc => unit? [18:30] this appears linked to when i use juju upgrade-charm --force-units, with a couple of them deployed... i dont know if the hashes are getting out of sync between what the state server thinks should be there or what, but it doesn't barf if i dont upgrade-charm --force-units in the model. [18:35] lazyPower: interesting [18:35] natefinch aside from anecdotal evidence, what could i gather to reproduce and file a bug? [18:36] lazyPower: can you repro with a simple case? [18:37] Will work on it and get that + bug# at you then. [18:37] cheers :) [18:37] lazyPower: cool, thanks [18:39] rick_h_: the spec for showing updates available on resources when running juju resources... should those be shown for all modes of juju resources, or just the generic juju resources servicename? i.e. should it be shown for juju resources unitName or juju resources servicename --details? [18:47] natefinch: i think like juju status for all commands. i don't want havevto write a bash for loop to check for updates available across my model. [18:47] natefinch: thoughts? [18:48] rick_h_: what I mean is, I already have it coded so that juju resources wordpress will show you warnings for any out-of-date resources for the service. but my question would be, should we show the same warning if you do juju resources wordpress/0 or juju resources wordpress --details? [18:49] rick_h_: I don't think it's appropriate when you're just viewing a single unit... but not sure about when you're viewing the detailed output for a service.... probably [18:49] Bug #1548938 opened: list-credentials doesn't include 'discovered' creds

[18:50] rick_h_: we don't currently support just running "juju resources" without the service name [18:50] rick_h_: (because it's not in the spec ;) [18:51] natefinch: ok, taking that one at a time. I definitely think that --details should show since it's about getting into the thorough details [18:51] agreed [18:51] natefinch: agree that on a unit, only showing it's current revivsion vs expected revision makes sense [18:51] natefinch: since you're not scoped to the "service as a whole" which an upgraded resource represents [18:51] exactly [18:52] natefinch: and /me loads spec to see what we have/don't for "juju resources" as a lone command [18:53] I wouldn't be totally against it, though honestly, most commands run over the entire model lose usefulness once you have a realistically sized model [18:53] though if you only showed out of date resources for the entire model, that could be quite usefukl [18:54] natefinch: well,it seems you'd be able to show your network map, storage pools created, etc. [18:54] natefinch: but you're right, that never came up in the spec... [18:54] rick_h_: sure, sure [18:54] natefinch: well any kind of audit function/debugging details would want a 'wtf is running' [18:54] natefinch: so current resources that have been 'resource-get' and their revisions, along with any upgrades available seems useful [18:55] natefinch: because if you go to file a bug, knowing which ones are there are important to duplicating. And without having to script a for loop for each service [18:55] yep [18:55] * rick_h_ hangs head in shame that he missed this in the spec so far [18:56] rick_h_: we missed the existence of juju deploy --resource... I think you're in good company ;) [18:56] the only perfect spec is the code itself [18:57] natefinch: ok, so you have what you need for the moment? [18:57] rick_h_: yes... we'll just do it for the service and service with --details [18:57] natefinch: k, ty for the ping [18:57] rick_h_: and I leave it with you to arm wrestle katco` about listing resources across the model [18:57] natefinch: heh, /me runs to protective tank [18:58] natefinch: the good news is that it's not bad since Juju is just looping on myhalf? /me hopes :) [18:59] rick_h_: not the end of the world, but a few days' work, certainly [19:14] rick_h_: one more thing I thought of.... once you override a store resource by uploading a local resource with push-resource, I presume we won't upgrade that resource when you do a charm-upgrade, correct? [19:15] natefinch: I think that's true. The key there will be indicating that to the user somehow. [19:15] natefinch: though...if you upgrade-charm... [19:15] natefinch: thinking [19:15] rick_h_: it seems logical to me to pin it... but then we have no way to un-oin it currently [19:15] un-pin that is [19:15] natefinch: so since the only way to upgrade that is with upgrade-charm, and that is an explicit call to "get me the latest from the charmstore" [19:16] (assuming it's not upgrade-charm ./localpath) [19:16] natefinch: I don't think we pin, I think it's just doing what the user asks [19:17] rick_h_: so the problem is, I'm using a charm that has stub-resources in the charmstore... the charm code gets updated, and there are some minor tweaks to the stub resources, so they get updated too... charm-upgrade will now throw away my real resources and replace them with the stubs in the store [19:17] natefinch: so but we don't tell 'stub' from 'non-stub' [19:17] natefinch: you might need that resource for a bugfix and want to get back on 'stable' footing [19:18] natefinch: I think the trick there is upgrade-charm supporting something...either manually specified resources or something that says "charm w/o new resources"? but then maybe you want one/not all [19:18] natefinch: so ugh? [19:18] rick_h_: ug is right [19:18] rick_h_: I definitely think there will be times when users want one or the other behavior [19:19] natefinch: I'm getting tempted to suggest a --without-new-resources flag to upgrade-charm [19:19] rick_h_: I was thinking it might be useful to have a command to revert an uploaded resource to the store-version [19:19] * rick_h_ isn't sure on that one [19:21] natefinch: hmm, actually I think this fits into the stuff I'm writing for the juju resources command. [19:21] rick_h_: I was just thinking that splitting it into two commands might give the most flexibility to the user. have upgrade-charm keep uploaded resources as they are, but if someone wants to stop using an uploaded resource, they can juju unpush-resource (hopefully with a better name) [19:22] natefinch: well, the idea would be you could push a resource with a charmstore url. [19:22] natefinch: that indicates your interest in following the CS blessed paths perhaps [19:22] rick_h_: ooooh, I like that [19:23] natefinch: though it might not be techincally blessed based on the revision you have...thinking more [19:23] rick_h_: I like that it's explicit about what exactly you'll get [19:23] natefinch: right [19:23] I think that falls under the normal charmstore rules of you can leave off the revision, it grabs the latest blessed revision [19:23] and you'd track the charmstore from there on [19:23] and if you provide a local file, you'd ignore the charmstore updates from then on, until you went back to a push-resource cs:xxxxx [19:24] yeah, I think that's what I would expect... if juju threw out the thing I uploaded and explicitly told it to use, I'd get mad [19:24] hmm, this is working ok in my head at least [19:24] yea...and if I deploy a service with local files, even if I upgrade the charm I've indicated I'm manually handling resources [19:24] yep [19:25] ok, this falls into the lovely "handling upgrades" section. [19:25] might be worth having a flag on upgrade-charm that forces the use of the store resources... otherwise it might be impossible to upgrade, if the new resources and old resources are incompatible [19:26] natefinch: how so? [19:26] natefinch: if you have a new charm, and it wants different resources, it'll error and then you'll have to provide them, rerun hooks, and get from error to normal? [19:27] natefinch: and there's an upgrade-charm flag with the --resources option [19:27] natefinch: so you could do it in one swoop? [19:28] rick_h_: anything involving rerunning the hooks is bad. But yes, --resources could work if you can specify charmstore urls. [19:28] natefinch: right [19:30] except uh..... I think we missed upgrade-charm --resources. AFAIK we don't have cards for that... ericsnow, katco` ... I think this is work we're missing [19:34] natefinch, rick_h: correct me if I'm wrong, but "juju upgrade-charm --resources" is new to the spec [19:34] ericsnow: well it was a "case" in the upgrade cases that was blank [19:34] ericsnow: those weren't all filled out and natefinch has been asking about those cases right now [19:34] ericsnow: so... sort of :) [19:35] rick_h_: I was looking for a "upgrade-charm --resources" in the spec yesterday but did not find one [19:35] rick_h_: ah [19:35] ericsnow: right, it was "Upgrade charm and use supplied resource at upgrade time" without a command in the following bullet point [19:35] ericsnow: the actually CLI command was just added, but there was a bullet point labelled "Upgrade charm and use supplied resource at upgrade time" under upgrades [19:35] rick_h_: i apologize, i'm having to buy a new furnace so i'm not able to give this my full attention. can the new bullets under "handling upgrades" be pushed to a v2? [19:35] ericsnow: and I think that logically fits into place there. [19:36] katco`: understand, let's sync on it when you're free. I've given natefinch what he needs to unblock him for the moment and we'll go through the updates and see what can be bumped. [19:36] katco`: take care of getting fire first, handy this time of year [19:38] rick_h_: you're not kidding. we are getting pretty creative here with space heaters =| [19:40] I dont understand, its pretty warm this time of the year, after a decent rain temp got down to 25C [19:40] :p [19:40] lol [19:40] we don't all live in the jungle, perrito666 [19:40] perrito666: you shut your souther-hemisphere mouth! [19:40] * perrito666 closes his mouth, around a straw, and zips a fruit juice [19:41] perrito666: rofl [19:41] * katco` enjoys the phone transfer tolken ring she seems to be on [19:41] katco`: you are on the infinite call center loop? [19:46] katco`: do you mind if I land my 2 patches; natefinch has given ship-its and I've addressed all the open issues [19:46] ericsnow: please go for it. [19:46] * katco` is frustrated [19:47] ericsnow: I have one concern I just found [19:47] i can't think of many worse times for this to happen (grumble) [19:47] katco`: I left a few open to point out where we might discuss it a bit more, but I feel comfortable with where things are at [19:47] ericsnow: I was looking at the updates function [19:47] natefinch: uh oh [19:48] natefinch, katco`: FYI, I have a patch up for moving resources persistence to the state package [19:48] ericsnow: I don't liek that it assumes the two lists are the same length and in the same order. I'd rather explicitly check the resource names [19:48] natefinch: that's fine; I did make it clear in the doc comment that they are one-to-one [19:49] ericsnow: yeah, but that guarantee is really really really far removed from that code [19:49] natefinch: I'll fix it up [19:50] ericsnow: thanks... sorry, the only reason I noticed was because I copied your code for doing my testing, and had weird behavior because my lists were out of order [19:50] natefinch: sounds like a personal problem [19:50] ericsnow: lol [19:57] ericsnow: thanks for the move, doing payloads too? [19:57] thumper: wasn't planning on it [19:58] thumper: I wouldn't mind but you'll have to win over katco` (and you shouldn't mess with her today!) [19:58] * thumper keeps his distance [19:58] thumper: (we're still scrambling with resources) [19:59] thumper: :) we'll do it happily if we can get out ahead on resources [19:59] thumper: (and katco` is dealing with a bad furnace) [20:00] thumper: FWIW, moving payloads should look just like the patch for resources [20:02] ericsnow: um... have you seen the size of that? [20:02] 47 changed files with 2,110 additions and 546 deletions. [20:02] ericsnow: I'm pretty sure you aren't taking across what you think you are [20:02] thumper: that's because it's based on other branches; in RB you'll see it is ~ +200, -200 [20:06] rick_h_: the spec calls the section for updates "[Updates available]" (note the lowercase a in available). Should that be a capital a for Available?" [20:07] natefinch: no, it's only the first word caps. /me tries to remember the email/notes from jam on that [20:08] rick_h_: boo [20:08] rick_h_: natefinch: i think we can do second word caps too [20:08] rick_h_: natefinch: i think the real contention was b/t all caps and camel-case of sorts [20:08] katco`: natefinch yea, foudn the email [20:08] that's the rule [20:08] title case [20:09] rick_h_: title case, there we go [20:09] natefinch: katco` so title case should be Updates Available [20:09] huzzah [20:09] my bad [20:09] :P [20:43] ericsnow: natefinch: being on hold has it's advantages: http://reviews.vapour.ws/r/3948/ [20:43] katco`: nice [20:44] katco`: lol [20:50] ericsnow, katco`: gah, we need to implement FingerPrint.Equal :/ [20:51] ericsnow, katco`: that's the second place we'll be writing a custom comparison func [20:51] natefinch: IIRC, I did in my original proposed patch and you shot it down :) [20:53] ericsnow: who, me? Saying we shouldn't implement things before we need them? Doesn't sound like me ;) [20:53] ha [20:54] ericsnow: for that one though, if I did say that, I was definitely wrong. That was pretty inevitable that we'd need it... and it's outside juju/juju, so it's annoying to add later. [20:54] natefinch: yep [20:58] I'm able to successfully issue a 'juju bootstrap' on my openstack private cloud, but when the new instance starts up the service it returns: "index file has no data for cloud" Any ideas? [21:00] doesn't sound familiar [21:00] thumper: ^ [21:08] Bug #1548938 changed: list-credentials doesn't include 'discovered' creds

[21:08] ericsnow: fixed up my pr for updates available, adding support for doing it during --details as well. please re-review. I wrote my own updates function, but I'll wait until your code is in and overwrite mine with yours. [21:08] ericsnow: http://reviews.vapour.ws/r/3945/ [21:08] natefinch: it's merging now, BTW [21:08] ericsnow: cool, I'll rebase once it's in. [21:14] Bug #1548938 opened: list-credentials doesn't include 'discovered' creds

[21:17] Bug #1548938 changed: list-credentials doesn't include 'discovered' creds

[21:20] Bug #1548938 opened: list-credentials doesn't include 'discovered' creds

[21:29] Bug #1548938 changed: list-credentials doesn't include 'discovered' creds

[21:30] ericsnow: here's my approach for returning unitresources for all units, would like your thoughts before I get too far into it: http://reviews.vapour.ws/r/3949/diff/# [21:30] (though obv standup now) [22:55] if anyone has a minute to riff on this - https://github.com/juju/charm-tools/issues/91 - is there any explicit reason underscores are not accepted in action parameters/names? === philipballew is now known as Guest44851 [23:13] lazyPower: IIRC it's simply because that wasn't one of the characters allowed. The 'allowed' characters were a pretty small subset in bodie's initial implementation. [23:22] cool, thanks jw4 [23:23]