[02:58] davecheney: hi, if you had a few minutes, would you be able to take another look at my recent mp and hopefully +1 it. i've addressed the main issues and would like to land it to unblock things for others https://codereview.appspot.com/6782112/ [06:32] wallyworld_: sorry I missed you [06:33] no problem [06:33] my wifi as been very flaky today [06:33] reviewing now [06:33] ok, no hurry [06:33] you've got two LGTM's [06:33] i'd just commit it so you can close out the day [06:33] any comments I make would be stylaistic [06:33] ok, thanks, wasn't sure if your issues needed to be formalled +1ed [06:33] but did address them [06:34] nah, we're a trusting lot [06:34] a lot of the issues were already in the code i cut and pasted from elsewhere [06:34] but i think everything is much better now [06:34] s'ok, it takes a while to learn the Go idioms, and then to intergrate them with the Canonical Go idioms [06:38] yeah, tell me about it :-) [06:38] especially the lack of interfaces [06:42] davechen1y: so the lp mp is not approved, and that's also why i thought i might still need to seek approval [06:42] ie it is still marked as needs review [06:42] wallyworld_: i don't know how it is done on goose [06:42] but on juju-core we don't care about that [06:43] i don't know if you have any procedural interlocks on your project [06:43] on juju-ore lbox submit has always trusted me to do the right thing [06:44] Good morning. [06:44] davechen1y: ok, thanks, just wanted to check :-) [06:44] wallyworld_: might be a point to raise next tuesday [06:44] ok. i guess i'm used ti using p for everything [06:45] lp i mean, not p [06:47] TheMue, wallyworld_, davechen1y, mornings [06:47] fwereade: Hiya. [06:47] morning all [06:48] davechen1y: Have a nice evening. ;) [06:53] fwereade: morning === TheMue_ is now known as TheMue [08:57] morning campers! [08:58] mgz, dimitern, wallyworld_: I'm going to miss the standup today, we have a Parent Teacher conference this afternoon. But please go on without me. [08:58] hi rogpeppe [08:59] jam: okay [09:02] rogpeppe, btw, can I assume that state.Info.UseSSH will be disappearing soon? [09:02] fwereade: as soon as i submit this morning, yes [09:02] rogpeppe, marvellous [09:03] rogpeppe: Hiya [09:05] jam: If I'm right you told something about looking for an OAuth package. Did you have any success with it? [09:14] hey all, I need to be away for a couple of hours -- doctors appointment that I will parlay into an early lunch [09:31] okay, I hate type assertions and I hate json ;_; [09:31] if only unpacking into a struct actually worked here [09:32] rogpeppe: please help me find a non-idiotic way to do this [09:32] mgz: i'll try :-) [09:32] mgz: what's the json you're trying to parse? [09:33] I have json in the form {NAME: {"code": CODE, "message": MESSAGE}} where caps are variables, that I want to end up in a struct [09:34] mgz: map[string] struct{Code string; Message string} ? [09:34] mgz: i know it's not quite what you want [09:34] mgz: but at least you can avoid type assertions [09:35] I tried that [09:35] mgz: oh? seems like it should work [09:35] it sort of does... [09:36] in that it parses, but it doesn't ever not parse, which is a little annoying, [09:37] and what was the other thing... [09:37] it seems less bad than using map[string]interface{} and picking the bits out now I've tried that as well [09:37] mgz: try explicitly specifying the fields with `json:"CODE"` after [09:38] dimitern: that won't make a difference if you're only unmarshalling - json does case folding [09:38] rogpeppe: I see.. [09:38] mgz: i'm not sure what you mean by "it doesn't ever not parse" - it seems like there are many things that it'll reject [09:39] I shall retry that method and see what tears I run into [09:39] jam: Ping. [09:40] TheMue: I'm not sure if what he said earlier was the PTA thing was right now, or in an an hour over our standup [09:41] *parents evening [09:42] mgz: something like this seems not unreasonable: http://play.golang.org/p/xDBuMpNTTI [09:42] mgz: Ah, ok, yes. Thx. [09:42] mgz: except it does accept spurious Name fields in the elements [09:43] rogpeppe: I don't mind the idea of having a different anon struct to unpack into then filling in the fields of the struct I care about rather than trying to directly map [09:43] mgz: yeah, that's a common approach [09:44] mgz: it means that json can do all the dogwork of checking for validity [09:44] mgz: using interface{} is something that's worth avoiding if at all possible [09:44] it seems working with dicts is just a pain in the bump comparitively [09:45] bump? [09:49] mgz: really? maps seem to me to be pretty similar to dicts [09:50] mgz: the problem is you want a key in the map to become a field in the struct [09:51] until you have anything nested, then there's a lot of interface{} not being helpful [09:51] mgz: ah, you mean when you've got different kinds of things in the map? [09:51] or just maps in maps. [09:52] mgz: should be fine too [09:52] mgz: map[x]map[y]z [09:52] it's nice in that it doesn't let you be sloppy (python/js makes it easy to write non-robust code and hard to write robust) [09:53] rogpeppe: only if there's an entirely uniform level of nesting [09:53] mgz: yeah. [09:53] so, yes, diverse types [09:53] mgz: you can still avoid interface{} though [09:53] mgz: sometimes [09:53] mgz: by judicious use of json.RawMessage [09:53] anon struct seems the nice sloppy way [09:54] mgz: certainly that can work if there's no clash in field names/types [09:59] okay, this is bad code, but what circumstances exactly do you get "err is shadowed by return"... seems the convention is to reuse the name, but then I have to declare again to use a specific type for a certain err [10:02] hm, looks like I don't need to redeclare, go is just trying to tell me my error struct is wrong [10:10] okay, test now works [10:12] could some one please run some live tests in juju-core trunk for me please? i'm seeing a consistent failure, and i'm not sure if it's the result of a change in amazon or our code. [10:12] go test -amazon -gocheck.f 'BootstrapMultiple|GlobalPorts|StartStop' [10:12] in environs/ec2 [10:12] i'm consistently seeing 2 out of 3 of those tests passing [10:12] TheMue: ^ [10:12] davechen1y: ^ [10:13] I'll try it. [10:13] rogpeppe: Yep, will do. [10:14] mgz, TheMue: thanks. the more the merrier. [10:18] hm, those tests also demand a public key in home... and want the amz style vars not euca ones... [10:18] running now. [10:19] or I assume it is, no output yet [10:19] mgz: yeah, sorry. [10:20] mgz: maybe we should accept euca-style vars [10:20] rogpeppe: 5 PASS, 2 FAILED [10:20] TheMue: good, it's not just me then [10:20] mgz: isn't it weird we call the other services in goose nova and swift, and we call keystone - identity? we might as well call the others compute and object-store [10:20] TheMue: which ones failed? [10:20] I got three failures, but probably different... [10:21] rogpeppe: localLiveSuite.TestStartStop and LiveTests.TestStartStop, interesting. [10:21] mgz: if you got three failures, that'll be all of 'em [10:22] looks like amazon is consistently taking more than 30 seconds to mark an instance as shutting down [10:22] may be setup related though [10:22] mgz: could you paste your test failure text? [10:22] it's not getting an instance created [10:22] rogpeppe: http://pastebin.ubuntu.com/1396599/ [10:23] mgz: i thought you had 3 failures [10:23] mgz: FWIW that one matches the error i'm seeing [10:24] they're all that (as far as I could see, didn't pipe output anywhere [10:25] mgz: no, i think there must be quite a bit more output than that [10:25] mgz: can't you scroll back in your terminal? [10:26] mgz, wallyworld_, jam: if there are no objections, I'll pick up the novaservice double next [10:26] okay, actually different [10:26] dimitern: ok, i had just started a branch to do it, and put a card on the board [10:26] dimitern: yes, I'd be tempted to use compute and object-store as names [10:26] but if you want it you can have it [10:27] wallyworld_: well, if you stared and made good progress on it, maybe you should continue, since I'm just starting now [10:27] TheMue: could you paste your test failures, please? [10:27] rogpeppe: Sure. [10:27] dimitern: i have hardly done anything except create the branch and copy one file [10:27] * rogpeppe often finds that staring at things helps progress too. [10:28] so if you can make good progress today, you may as well do it [10:28] wallyworld_: ok, then I'd like to pick it up pls [10:28] sure [10:28] rogpeppe: http://paste.ubuntu.com/1396611/ [10:28] rogpeppe: http://paste.ubuntu.com/1396612/ [10:28] and pastebinit is nice... [10:28] wallyworld_: i rather like how the swift double looks now and the nova one will be similar, if more complex [10:29] yeah [10:29] * rogpeppe wishes paste.ubuntu.com wrapped text. [10:29] dimitern: i have a branch up for review whichs plugs the swift doublw into the tests, so it's all looking good [10:29] if you need to wrap text, it's a sign your test failure output sucks :) [10:30] outputting the cloud config in a less violently horrible manner would be nice [10:30] wallyworld_: yeah, I looked at it, but jam seems to have caught the most of it already [10:30] mgz: naah, long lines are useful [10:31] mgz: in this case one of the lines has the entire cloudinit file (6K). i've found it dead useful in the past, and it would be a pain if it was split up. [10:31] why? it's basically a yaml file [10:31] having it in serialised escaped form isn't really a win [10:32] you're more likely to miss an error due to that than pick one up in the serialisation logic [10:32] mgz: that comment at the top is important :-) [10:32] that's about the only bug you'd be likely to spot :P [10:33] mgz: the nice thing about it being on one line is i can grep for it [10:33] mgz: and changing \n to real newlines is trivial if i need to look at it [10:34] mgz: though it is perhaps a bad example, yeah. [10:35] this line would be hard to split well though [10:35] [LOG] 19.26103 JUJU environs/ec2: starting machine 0 in "sample-c9c3b04482e7d2fa" running tools version "1.9.3-quantal-amd64" from "https://s3.amazonaws.com/juju-test-c9c3b04482e7d2fa/tools/juju-1.9.3-quantal-amd64.tgz?Expires=1385720740&AWSAccessKeyId=AKIAJILHDJBMQGLFWX3A&Signature=QbS36DvUwVcdKNFiy2yyA42p5FQ%3D" [10:35] just the url is too long [10:36] anyway, horizontal scrollbars for text is *never* right. [10:36] that's the whole ugliness of using pre-signed urls to designate public access [10:36] rather than using a bucket with public acls [10:36] which causes me no end of pain... [10:37] mgz: in that case, public acls would be wrong - it's a private bucket. [10:37] right, which is why the code is a pain [10:37] mgz: interesting. because you can't do a similar thing under openstack? [10:37] there should be two buckets if we want one that needs public access and one that needs to be private [10:38] rogpeppe: swift has middleware to emulate this oddness, no one actually enables it though, because why would you? [10:38] mgz: there are two such buckets. in this case, it's private, but we want to let stuff that we start have access to it. [10:38] rogpeppe: then you want a bucket you can set acls to the stuff you want to be able to access it then [10:39] mgz: so perhaps we should create a new user when we start an environment and create acls that allow access to only that user? [10:39] having an obscure url that enables access from anywhere is just ugh [10:40] mgz: the problem AFAICS with the acls is that if someone has access to the bucket, they have access to everything else that the named user can do [10:40] mgz: in this case we don't want to pass the amz credentials to anything except the bootstrap node [10:41] there are two ways of doing it in swift [10:41] one is user-based, and involves passing a token [10:42] the other is address based, so you can limit to local addresses at least (or just make public) [10:42] mgz: i'm interested in this stuff - how does the former work then? [10:42] mgz: i don't think the latter is appropriate for what we want to do (we're talking IP addresses, right?) [10:44] the same way as all the other auth, so pass keystone some creds and get a token. this has the issues you were talking about if you just have the main user account [10:44] in fact, i'm not sure we really care if anyone reads our private bucket - it doesn't hold any sensitive info [10:44] mgz: how is that different in principle from the above signed url? [10:45] rogpeppe: right, that's what my assessment was, hence the current openstack provider just setting the bucket to let anyone access it [10:45] mgz: yeah, just as long as they can't mutate it [10:45] rogpeppe: the main difference is I can implement one of them reliably and not the other. [10:46] mgz: the other thing is we need to be able to access the contents of the bucket from the command line with no juju installed [10:46] mgz: and preferably without apt-getting too much stuff [10:47] wget works... [10:48] mgz: yeah, that's what we're using. would it work with the token passing method? [10:48] trying to use keystone probably isn't sane, as I'm reasonabnly sure tenant management is an admin level thing, so there's no sane way to create a new one based on your user with more limited permissions [10:49] and you can create a token scoped to a particular region, but not to a single service I belive [10:50] * rogpeppe wants SPKI-style delegation :-) [11:00] mgz: it is time! [11:00] jam: we're on mumble [11:01] dimitern: no jam [11:21] the weird thing about those test failures is that at least one of them is the local suite failing... but running without amazon tests, the local suite passes consistently. [11:22] mgz: we lost you? [11:25] Goood mornings [11:25] niemeyer: morning! [11:27] niemeyer: hiya [11:28] dimitern, wallyworld_: sorry about that, cow-orking place has router issues :) [11:28] mgz_: no worries, we practically finished, everyone's happy :) [11:28] WOohay happiness [11:29] niemeyer: the warm, fuzzy feeling of taming a free-range openstack === mgz_ is now known as mgz [11:30] dimitern: you still want to watch out for that nasty bite though [11:30] lunchtime, biab [11:30] rogpeppe: :) [12:02] rogpeppe, do you think that maybe cloudinit.caCertPath() should actually be environs.CaCertPath()? [12:03] fwereade: possibly. although it's relative to DataDir, so possibly environs.CACertPath(dataDir string) [12:04] rogpeppe, sorry, yeah, that was what I meant [12:04] fwereade: ah [12:05] fwereade: you're looking at container, presumably [12:05] rogpeppe, yeah, more-or-less [12:06] fwereade: i *think* that's the only place that would need it [12:06] rogpeppe, I feel like there's something we could do better with the state.Info [12:06] rogpeppe, well, cloudinit too :) [12:06] rogpeppe, but yeah [12:06] fwereade: ok, the only *other* place we'd need it :-) [12:07] fwereade: what are you thinking about state.Info ? [12:07] rogpeppe, the thing currently on my mind is that isolated units will need their own cert files [12:07] fwereade: why so? [12:07] rogpeppe, they can't see outside their containers [12:07] fwereade: oh yeah, definitely [12:08] fwereade: the container package would be responsible for putting those in place [12:08] rogpeppe, and that it might end up simplest if we copy all the stateinfo info into a single file in the agent dir [12:08] rogpeppe, ie addrs, cert, name, password [12:08] rogpeppe, we already have pw, name is implicit, addrs is passed, and password is...complex [12:08] fwereade: yeah, i've been toying with the idea of just serialising the stateinfo [12:09] rogpeppe, I'm +1 on that I think [12:09] fwereade: i'm not sure [12:10] fwereade: it's quite nice being able to invoke jujud directly without manufacturing some serialised stateinfo [12:10] fwereade: although tbh, have i ever done that? i'm not sure. [12:10] rogpeppe, I have once or twice, but it's rare [12:11] fwereade: actually, it's not quite that simple [12:11] fwereade: agents want to share the CACert but not all state info [12:11] fwereade: although... [12:11] rogpeppe, yeah, understood, we have distinct identity & passwords [12:12] fwereade: i'm trying to think through to what happens when we want to update a CA cert [12:12] rogpeppe, heh, I've been worrying about that but dodging my own questions there [12:12] fwereade: i think it makes sense to have a per-agent version, like we have a per-agent version of the tools [12:13] fwereade: then we can apply the same kind of upgrade approach [12:13] rogpeppe, handwave accepted, sounds plausible :) [12:13] fwereade: i.e. an agent changes its own stateinfo file [12:14] fwereade: i'm starting to like the idea more [12:14] rogpeppe, I'm not sure how significant it is that a stateinfo file will in fact contain *everything* needed to run an agent [12:14] fwereade: not necessarily [12:14] rogpeppe, because it includes entityname, from which we can infer unit/machine name/id [12:14] fwereade: some agents need more [12:15] fwereade: actually, no [12:15] rogpeppe, bother, what am I missing [12:15] oh cool [12:15] fwereade: bootstrap-state needs the environ details [12:15] rogpeppe, ah yeah [12:15] rogpeppe, that's only in jujud by coincidence really though [12:16] fwereade: dataDir ? [12:16] rogpeppe, ha, true [12:16] rogpeppe, but still [12:17] rogpeppe, `jujud agent machine-0 /var/lib/juju` works out quite nice actually, I think, assuming the stateinfo file has a predictable location [12:17] fwereade: there's another problem: i'm not sure we can pass arguments containing newlines to an upstarted command [12:17] rogpeppe, base64 of yaml [12:18] rogpeppe, juju agent even [12:18] fwereade: actually, yeah, we don't *want* to [12:18] rogpeppe, sorry, expand please? [12:18] fwereade: the above arguments look greatr [12:18] s/tr/t/ [12:18] rogpeppe, ah ok [12:18] fwereade: we don't need to pass anything substantial to the command [12:19] fwereade: and those two facts (entity name and data dir) are the two invariants of an agent [12:19] fwereade: everything else could change [12:20] fwereade: so it makes sense to put those in the upstart script and have everything else come from the fs [12:20] rogpeppe, yeah, that is my thought too [12:21] * rogpeppe looks forward to deleting all those command-line flags [12:21] me too :) [12:21] the question is doing it [12:21] fwereade: we'll leave it for the time being - it's not actively harmful [12:21] fwereade: it can be done whenever [12:21] rogpeppe, yeah [12:21] rogpeppe, well [12:22] rogpeppe, it actually rather complicates the upgrade situation [12:22] fwereade: ? [12:23] rogpeppe, agents will need to rewrite their own upstart confs [12:23] fwereade: why's that? [12:23] rogpeppe, `jujud unit --unit-name u/0 ...` != `jujud agent unit-u-0 ...` [12:23] fwereade: oh yeah. excellent point. [12:24] fwereade: best to pare it down while we can do it easily [12:24] rogpeppe, and I'd rather avoid ever having to do that [12:24] rogpeppe, yeah [12:24] fwereade: in fact, now is a good moment, because adding TLS is also backwardly incompatible [12:24] rogpeppe, oh! in that case, ++cool [12:25] rogpeppe, is there any chance you'd be free to look into doing that now while the API ferments in your mind? [12:25] Why is that a significant advantage again? [12:25] fwereade: i'm thinking that rather than having a single file containing all of state.Info, we'd have a different file for each element of it. [12:26] rogpeppe, that would simplify some things [12:26] niemeyer: it makes it easy to change, for instance, the state servers we connect to [12:26] niemeyer: or the CA cert [12:26] I don't see how changing the command line offers that [12:27] niemeyer: currently the state server addresses are baked into the upstart script [12:27] niemeyer: and the CA cert is shared amongst all agents [12:27] rogpeppe: That's a seed address.. we'll continue to need seed addresses, and that will continue to change over the lifetime of the service [12:27] niemeyer, all sorts of things are in the upstart script now, and it will always be challenging to change that [12:27] niemeyer, a layer of indirection really does feel helpful here [12:27] niemeyer: we'll need a seed address, but we'll want the seed address to be able to change too. [12:28] fwereade: I don't see how "jujud agent machine-0 /foo/bar" is a layer of indirection and "jujud unit --unit-name u/0" is not [12:28] niemeyer, it's all the other args that are subject to change isn't it? --state-servers etc [12:29] fwereade: actually it's just state-servers [12:29] niemeyer, if we end up needing to add a flag in future, it will be extremely tedious [12:29] fwereade: These are seed addresses.. they'll necessarily change over the lifetime of the service, and the service can happily track those wherever [12:29] rogpeppe, ok; but --initial-password is also a changing piece of data [12:29] fwereade: no it's not [12:29] rogpeppe, as may be ca-cert in future [12:30] rogpeppe, the *password* does change [12:30] fwereade: ca-cert is already a file name [12:30] rogpeppe, initial-password does at some point outlive its usefulness [12:30] rogpeppe, and more to the point I don't believe we'll ever be able to say we won't need to add more flags at some stage [12:30] fwereade: i'm not sure - we need to know when the password is initial [12:30] fwereade: Indeed, but it'd be easier to understand if your argument was "--initial-password outlives its usefulness, let's remove it" [12:30] fwereade: that's not a problem [12:31] fwereade: rather, the proposed scheme isn't any better in that respect [12:31] rogpeppe, IMO it is a problem if we have agents rewriting their own upstart jobs [12:31] fwereade: we don't add flags, we add stuff to data dir [12:31] I don't think we proposed that [12:31] rogpeppe, that is my overriding concern [12:31] (I didn't, at least) [12:32] niemeyer, how do we accommodate cmdline api changes without rewriting our own upstart jobs? [12:32] fwereade: and i think that's the best argument for the change - the agent name and the data dir are the only two things that *need* to be passed as command line args [12:32] fwereade: You're backing a proposal on the question [12:32] baking [12:32] fwereade: Nobody suggested changing cmdline arguments I believe [12:32] niemeyer, well, we just did [12:32] fwereade: Okay, I didn't [12:32] niemeyer, I think it is somewhat optimistic to state that we never will again :) [12:32] niemeyer, we just did change them [12:33] fwereade: Where? [12:33] niemeyer, jujud --ca-cert [12:33] niemeyer, is new [12:33] yeah state.Info may easily change in the future [12:34] and if it did, we'd need to add stuff in dataDir rather than adding more command-line args [12:34] i think [12:34] niemeyer, I'm suggesting that if we make a point of storing all that information in the agent directory instead, and stuck to that, we would at least eliminate that source of future pain [12:34] fwereade: Okay, so what's your proposal? Dropping --ca-cert? [12:34] fwereade: There would be no ca-cert there.. [12:34] niemeyer, `jujud agent

