[00:19] thumper: yes, that was a mistake [00:19] that line doesn't do anything [00:20] but commenting it out was a mistake [00:20] i will revert that part from the PR [00:20] and add some more test coverage to exercise that line [00:24] davecheney: I'm concerned [00:24] how do I pull your branch locally? [00:25] davecheney: do you know what causes the empty caller stack item between the test function and the code? [00:25] davecheney: I'm wondering if when called in real life, we don't get that [00:26] davecheney: in particular, the errgo.New method in the global var block gets the wrong location [00:26] davecheney: as it doesn't have a blank caller entry [00:26] davecheney: also, when called from juju/errors we get the correct stack [00:26] but if this change goes in, they will be wrong [00:26] thumper: toss some notes/feedback in your doc. I can't edit or I'd spell out some of the use cases/etc. Let me know if any of it seems crazy. [00:27] thumper: go to the PR, there is link to the instructions on how to checkout my branch [00:27] thumper: the final error remaining to be fixed ? [00:27] davecheney: I'll look again [00:27] i don't know the cause at the moent, if I did, I would have fixed it :) [00:28] davecheney: the pull request doesn't tell me how to get it locally [00:28] or at least not in any way obvious I can see [00:28] rick_h_: kk, ta [00:31] davecheney: do you know how I can get your branch locally? I'm stumped [00:32] thumper: https://github.com/juju/errgo/pull/2 [00:32] ^ click You can also merge branches on the command line. [00:32] do step 1 [00:32] don't do step 2 [00:33] ahh... [00:33] ta [00:34] thumper: welcome to the monoculture [00:34] davecheney: as expected, with the change to errgo, all of the stack tests in juju/errors now fail [00:36] * thumper has to go do daughter's lunch now [00:43] shit [00:43] * davecheney has a horrible feeling this may not be fixable i the general case [00:44] hi wallyworld_ https://bugs.launchpad.net/juju-core/+bug/1319822 appeared with your branch to change lxc [00:44] <_mup_> Bug #1319822: lxc unit tests broken for trusty