` [12:35] fwereade: That doesn't solve anything [12:35] fwereade: Which is why I was confused [12:35] fwereade: Changing the command line format won't magically remove arguments from it [12:35] niemeyer, ...and write the state we want to write into the agent dir, which the agent can then use... [12:35] fwereade: What you're arguing about is to remove arguments [12:35] niemeyer: i think that information provides the agent with enough to find out all that it needs to [12:35] rogpeppe: We already know how to find the data dir [12:36] niemeyer, yes, I'm saying that we can and should be able to completely configure an agent knowing nothing but those two arguments [12:36] rogpeppe: We don't need to change anything [12:36] niemeyer: assuming that dataDir and the agent dir have been primed [12:36] rogpeppe: The only argument being made here is to drop command line arguments [12:36] niemeyer, we already have a --data-dir arg, yes [12:36] niemeyer: we're saying that data dir and entity name are all we need [12:36] niemeyer: which makes things simpler [12:36] niemeyer: and just as flexible [12:37] rogpeppe: Sorry, I don't get it.. [12:37] rogpeppe: There are two different concerns being crossed over [12:37] The main point I've seen so far is that we couldn't introduce --ca-cert because we'd have to change the upstart script [12:38] What would happen if we did not add that to the upstart script? [12:38] niemeyer, yes, that is the heart of my concern [12:38] The certificate would magically appear under data dir? [12:38] niemeyer: yes [12:38] rogpeppe: How!? [12:38] niemeyer, we would have to give the information to a unit while it was being installed, yes [12:38] niemeyer: it already does [12:38] rogpeppe: No, it doesn't.. if I bootstrapped an environment, it doesn't have a CA [12:39] niemeyer, we are merely proposing changing the channel by which we pass all the other info like cert and servers [12:39] niemeyer: sure it does. the CA is an argument to cloudinit.MachineConfig [12:39] rogpeppe: That you *just added* [12:39] rogpeppe: My environment from 1 month ago doesn't have anything about that [12:39] rogpeppe: How would that work? [12:40] niemeyer, so what will happen now, if we upgrade from pre-tls to post-tls, is that all the pre-tls scripts, lacking --ca-certs, will fail to run [12:40] niemeyer: we'd need to provide some mechanism for state.Info upgrade [12:40] fwereade: What will happen in your proposed world? [12:40] niemeyer: perhaps not too far removed from our current upgrade logic [12:40] fwereade: We don't have a --ca-cert.. we have a data-dir, that does not have a ca-cert [12:40] fwereade: How does that help the upgrade case to work smoothly? [12:41] niemeyer, I *think* that this can be addressed by running post-upgrade operations [12:41] niemeyer, it requires additional infrastructure [12:41] fwereade: Which operations? There's nothing there, no CA in the machine or locally, and we haven't coded anything about that [12:41] niemeyer, honestly it feels like almost exactly the same problem as any major version upgrade [12:41] fwereade: How will the upgrade work then? [12:42] fwereade: Exactly [12:42] niemeyer, using the same set of waving hands we have employed in the past for major-version upgrades [12:42] fwereade: That's my concern. We're all happily agreeing to fiddle with logic in the name of avoiding future issues, but it's not clear how that would have avoided any issues. [12:42] niemeyer, the lesson here may be that the version we're about to release should be a major-version upgrade [12:42] fwereade: If the ca-cert file under datadir was optional, the --ca-cert could be optional too [12:43] niemeyer, we avoid one specific issue about which I have a bee in my bonnet [12:43] niemeyer, rewriting upstart jobs [12:43] fwereade: That would be the case indeed, if we hadn't clearly stated that we're doing breaking changes for now [12:43] niemeyer, ok, cool, I couldn't remember an official statement of that and was fretting a little :) [12:43] fwereade: I did say that openly during UDS [12:44] fwereade: When we discussed versioning [12:44] niemeyer, but I am not saying that this change will solve the major-version-upgrade problem [12:44] fwereade: i'm not sure that it needs a major-version upgrade actually [12:44] fwereade: Right, which is why I'm concerned [12:44] fwereade: We're about to dive into fiddling with call semantics, without a clear win [12:44]