[00:45] sinzui: yeah, it's on my todo list today. sad that it passed the bot but breaks on CI [00:45] wallyworld_, can you review what went wrong? [00:45] yeah, just finishing another branch first [00:45] wallyworld_, It might be CI. I am willing to accept the bame [00:45] more likely my fault [00:46] i also gotta look to see if precise containers on trusty host has broken again [00:49] wallyworld_, I now have aws, canonistack, and lexington under by control. http://juju-ci.vapour.ws:8080/ [00:49] great [00:49] but alas, I forgot the test I wanted to play needs a built package, and CI doesn't know how to do that ppc64 and arm64 [00:50] i like all the blue dots [01:05] * menn0 is being inducted^Wbrainwashed [01:39] davecheney: https://github.com/juju/errgo/pull/3 [01:41] * davecheney looks [01:42] thumper: if it passed under gc [01:42] check it in [01:42] it did [01:42] cool [01:42] and it passes with gccgo [01:42] fwiw [01:42] thumper: so here is my concern [01:42] runtime.Callers is basically different between gc and gccgo [01:43] normally you can work around it by adjusting the offset of the initial runtime.Callers [01:43] for many values yes [01:43] but if we stack these things, and there are embedded strcuts involved [01:43] i am not sure it will work for all possible variation [01:43] variations [01:43] however I *think* that the one causing a problem is just for tests [01:43] yes [01:43] and the effect on real code is you may see an odd line in the stack trace that either has no source line [01:43] so perhaps we patch the initial level only for gccgo and just for the tests? [01:44] and it seems to be just the test methods themselves [01:44] oh... [01:44] I have a plan [01:44] axw: hiya, standup? [01:44] the &embed{err} one is the complete fucker [01:44] davecheney: let me try something [01:44] thumper: hold up, i'll update my PR [01:44] davecheney: I'd like some approval on that test addition PR [01:44] davecheney: so it looks like I'm getting other feedback :) [01:45] thumper: i can drop it from the PR [01:45] is there a git command to branch and checkout? [01:45] keep things simple [01:45] thumper: you're asking the wrong man [01:45] i use [01:45] git checkout -b NAME [01:45] which branchs and switchs to NAME [01:45] wallyworld_: hey, yep [01:45] that what I want [01:46] excellent, grammar good [01:47] davecheney: ya know... [01:47] davecheney: I bet if we changed errgo to use gocheck, this would work [01:50] davecheney: so... TestNew failes but TestNewf succeeds [01:50] with gccgo [01:51] https://github.com/juju/errgo/pull/2 [01:51] updated [01:51] now with less contraversy [01:58] --- FAIL: TestNoteUsage (0.00 seconds) [01:58] errors_test.go:250: unexpected details: want "[{/home/dfc/src/github.com/juju/errgo/errorstest.go:38: annotate2} {/home/dfc/src/github.com/juju/errgo/errors_test.go:32: annotate1} {/home/dfc/src/github.com/juju/errgo/errors_test.go:29: some error}]"; got "[{/home/dfc/src/github.com/juju/errgo/errors_test.go:43: annotate2} {/home/dfc/src/github.com/juju/errgoj/errors_test.go:37: annotate1} {/tmp/go-build412244215/github.com/juju/errgo/_t [01:58] yup, that test fails on my branch with those adjustments [01:58] * davecheney goes back to hunting wumpus' [01:59] davecheney: I'm pretty confused as to why TestNew fails but TestNewf succeeds [02:00] same [02:00] it calls the same damn methods [02:00] yeah [02:00] fyi, % go test && go test -compiler=gccgo [02:00] who do we know on gccgo that we can throw this at? [02:00] * davecheney raises hands [02:00] seriusly, it might be me [02:00] handy to do that in one command [02:00] heh [02:00] we did log a bug about this with the upstream [02:01] we == michael and me last year [02:01] * davecheney searches [02:01] I think a key point would be to focus on that one use case [02:01] TestNew vs TestNewf [02:01] if we can work that out [02:01] the rest should be simple [02:01] I'm goint to write other emails... [02:01] roger [02:01] you're trained for that now [02:01] with your ceritificate [02:02] heh [02:03] mwhudson: you around? [02:04] mwhudson: have you been poking gccgo too? [02:04] thumper: https://code.google.com/p/go/issues/detail?id=6835 [02:04] thumper: not recently [02:04] but i am here [02:04] davecheney: yeah, read that one, and that is how I fixed the juju/errors work [02:04] thumper: bingo [02:04] * thumper jumps on a different hangout [02:10] is juju-core/errors being moved out of the tree? [02:13] stokachu: it has been [02:13] yes [02:13] stokachu: to github.com/juju/errors [02:13] thumper: ah ok, go get was giving me errors [02:13] no pun intended? [02:13] so i should be doing go get github.com/juju now? [02:17] doesn't look like the core bits are on github -- is this a migration in progress i take it? [02:18] stokachu: go get -u launchpad.net/juju-core/... will always pull in the correct dependencies [02:18] you should run godeps -u dependencies.tsv afterwards to set all the repos to their correct revisions [02:18] so go get -u fails to find launchpad.net/juju-core/errors [02:18] ran that a few minutes ago [02:18] that ios correct [02:18] that has been removed [02:19] ah lemme re-run then could be fast on the draw [02:19] i should probably stop messing with juju-core so late at night :X [02:26] davecheney: haha, guess what? === revagomes is now known as mGraf [02:26] davecheney: I have a branch that uses gocheck, and all the tests pass with both compilers === mGraf is now known as revagomes [02:28] davecheney: https://github.com/juju/errgo/pull/4 [02:29] i cannot explain that [02:30] and it terrifies me === revagomes is now known as mGraf [02:30] this is the difference between being called from a function or called from a method [02:30] which under the hood are EXACTLY THE SAME! === mGraf is now known as revagomes [02:30] methods on types are just like static methods on C classes [02:30] there is no virtual dispact [02:31] dispatch [02:31] mwhudson: which compiler do we use for juju on armhf and armel? [02:31] davecheney: I know... [02:31] thumper: gc [02:31] i think [02:31] davecheney: something screwy is happening [02:31] thumper: there is no supprt on armel [02:31] thumper: we don't do anything for armel any more do we? [02:31] that is harm without a floating point unit [02:31] kk [02:31] armhf, we use gc [02:31] cheers [02:31] but gccgo is also known to work on linux [02:32] thumper: but not juju/errors does not pass === revagomes is now known as mGraf [02:33] huh? === mGraf is now known as revagomes [02:33] davecheney: pass here === revagomes is now known as xauz [02:34] hmm, ok === xauz is now known as revagomes [02:34] * davecheney deletes things [02:35] davecheney: as expected, I bet that the core testing library is doing weird things, perhaps calling functions using reflect which may well be adding synthetic methods through gccgo [02:35] with gocheck, those synthetic methods are so far up the stack we don't care [02:39] thumper: yes it does [02:39] the wya testing works is it builds a list of functions by name at compile time, then uses reflect to find those functions at run time an execute them [02:40] ok, i call lunch [02:45] wallyworld_: if I run TestInitiateReplicaSet in a loop inside the testing framework (i.e. no per-test SetUp/TearDown), I can reliably get it to fail on the bot - but not on my laptop [02:46] seems the bot is actually faster than may laptop [02:46] axw: lol [02:46] hmmm [02:46] at least it fails [02:47] thumper: [0] for some implementations of great [02:53] right, now I really am going for lunch [03:06] wallyworld_: would you be able to have a look at this: https://codereview.appspot.com/87130045 [03:06] fwereade has reviewed. Basically, he is happy if you're happy [03:06] wallyworld_: I have to do school run now, so no rush [03:06] ok [03:06] cya :) [03:06] l8tr [03:28] axw: i have a fix for the trusty tests on CI https://codereview.appspot.com/99330043 [03:31] looking [03:33] thank you [03:50] Do I have to worry about compatibility if I'm adding fields to the machine and unit status API responses? [03:51] hmm... [03:51] as long as the deserialization code can handle that they are missing [03:51] you *should* be ok [03:52] we know that during upgrades, the api server should be done first [03:52] so an agent should never be a higher version than that api server [03:52] understood. [03:52] however, the agent might not be as up to date as the server [03:55] I think I'll be ok as my change only affects the API server. it's exposing information that is already being reported but just wasn't available in the status response. [03:55] i'll check the api server / client mismatch issue to make sure there isn't a deserialization issue [03:56] as an aside: jam is working on versioning for the API isn't he? [04:05] menn0: just emailed you leankit stuff [04:05] just saw it thanks [04:10] "After logging in for the first time, you will have to option to change this temporary password." [04:10] or not... :( [04:11] menn0: have you found out where to change it yet? [04:12] iirc it isn't entirely obvious [04:12] thumper: no. the UI mentioned in the help isn't there for me. I'm hovering over the Leankit logo in the top right and changing my password isn't available on the menu that appears. [04:12] wallyworld_: puttiing replSetInitiate in a retry loop does the trick [04:13] menn0: priv msg :) [04:13] axw: great, a bit hacky but it will server the purpose for now i reckon [04:41] wallyworld_: want me to look at the i386 tests? [04:45] axw: yeah, that's the next highest priority, thanks [04:45] it might turn into a "fix tools handling" exercise [04:46] * axw nods === vladk|offline is now known as vladk === vladk is now known as vladk|offline [06:54] axw: thanks for the review [06:56] davecheney: nps [06:56] always glad to be rid of another panic("unreachable") [06:56] axw: i'm off to soccer, so have a good weekend. i'm part way through replacing LoggingSuite with BaseSuite and rewriting tests to avoid outgoing http. [06:57] wallyworld__: later, you too. I'm scratching my head at i386 test failures :) [06:57] does seem like we should consider pluggin in basesuite when the suite is registered [06:58] yeah, i didn't look too closely at the i386 faiures, looke dtools related [06:58] axw: can you clarify if we need to support 1.0 style unreachable stuff ? [06:58] I was under the understanding that we [06:58] a. did have to support precise [06:58] b. the version of Go in precise was not capable of compiling Juju [06:58] tf. our minimum is actually 1.1 [06:59] davecheney: yeah our minimum is 1.1 (we use 1.1.2 on the bot) [06:59] axw: right, in that case there are some more warnings I can address [06:59] bueno [06:59] multo gusti! [07:00] and yes we need to support precise. there was talk about moving to 1.2 (and may still), but precise only has 1.1.2 in the ppa right now [07:00] given that precise is built from a dependant ppa [07:00] and we have to support two compilers anyway [07:01] i vote for not shooting ourselves in the foot and having to support two versions of one compiler [07:01] that is, Go 1.2 across the board [07:01] both as the upper and lower bound [07:01] I would prefer that [07:01] * davecheney will propose [07:08] done [07:15] omg, goose bot merges things SO FAST [07:52] morning all [07:58] wallyworld__, ping === ev_ is now known as ev [08:44] waigani, LGTM, just trivials === vladk|offline is now known as vladk [10:14] fwereade: my thoughts exactly: "LGTM. The yuck of the reflection is more than balanced by the squee of [10:14] the external interface." [10:14] thanks for the reviews [10:25] for gccgo should we be testing with the packaged version (apt-get gccgo) or building from source, or something else (building/using a specific version)? [10:25] voidspace: gccgo is packaged on Trusty [10:26] outside of Trusty, you'll probably need to roll your own (or push us to get something into a PPA) [10:26] ah, and in the next thread David says "gccgo-4.9" [10:26] I'm on trusty [10:26] jam: thanks [10:26] voidspace: yeah, the gccgo in trusty is good enough for working with. [10:26] It *is* being used in anger for the ppc64 ports. [10:26] and amd64 [10:27] fwereade: you wanted to be pinged about rsyslog-ca-cert in wwitzel3's branch - which is also my branch [10:27] jam: yeah, there's a thread that says we should be testing with it [10:28] fwereade: so we had a big discussion about this issue (is watching APIHostPorts alone sufficient or not)? [10:28] fwereade: and no-one wanted to commit to an answer, but the consensus seemed to be [10:29] fwereade: if we're treating the rsyslog config entries as "immutable once set" then watching APIHostPorts alone to trigger rsyslog config rewriting should be enough [10:29] fwereade: and it works for the scenarios we've manually tested [10:29] non-HA with unit deployed, HA without units, HA then units deployed, non-HA with units deployed then ensure-availability [10:29] rsyslog config is rewritten in all these cases and logging happens correctly [10:30] fwereade: so the only wrinkle would be if the rsyslog config can be written out *before* the certificate is set for the first time on bootstrap [10:30] fwereade: in which case it wouldn't be rewritten [10:30] fwereade: when we asked nobody thought that was likely, but no-one would *commit* to it being impossible [10:31] fwereade: however "they" (jam and natefinch) did think that if we're treating the rsyslog config as "immutable once set" then watching just APIHostPorts *should* be sufficient [10:31] so that's what we did [10:47] jam: hangout [10:48] vladk: I'm not actually "working" today [10:48] its my weekend [10:54] vladk: here [11:03] hello [11:03] wwitzel3: hey, hi [11:04] wwitzel3: there were some comments on the mp from fwereade [11:04] wwitzel3: I replied [11:04] wwitzel3: one thing we forgot - we made GetRsyslogConfig return HostPorts [11:04] wwitzel3: the reason for that is so that the templates can use host-port pairs rather than host plus global port [11:04] wwitzel3: but we didn't change the template rendering code to do that [11:05] wwitzel3: I've made a start on that (whilst also starting some more manual testing against canonistack and reading William's architecture doc) [11:05] wwitzel3: nothing to push yet [11:05] wwitzel3: we can probably lose the global port on the RsyslogConfigParams then [11:06] but you arrived (as always) just as I need coffee) [11:06] natefinch: morning [11:07] this is a lie [11:07] it is not morning for natefinch [11:07] davecheney: it's *always* morning on the internet [11:09] +1 [11:10] also, yes, it is morning :)( [11:10] morning davecheney :) [11:14] fwereade: hi, was at soccer, back now [11:14] wallyworld__, er, what did I want [11:14] wallyworld__, oh yes: are you doing git things? [11:14] yes, sorta [11:14] wallyworld__, ie landing bot change etc [11:14] wallyworld__, can I put the use-go-1.2 stuff on your plate then please? [11:15] i have a repo that i've migrated to github https://github.com/wallyworld/core [11:15] and i'm working with curtis to get the landing bot sorted out [11:15] sure [11:15] so we want the bot to use go 1.2? [11:16] fwereade: also, i'd like a meeting with you first thing your monday AM to talk about storage, would that be ok? [11:17] wallyworld__, sure [11:17] ok, just ping me when you're online [11:18] wallyworld__, will do [11:21] natefinch, myself and tasdomas are available to help with ha, let me know when would be a good time to grab your for a chat about it [11:29] mattyw: cool, let me bring up the docs [11:29] voidspace, wwitzel3: is anyone free to briefly educate me on rsyslog-ca-cert, where it came from, why it exists, etc? [11:30] voidspace, wwitzel3: I suspect it interacts with stuff cmars is doing at the moment but I don't really have a clear picture of how it all ends up interacting [11:31] voidspace, wwitzel3: in particular I'm +1 on separate certs for separate services, but less convinced that we need a different ca cert for rsyslog, unless we're thinking of setting up external rsyslog targets [11:31] voidspace, wwitzel3: and even then *we* wouldn't be generating server certs from it? [11:39] mattyw: sorry, my daughter detected I might get work done and woke up. It'll be an hour or so for my wife to wake up and be ready to take her, so probably don't wait for me for right now [11:40] natefinch, ok no problem, I'll take the time to sort my little on out as well :), just ping me when you're ready [11:41] mattyw: cool [11:49] fwereade: we already have these certs, so no I'm not able to educate you on why we have it :-) [11:49] I have to go on lunch [11:49] meeting a friend [11:49] but I'll be back soonish [11:49] voidspace, np, enjoy, I will go hunting [11:50] ta, see you all soon [12:28] * bodie_ pings fwereade -- going to slice that commit back down to what you'd mentioned and get it in this morning :) [12:32] bodie_, don't feel you have to, go ahead and propose as it is if you like -- you can slice bits out while I take a first look if you like [12:38] lunchtime [12:38] TheMue: I will not lunch at 9 am :p [12:50] on that note fwereade and jcw4 -- the interface{} option for gojsonschema is looking for a raw JSON string. I think it's appropriate to transform the unmarshaled YAML map into a JSON string to check whether it conforms to JSON-schema, but I'm not positive what the behavior will be like (whether it will, e.g., silently truncate nonconformant values from the map) [12:51] bodie_, huh, that's really bizarre, Iwonder why on earth they would do that [12:53] bodie_, https://github.com/xeipuuv/gojsonschema/blob/master/schemaDocument.go :66 seems to imply it can handle map[string]interface{} at least for schemaDocument [12:53] I could be misinterpreting something, but when I try to "smush" the unmarshaled YAML into the gojsonschema loader, it's saying it "must be a jsonReference string or Json as map[string]interface{}" [12:54] bodie_, if we *have* to go via json we could, I guess, but I think it's a last resort [12:54] bodie_, I think map[string]interface{} is nice for us all around though [12:54] I agree [12:54] I could be misinterpreting the error, too, or it could be happening for a different reason [12:54] bodie_, we could use the juju-core/schema package to coerce that stuff into map[string]interface{} on ingest [12:55] bodie_, I suspect it's because it's map[interface{}]interface{} until it's coerced? [12:55] * bodie_ ponders [12:57] it's probably a silly type issue [12:57] right now an Actions is just an alias for map[string]interface{} but perhaps it doesn't know how to unmarshal yaml into that alias [12:57] either way I need to really cut down the scope on this [12:58] if you'd like to have a look it's here -- https://code.launchpad.net/~binary132/juju-core/charm-actions [13:01] the problem code is here http://bazaar.launchpad.net/~binary132/juju-core/charm-actions/revision/2736 [13:02] actually, if anyone has input on that, it would be welcome. I suspect it's to do with unmarshaling to "actions" and attempting to do NewJsonSchemaDocument on "actions" which is of type ... Actions map[string]interface instead of directly on such a map [13:02] bodie_, "Actions" doesn't sound quite right for that type anyway [13:03] that's the type formerly known as ActionsSpec... lol [13:03] it's a charm's Actions [13:03] bodie_, giving whatever encloses it a "schema" field of type map[string]interface{} seems like a perfectly reasonable thing to unmarshal the yaml into, then you should be able to hand over to gojsonschema directly, I think [13:04] bodie_, I don't think the whole set of actions wants to be a schema, does it? [13:04] rather a .yaml for each action in the charm? [13:04] an* [13:05] bodie_, we want a map[name]ActionSpec or something, in which an ActionSpec has name, description, schema (or something roughlylike that anyway, I think) [13:05] bodie_, yeah, actions.yaml seems like a nice way to express it [13:05] well the idea was to define the loosest possible schema, but a sane charm would have its top level keys be the names of actions [13:06] bodie_, not sure, don't we want `actions: {...}` at the top level for forward compatibility? [13:06] bodie_, otherwise there's nowhere nice to tack on a version field if (when ;)) we need it [13:07] bodie_, (but yeah we don't want name explicitly I guess, that can come from the map keys, ofc) [13:07] presumed version would be for the entire charm? [13:08] if you change the actions, that ought to increment the charm version [13:08] bodie_, no, I mean the format of the actions.yaml file itself [13:08] bodie_, I have yet to see a v1 of a format that never needed to be changed ;p [13:08] hehe [13:08] bodie_, (given a year of two if usage anyway) [13:10] my assumption here was that our goal is to permit the charmer to define his actions spec however he pleases, as long as it's "some kind of" json-schema [13:10] I'm not grasping what you're envisioning [13:14] bodie_, well, we need stuff that juju can interpret -- the name comes from the map key, but we want a description; we'll need a field defining the target (service/unit) even if that's implicitly unit for now; probably we'll want something else at some point, eg is it valid to run it in an error state, etc etc [13:15] bodie_, then we need another field containing the jsonschema stuff that we use to validate the payload when the action actually gets queued/run [13:15] interesting [13:15] so almost like a schema with an args sub-schema [13:16] the top-level schema being the one WE perform checks against [13:17] bodie_, http://paste.ubuntu.com/7472971/ [13:17] bodie_, yeah, exactly [13:22] fwereade, to play Devil's advocate, it seems to me like we want to give charmers that ability as a "manual" mode as it were, where we assume defaults if the top-level keys don't match a set we check for [13:23] a more permissive spec could still enable the functionality you're describing while not enforcing a strict format [13:24] bodie_, well, we still need a reliable place to add our own fields, right? [13:24] bodie_, what are you envisioning? just a top-level dict of name to schema? [13:25] for actions.yaml or for Charm's Actions? [13:27] bodie_, what's the distinction between the two? actions.yaml is a serialisation format for a charm's actions definition [13:27] bodie_, but I guess I'm talking about actions.yaml [13:27] bodie_, I'm just not really considering a hard separation between the charm representation and the in-memory one [13:28] bodie_, they won't look exactly the same, that's what our reading code will handle [13:31] I see, what you were saying about having a sub-spec got me thinking that perhaps if there's no encapsulating spec in the user's actions.yaml, we have a default map in the memory representation, something like {actions: {spec: {...}, version: {...}, ...}} [13:31] i.e. if the user doesn't match our schema, we just dump his or her schema into the "spec" subkey of our actions dict [13:32] bodie_, I think we can ignore extra keys for forward compatibility's sake, but we really want to be storing it as a type [13:32] bodie_, type Actions struct { Actions map[string]Action } [13:33] bodie_, type Action struct { Name string; Description string; Schema map[string]interface{} } [13:33] bodie_, sort of thing [13:34] bodie_, am I making sense? would a hangout help? [13:34] it's a little crazy here right now, michelle just discovered we have a small ant infestation. I need to process for a minute... [13:35] bodie_: ouch, buy a ton of ant gel, that usually works charms [13:37] yeah, the gel works nicely because they take it back with them [13:39] we had awesome results at my old place with this chalk that kills them if they cross it [13:39] it's got to be a high-grade neurotoxin, I'm sure, probably wreaking havoc on my DNA [13:41] bet you there's a super easy way to do it [13:41] woops, wrong channel [13:42] bodie_: we're having an ant problem here, too, I can sympathize [13:42] let's see [13:42] I've heard there's basically one massive hive that extends from Mexico to Canada [13:42] haven't seen them like that back East [13:42] that was mortal combat.... [13:43] fwereade, you're making sense but I was under the impression we should be parsing and storing the info more as a schemaless blob [13:43] that perhaps the way we'd been doing it (parsing out a spec for each action) was too restrictive and we simply were to let the charmer define the schema according to his or her preference [13:44] so, I'm continuing to have a really hard time understanding which way is preferable (blob versus more detailed parsed map) [13:45] it's very challenging to make progress on this when I feel both ways are nixed in favor of the opposite... heh [13:45] bodie_: I had thought the blob was better, but I forgot about the GUI - we need to be able to support people setting values in there without having to type out json in a big text field [13:45] but I want to understand the reasoning and goals so I can move forward [13:45] yes -- which means that shouldn't the Charm's Actions map be a valid JSON-schema and perhaps not more? [13:46] bodie_, but we need metadata that juju can interpret cleanly [13:46] bodie_, and expose parts of it to the user [13:46] bodie_, users will need a rough description of what a given action will do [13:47] bodie_, and juju itself will need to know what the action's target is [13:47] I'm getting this tattooed on my arm.... ;) [13:48]