| wallyworld_ | 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/ | 02:58 |
|---|---|---|
| davechen1y | wallyworld_: sorry I missed you | 06:32 |
| wallyworld_ | no problem | 06:33 |
| davechen1y | my wifi as been very flaky today | 06:33 |
| davechen1y | reviewing now | 06:33 |
| wallyworld_ | ok, no hurry | 06:33 |
| davechen1y | you've got two LGTM's | 06:33 |
| davechen1y | i'd just commit it so you can close out the day | 06:33 |
| davechen1y | any comments I make would be stylaistic | 06:33 |
| wallyworld_ | ok, thanks, wasn't sure if your issues needed to be formalled +1ed | 06:33 |
| wallyworld_ | but did address them | 06:33 |
| davechen1y | nah, we're a trusting lot | 06:34 |
| wallyworld_ | a lot of the issues were already in the code i cut and pasted from elsewhere | 06:34 |
| wallyworld_ | but i think everything is much better now | 06:34 |
| davechen1y | s'ok, it takes a while to learn the Go idioms, and then to intergrate them with the Canonical Go idioms | 06:34 |
| wallyworld_ | yeah, tell me about it :-) | 06:38 |
| wallyworld_ | especially the lack of interfaces | 06:38 |
| wallyworld_ | davechen1y: so the lp mp is not approved, and that's also why i thought i might still need to seek approval | 06:42 |
| wallyworld_ | ie it is still marked as needs review | 06:42 |
| davechen1y | wallyworld_: i don't know how it is done on goose | 06:42 |
| davechen1y | but on juju-core we don't care about that | 06:42 |
| davechen1y | i don't know if you have any procedural interlocks on your project | 06:43 |
| davechen1y | on juju-ore lbox submit has always trusted me to do the right thing | 06:43 |
| TheMue | Good morning. | 06:44 |
| wallyworld_ | davechen1y: ok, thanks, just wanted to check :-) | 06:44 |
| davechen1y | wallyworld_: might be a point to raise next tuesday | 06:44 |
| wallyworld_ | ok. i guess i'm used ti using p for everything | 06:44 |
| wallyworld_ | lp i mean, not p | 06:45 |
| fwereade | TheMue, wallyworld_, davechen1y, mornings | 06:47 |
| TheMue | fwereade: Hiya. | 06:47 |
| davechen1y | morning all | 06:47 |
| TheMue | davechen1y: Have a nice evening. ;) | 06:48 |
| wallyworld_ | fwereade: morning | 06:53 |
| === TheMue_ is now known as TheMue | ||
| rogpeppe | morning campers! | 08:57 |
| jam | 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 |
| jam | hi rogpeppe | 08:58 |
| mgz | jam: okay | 08:59 |
| fwereade | rogpeppe, btw, can I assume that state.Info.UseSSH will be disappearing soon? | 09:02 |
| rogpeppe | fwereade: as soon as i submit this morning, yes | 09:02 |
| fwereade | rogpeppe, marvellous | 09:02 |
| TheMue | rogpeppe: Hiya | 09:03 |
| TheMue | jam: If I'm right you told something about looking for an OAuth package. Did you have any success with it? | 09:05 |
| fwereade | hey all, I need to be away for a couple of hours -- doctors appointment that I will parlay into an early lunch | 09:14 |
| mgz | okay, I hate type assertions and I hate json ;_; | 09:31 |
| mgz | if only unpacking into a struct actually worked here | 09:31 |
| mgz | rogpeppe: please help me find a non-idiotic way to do this | 09:32 |
| rogpeppe | mgz: i'll try :-) | 09:32 |
| rogpeppe | mgz: what's the json you're trying to parse? | 09:32 |
| mgz | 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:33 |
| rogpeppe | mgz: map[string] struct{Code string; Message string} ? | 09:34 |
| rogpeppe | mgz: i know it's not quite what you want | 09:34 |
| rogpeppe | mgz: but at least you can avoid type assertions | 09:34 |
| mgz | I tried that | 09:35 |
| rogpeppe | mgz: oh? seems like it should work | 09:35 |
| mgz | it sort of does... | 09:35 |
| mgz | in that it parses, but it doesn't ever not parse, which is a little annoying, | 09:36 |
| mgz | and what was the other thing... | 09:37 |
| mgz | it seems less bad than using map[string]interface{} and picking the bits out now I've tried that as well | 09:37 |
| dimitern | mgz: try explicitly specifying the fields with `json:"CODE"` after | 09:37 |
| rogpeppe | dimitern: that won't make a difference if you're only unmarshalling - json does case folding | 09:38 |
| dimitern | rogpeppe: I see.. | 09:38 |
| rogpeppe | 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:38 |
| mgz | I shall retry that method and see what tears I run into | 09:39 |
| TheMue | jam: Ping. | 09:39 |
| mgz | 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:40 |
| mgz | *parents evening | 09:41 |
| rogpeppe | mgz: something like this seems not unreasonable: http://play.golang.org/p/xDBuMpNTTI | 09:42 |
| TheMue | mgz: Ah, ok, yes. Thx. | 09:42 |
| rogpeppe | mgz: except it does accept spurious Name fields in the elements | 09:42 |
| mgz | 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 |
| rogpeppe | mgz: yeah, that's a common approach | 09:43 |
| rogpeppe | mgz: it means that json can do all the dogwork of checking for validity | 09:44 |
| rogpeppe | mgz: using interface{} is something that's worth avoiding if at all possible | 09:44 |
| mgz | it seems working with dicts is just a pain in the bump comparitively | 09:44 |
| mgz | bump? | 09:45 |
| rogpeppe | mgz: really? maps seem to me to be pretty similar to dicts | 09:49 |
| rogpeppe | mgz: the problem is you want a key in the map to become a field in the struct | 09:50 |
| mgz | until you have anything nested, then there's a lot of interface{} not being helpful | 09:51 |
| rogpeppe | mgz: ah, you mean when you've got different kinds of things in the map? | 09:51 |
| mgz | or just maps in maps. | 09:51 |
| rogpeppe | mgz: should be fine too | 09:52 |
| rogpeppe | mgz: map[x]map[y]z | 09:52 |
| mgz | 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:52 |
| mgz | rogpeppe: only if there's an entirely uniform level of nesting | 09:53 |
| rogpeppe | mgz: yeah. | 09:53 |
| mgz | so, yes, diverse types | 09:53 |
| rogpeppe | mgz: you can still avoid interface{} though | 09:53 |
| rogpeppe | mgz: sometimes | 09:53 |
| rogpeppe | mgz: by judicious use of json.RawMessage | 09:53 |
| mgz | anon struct seems the nice sloppy way | 09:53 |
| rogpeppe | mgz: certainly that can work if there's no clash in field names/types | 09:54 |
| mgz | 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 | 09:59 |
| mgz | hm, looks like I don't need to redeclare, go is just trying to tell me my error struct is wrong | 10:02 |
| mgz | okay, test now works | 10:10 |
| rogpeppe | 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 |
| rogpeppe | go test -amazon -gocheck.f 'BootstrapMultiple|GlobalPorts|StartStop' | 10:12 |
| rogpeppe | in environs/ec2 | 10:12 |
| rogpeppe | i'm consistently seeing 2 out of 3 of those tests passing | 10:12 |
| rogpeppe | TheMue: ^ | 10:12 |
| rogpeppe | davechen1y: ^ | 10:12 |
| mgz | I'll try it. | 10:13 |
| TheMue | rogpeppe: Yep, will do. | 10:13 |
| rogpeppe | mgz, TheMue: thanks. the more the merrier. | 10:14 |
| mgz | hm, those tests also demand a public key in home... and want the amz style vars not euca ones... | 10:18 |
| mgz | running now. | 10:18 |
| mgz | or I assume it is, no output yet | 10:19 |
| rogpeppe | mgz: yeah, sorry. | 10:19 |
| rogpeppe | mgz: maybe we should accept euca-style vars | 10:20 |
| TheMue | rogpeppe: 5 PASS, 2 FAILED | 10:20 |
| rogpeppe | TheMue: good, it's not just me then | 10:20 |
| dimitern | 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 |
| rogpeppe | TheMue: which ones failed? | 10:20 |
| mgz | I got three failures, but probably different... | 10:20 |
| TheMue | rogpeppe: localLiveSuite.TestStartStop and LiveTests.TestStartStop, interesting. | 10:21 |
| rogpeppe | mgz: if you got three failures, that'll be all of 'em | 10:21 |
| rogpeppe | looks like amazon is consistently taking more than 30 seconds to mark an instance as shutting down | 10:22 |
| mgz | may be setup related though | 10:22 |
| rogpeppe | mgz: could you paste your test failure text? | 10:22 |
| mgz | it's not getting an instance created | 10:22 |
| mgz | rogpeppe: http://pastebin.ubuntu.com/1396599/ | 10:22 |
| rogpeppe | mgz: i thought you had 3 failures | 10:23 |
| rogpeppe | mgz: FWIW that one matches the error i'm seeing | 10:23 |
| mgz | they're all that (as far as I could see, didn't pipe output anywhere | 10:24 |
| rogpeppe | mgz: no, i think there must be quite a bit more output than that | 10:25 |
| rogpeppe | mgz: can't you scroll back in your terminal? | 10:25 |
| dimitern | mgz, wallyworld_, jam: if there are no objections, I'll pick up the novaservice double next | 10:26 |
| mgz | okay, actually different | 10:26 |
| wallyworld_ | dimitern: ok, i had just started a branch to do it, and put a card on the board | 10:26 |
| mgz | dimitern: yes, I'd be tempted to use compute and object-store as names | 10:26 |
| wallyworld_ | but if you want it you can have it | 10:26 |
| dimitern | wallyworld_: well, if you stared and made good progress on it, maybe you should continue, since I'm just starting now | 10:27 |
| rogpeppe | TheMue: could you paste your test failures, please? | 10:27 |
| TheMue | rogpeppe: Sure. | 10:27 |
| wallyworld_ | 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:27 | |
| wallyworld_ | so if you can make good progress today, you may as well do it | 10:28 |
| dimitern | wallyworld_: ok, then I'd like to pick it up pls | 10:28 |
| wallyworld_ | sure | 10:28 |
| mgz | rogpeppe: http://paste.ubuntu.com/1396611/ | 10:28 |
| TheMue | rogpeppe: http://paste.ubuntu.com/1396612/ | 10:28 |
| mgz | and pastebinit is nice... | 10:28 |
| dimitern | wallyworld_: i rather like how the swift double looks now and the nova one will be similar, if more complex | 10:28 |
| wallyworld_ | yeah | 10:29 |
| * rogpeppe wishes paste.ubuntu.com wrapped text. | 10:29 | |
| wallyworld_ | dimitern: i have a branch up for review whichs plugs the swift doublw into the tests, so it's all looking good | 10:29 |
| mgz | if you need to wrap text, it's a sign your test failure output sucks :) | 10:29 |
| mgz | outputting the cloud config in a less violently horrible manner would be nice | 10:30 |
| dimitern | wallyworld_: yeah, I looked at it, but jam seems to have caught the most of it already | 10:30 |
| rogpeppe | mgz: naah, long lines are useful | 10:30 |
| rogpeppe | 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 |
| mgz | why? it's basically a yaml file | 10:31 |
| mgz | having it in serialised escaped form isn't really a win | 10:31 |
| mgz | you're more likely to miss an error due to that than pick one up in the serialisation logic | 10:32 |
| rogpeppe | mgz: that comment at the top is important :-) | 10:32 |
| mgz | that's about the only bug you'd be likely to spot :P | 10:32 |
| rogpeppe | mgz: the nice thing about it being on one line is i can grep for it | 10:33 |
| rogpeppe | mgz: and changing \n to real newlines is trivial if i need to look at it | 10:33 |
| rogpeppe | mgz: though it is perhaps a bad example, yeah. | 10:34 |
| rogpeppe | this line would be hard to split well though | 10:35 |
| rogpeppe | [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 |
| rogpeppe | just the url is too long | 10:35 |
| rogpeppe | anyway, horizontal scrollbars for text is *never* right. | 10:36 |
| mgz | that's the whole ugliness of using pre-signed urls to designate public access | 10:36 |
| mgz | rather than using a bucket with public acls | 10:36 |
| mgz | which causes me no end of pain... | 10:36 |
| rogpeppe | mgz: in that case, public acls would be wrong - it's a private bucket. | 10:37 |
| mgz | right, which is why the code is a pain | 10:37 |
| rogpeppe | mgz: interesting. because you can't do a similar thing under openstack? | 10:37 |
| mgz | there should be two buckets if we want one that needs public access and one that needs to be private | 10:37 |
| mgz | rogpeppe: swift has middleware to emulate this oddness, no one actually enables it though, because why would you? | 10:38 |
| rogpeppe | 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 |
| mgz | rogpeppe: then you want a bucket you can set acls to the stuff you want to be able to access it then | 10:38 |
| rogpeppe | 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 |
| mgz | having an obscure url that enables access from anywhere is just ugh | 10:39 |
| rogpeppe | 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 |
| rogpeppe | mgz: in this case we don't want to pass the amz credentials to anything except the bootstrap node | 10:40 |
| mgz | there are two ways of doing it in swift | 10:41 |
| mgz | one is user-based, and involves passing a token | 10:41 |
| mgz | the other is address based, so you can limit to local addresses at least (or just make public) | 10:42 |
| rogpeppe | mgz: i'm interested in this stuff - how does the former work then? | 10:42 |
| rogpeppe | mgz: i don't think the latter is appropriate for what we want to do (we're talking IP addresses, right?) | 10:42 |
| mgz | 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 |
| rogpeppe | in fact, i'm not sure we really care if anyone reads our private bucket - it doesn't hold any sensitive info | 10:44 |
| rogpeppe | mgz: how is that different in principle from the above signed url? | 10:44 |
| mgz | rogpeppe: right, that's what my assessment was, hence the current openstack provider just setting the bucket to let anyone access it | 10:45 |
| rogpeppe | mgz: yeah, just as long as they can't mutate it | 10:45 |
| mgz | rogpeppe: the main difference is I can implement one of them reliably and not the other. | 10:45 |
| rogpeppe | 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 |
| rogpeppe | mgz: and preferably without apt-getting too much stuff | 10:46 |
| mgz | wget works... | 10:47 |
| rogpeppe | mgz: yeah, that's what we're using. would it work with the token passing method? | 10:48 |
| mgz | 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:48 |
| mgz | and you can create a token scoped to a particular region, but not to a single service I belive | 10:49 |
| * rogpeppe wants SPKI-style delegation :-) | 10:50 | |
| wallyworld_ | mgz: it is time! | 11:00 |
| dimitern | jam: we're on mumble | 11:00 |
| mgz | dimitern: no jam | 11:01 |
| rogpeppe | 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:21 |
| wallyworld_ | mgz: we lost you? | 11:22 |
| niemeyer | Goood mornings | 11:25 |
| dimitern | niemeyer: morning! | 11:25 |
| rogpeppe | niemeyer: hiya | 11:27 |
| mgz_ | dimitern, wallyworld_: sorry about that, cow-orking place has router issues :) | 11:28 |
| dimitern | mgz_: no worries, we practically finished, everyone's happy :) | 11:28 |
| niemeyer | WOohay happiness | 11:28 |
| dimitern | niemeyer: the warm, fuzzy feeling of taming a free-range openstack | 11:29 |
| === mgz_ is now known as mgz | ||
| rogpeppe | dimitern: you still want to watch out for that nasty bite though | 11:30 |
| TheMue | lunchtime, biab | 11:30 |
| dimitern | rogpeppe: :) | 11:30 |
| fwereade | rogpeppe, do you think that maybe cloudinit.caCertPath() should actually be environs.CaCertPath()? | 12:02 |
| rogpeppe | fwereade: possibly. although it's relative to DataDir, so possibly environs.CACertPath(dataDir string) | 12:03 |
| fwereade | rogpeppe, sorry, yeah, that was what I meant | 12:04 |
| rogpeppe | fwereade: ah | 12:04 |
| rogpeppe | fwereade: you're looking at container, presumably | 12:05 |
| fwereade | rogpeppe, yeah, more-or-less | 12:05 |
| rogpeppe | fwereade: i *think* that's the only place that would need it | 12:06 |
| fwereade | rogpeppe, I feel like there's something we could do better with the state.Info | 12:06 |
| fwereade | rogpeppe, well, cloudinit too :) | 12:06 |
| fwereade | rogpeppe, but yeah | 12:06 |
| rogpeppe | fwereade: ok, the only *other* place we'd need it :-) | 12:06 |
| rogpeppe | fwereade: what are you thinking about state.Info ? | 12:07 |
| fwereade | rogpeppe, the thing currently on my mind is that isolated units will need their own cert files | 12:07 |
| rogpeppe | fwereade: why so? | 12:07 |
| fwereade | rogpeppe, they can't see outside their containers | 12:07 |
| rogpeppe | fwereade: oh yeah, definitely | 12:07 |
| rogpeppe | fwereade: the container package would be responsible for putting those in place | 12:08 |
| fwereade | 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 |
| fwereade | rogpeppe, ie addrs, cert, name, password | 12:08 |
| fwereade | rogpeppe, we already have pw, name is implicit, addrs is passed, and password is...complex | 12:08 |
| rogpeppe | fwereade: yeah, i've been toying with the idea of just serialising the stateinfo | 12:08 |
| fwereade | rogpeppe, I'm +1 on that I think | 12:09 |
| rogpeppe | fwereade: i'm not sure | 12:09 |
| rogpeppe | fwereade: it's quite nice being able to invoke jujud directly without manufacturing some serialised stateinfo | 12:10 |
| rogpeppe | fwereade: although tbh, have i ever done that? i'm not sure. | 12:10 |
| fwereade | rogpeppe, I have once or twice, but it's rare | 12:10 |
| rogpeppe | fwereade: actually, it's not quite that simple | 12:11 |
| rogpeppe | fwereade: agents want to share the CACert but not all state info | 12:11 |
| rogpeppe | fwereade: although... | 12:11 |
| fwereade | rogpeppe, yeah, understood, we have distinct identity & passwords | 12:11 |
| rogpeppe | fwereade: i'm trying to think through to what happens when we want to update a CA cert | 12:12 |
| fwereade | rogpeppe, heh, I've been worrying about that but dodging my own questions there | 12:12 |
| rogpeppe | fwereade: i think it makes sense to have a per-agent version, like we have a per-agent version of the tools | 12:12 |
| rogpeppe | fwereade: then we can apply the same kind of upgrade approach | 12:13 |
| fwereade | rogpeppe, handwave accepted, sounds plausible :) | 12:13 |
| rogpeppe | fwereade: i.e. an agent changes its own stateinfo file | 12:13 |
| rogpeppe | fwereade: i'm starting to like the idea more | 12:14 |
| fwereade | 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 |
| rogpeppe | fwereade: not necessarily | 12:14 |
| fwereade | rogpeppe, because it includes entityname, from which we can infer unit/machine name/id | 12:14 |
| rogpeppe | fwereade: some agents need more | 12:14 |
| rogpeppe | fwereade: actually, no | 12:15 |
| fwereade | rogpeppe, bother, what am I missing | 12:15 |
| fwereade | oh cool | 12:15 |
| rogpeppe | fwereade: bootstrap-state needs the environ details | 12:15 |
| fwereade | rogpeppe, ah yeah | 12:15 |
| fwereade | rogpeppe, that's only in jujud by coincidence really though | 12:15 |
| rogpeppe | fwereade: dataDir ? | 12:16 |
| fwereade | rogpeppe, ha, true | 12:16 |
| fwereade | rogpeppe, but still | 12:16 |
| fwereade | 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 |
| rogpeppe | fwereade: there's another problem: i'm not sure we can pass arguments containing newlines to an upstarted command | 12:17 |
| fwereade | rogpeppe, base64 of yaml | 12:17 |
| fwereade | rogpeppe, juju agent even | 12:18 |
| rogpeppe | fwereade: actually, yeah, we don't *want* to | 12:18 |
| fwereade | rogpeppe, sorry, expand please? | 12:18 |
| rogpeppe | fwereade: the above arguments look greatr | 12:18 |
| rogpeppe | s/tr/t/ | 12:18 |
| fwereade | rogpeppe, ah ok | 12:18 |
| rogpeppe | fwereade: we don't need to pass anything substantial to the command | 12:18 |
| rogpeppe | fwereade: and those two facts (entity name and data dir) are the two invariants of an agent | 12:19 |
| rogpeppe | fwereade: everything else could change | 12:19 |
| rogpeppe | fwereade: so it makes sense to put those in the upstart script and have everything else come from the fs | 12:20 |
| fwereade | rogpeppe, yeah, that is my thought too | 12:20 |
| * rogpeppe looks forward to deleting all those command-line flags | 12:21 | |
| fwereade | me too :) | 12:21 |
| fwereade | the question is doing it | 12:21 |
| rogpeppe | fwereade: we'll leave it for the time being - it's not actively harmful | 12:21 |
| rogpeppe | fwereade: it can be done whenever | 12:21 |
| fwereade | rogpeppe, yeah | 12:21 |
| fwereade | rogpeppe, well | 12:21 |
| fwereade | rogpeppe, it actually rather complicates the upgrade situation | 12:22 |
| rogpeppe | fwereade: ? | 12:22 |
| fwereade | rogpeppe, agents will need to rewrite their own upstart confs | 12:23 |
| rogpeppe | fwereade: why's that? | 12:23 |
| fwereade | rogpeppe, `jujud unit --unit-name u/0 ...` != `jujud agent unit-u-0 ...` | 12:23 |
| rogpeppe | fwereade: oh yeah. excellent point. | 12:23 |
| rogpeppe | fwereade: best to pare it down while we can do it easily | 12:24 |
| fwereade | rogpeppe, and I'd rather avoid ever having to do that | 12:24 |
| fwereade | rogpeppe, yeah | 12:24 |
| rogpeppe | fwereade: in fact, now is a good moment, because adding TLS is also backwardly incompatible | 12:24 |
| fwereade | rogpeppe, oh! in that case, ++cool | 12:24 |
| fwereade | rogpeppe, is there any chance you'd be free to look into doing that now while the API ferments in your mind? | 12:25 |
| niemeyer | Why is that a significant advantage again? | 12:25 |
| rogpeppe | 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:25 |
| fwereade | rogpeppe, that would simplify some things | 12:26 |
| rogpeppe | niemeyer: it makes it easy to change, for instance, the state servers we connect to | 12:26 |
| rogpeppe | niemeyer: or the CA cert | 12:26 |
| niemeyer | I don't see how changing the command line offers that | 12:26 |
| rogpeppe | niemeyer: currently the state server addresses are baked into the upstart script | 12:27 |
| rogpeppe | niemeyer: and the CA cert is shared amongst all agents | 12:27 |
| niemeyer | 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 |
| fwereade | niemeyer, all sorts of things are in the upstart script now, and it will always be challenging to change that | 12:27 |
| fwereade | niemeyer, a layer of indirection really does feel helpful here | 12:27 |
| rogpeppe | niemeyer: we'll need a seed address, but we'll want the seed address to be able to change too. | 12:27 |
| niemeyer | 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 |
| fwereade | niemeyer, it's all the other args that are subject to change isn't it? --state-servers etc | 12:28 |
| rogpeppe | fwereade: actually it's just state-servers | 12:29 |
| fwereade | niemeyer, if we end up needing to add a flag in future, it will be extremely tedious | 12:29 |
| niemeyer | 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 |
| fwereade | rogpeppe, ok; but --initial-password is also a changing piece of data | 12:29 |
| rogpeppe | fwereade: no it's not | 12:29 |
| fwereade | rogpeppe, as may be ca-cert in future | 12:29 |
| fwereade | rogpeppe, the *password* does change | 12:30 |
| rogpeppe | fwereade: ca-cert is already a file name | 12:30 |
| fwereade | rogpeppe, initial-password does at some point outlive its usefulness | 12:30 |
| fwereade | 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 |
| rogpeppe | fwereade: i'm not sure - we need to know when the password is initial | 12:30 |
| niemeyer | fwereade: Indeed, but it'd be easier to understand if your argument was "--initial-password outlives its usefulness, let's remove it" | 12:30 |
| rogpeppe | fwereade: that's not a problem | 12:30 |
| rogpeppe | fwereade: rather, the proposed scheme isn't any better in that respect | 12:31 |
| fwereade | rogpeppe, IMO it is a problem if we have agents rewriting their own upstart jobs | 12:31 |
| rogpeppe | fwereade: we don't add flags, we add stuff to data dir | 12:31 |
| niemeyer | I don't think we proposed that | 12:31 |
| fwereade | rogpeppe, that is my overriding concern | 12:31 |
| niemeyer | (I didn't, at least) | 12:31 |
| fwereade | niemeyer, how do we accommodate cmdline api changes without rewriting our own upstart jobs? | 12:32 |
| rogpeppe | 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 |
| niemeyer | fwereade: You're backing a proposal on the question | 12:32 |
| niemeyer | baking | 12:32 |
| niemeyer | fwereade: Nobody suggested changing cmdline arguments I believe | 12:32 |
| fwereade | niemeyer, well, we just did | 12:32 |
| niemeyer | fwereade: Okay, I didn't | 12:32 |
| fwereade | niemeyer, I think it is somewhat optimistic to state that we never will again :) | 12:32 |
| fwereade | niemeyer, we just did change them | 12:32 |
| niemeyer | fwereade: Where? | 12:33 |
| fwereade | niemeyer, jujud <agent> --ca-cert | 12:33 |
| fwereade | niemeyer, is new | 12:33 |
| rogpeppe | yeah state.Info may easily change in the future | 12:33 |
| rogpeppe | and if it did, we'd need to add stuff in dataDir rather than adding more command-line args | 12:34 |
| rogpeppe | i think | 12:34 |
| fwereade | 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 |
| niemeyer | fwereade: Okay, so what's your proposal? Dropping --ca-cert? | 12:34 |
| niemeyer | fwereade: There would be no ca-cert there.. | 12:34 |
| fwereade | niemeyer, `jujud agent <entity-name> <data-dir>` | 12:34 |
| niemeyer | fwereade: That doesn't solve anything | 12:35 |
| niemeyer | fwereade: Which is why I was confused | 12:35 |
| niemeyer | fwereade: Changing the command line format won't magically remove arguments from it | 12:35 |
| fwereade | niemeyer, ...and write the state we want to write into the agent dir, which the agent can then use... | 12:35 |
| niemeyer | fwereade: What you're arguing about is to remove arguments | 12:35 |
| rogpeppe | niemeyer: i think that information provides the agent with enough to find out all that it needs to | 12:35 |
| niemeyer | rogpeppe: We already know how to find the data dir | 12:35 |
| fwereade | 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 |
| niemeyer | rogpeppe: We don't need to change anything | 12:36 |
| rogpeppe | niemeyer: assuming that dataDir and the agent dir have been primed | 12:36 |
| niemeyer | rogpeppe: The only argument being made here is to drop command line arguments | 12:36 |
| fwereade | niemeyer, we already have a --data-dir arg, yes | 12:36 |
| rogpeppe | niemeyer: we're saying that data dir and entity name are all we need | 12:36 |
| rogpeppe | niemeyer: which makes things simpler | 12:36 |
| rogpeppe | niemeyer: and just as flexible | 12:36 |
| niemeyer | rogpeppe: Sorry, I don't get it.. | 12:37 |
| niemeyer | rogpeppe: There are two different concerns being crossed over | 12:37 |
| niemeyer | 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:37 |
| niemeyer | What would happen if we did not add that to the upstart script? | 12:38 |
| fwereade | niemeyer, yes, that is the heart of my concern | 12:38 |
| niemeyer | The certificate would magically appear under data dir? | 12:38 |
| rogpeppe | niemeyer: yes | 12:38 |
| niemeyer | rogpeppe: How!? | 12:38 |
| fwereade | niemeyer, we would have to give the information to a unit while it was being installed, yes | 12:38 |
| rogpeppe | niemeyer: it already does | 12:38 |
| niemeyer | rogpeppe: No, it doesn't.. if I bootstrapped an environment, it doesn't have a CA | 12:38 |
| fwereade | niemeyer, we are merely proposing changing the channel by which we pass all the other info like cert and servers | 12:39 |
| rogpeppe | niemeyer: sure it does. the CA is an argument to cloudinit.MachineConfig | 12:39 |
| niemeyer | rogpeppe: That you *just added* | 12:39 |
| niemeyer | rogpeppe: My environment from 1 month ago doesn't have anything about that | 12:39 |
| niemeyer | rogpeppe: How would that work? | 12:39 |
| fwereade | 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 |
| rogpeppe | niemeyer: we'd need to provide some mechanism for state.Info upgrade | 12:40 |
| niemeyer | fwereade: What will happen in your proposed world? | 12:40 |
| rogpeppe | niemeyer: perhaps not too far removed from our current upgrade logic | 12:40 |
| niemeyer | fwereade: We don't have a --ca-cert.. we have a data-dir, that does not have a ca-cert | 12:40 |
| niemeyer | fwereade: How does that help the upgrade case to work smoothly? | 12:40 |
| fwereade | niemeyer, I *think* that this can be addressed by running post-upgrade operations | 12:41 |
| fwereade | niemeyer, it requires additional infrastructure | 12:41 |
| niemeyer | fwereade: Which operations? There's nothing there, no CA in the machine or locally, and we haven't coded anything about that | 12:41 |
| fwereade | niemeyer, honestly it feels like almost exactly the same problem as any major version upgrade | 12:41 |
| niemeyer | fwereade: How will the upgrade work then? | 12:41 |
| niemeyer | fwereade: Exactly | 12:42 |
| fwereade | niemeyer, using the same set of waving hands we have employed in the past for major-version upgrades | 12:42 |
| niemeyer | 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 |
| fwereade | niemeyer, the lesson here may be that the version we're about to release should be a major-version upgrade | 12:42 |
| niemeyer | fwereade: If the ca-cert file under datadir was optional, the --ca-cert could be optional too | 12:42 |
| fwereade | niemeyer, we avoid one specific issue about which I have a bee in my bonnet | 12:43 |
| fwereade | niemeyer, rewriting upstart jobs | 12:43 |
| niemeyer | fwereade: That would be the case indeed, if we hadn't clearly stated that we're doing breaking changes for now | 12:43 |
| fwereade | niemeyer, ok, cool, I couldn't remember an official statement of that and was fretting a little :) | 12:43 |
| niemeyer | fwereade: I did say that openly during UDS | 12:43 |
| niemeyer | fwereade: When we discussed versioning | 12:44 |
| fwereade | niemeyer, but I am not saying that this change will solve the major-version-upgrade problem | 12:44 |
| rogpeppe | fwereade: i'm not sure that it needs a major-version upgrade actually | 12:44 |
| niemeyer | fwereade: Right, which is why I'm concerned | 12:44 |
| niemeyer | fwereade: We're about to dive into fiddling with call semantics, without a clear win | 12:44 |
| fwereade | niemeyer, I am saying that it solves one small but real sub-problem | 12:44 |
| niemeyer | fwereade: Which one again!? :-) | 12:45 |
| rogpeppe | niemeyer: i don't think this proposed change actually fixes anything we can't fix in the future, but i think we will end up at a place where the current command line arguments feel like pure cruft | 12:45 |
| niemeyer | fwereade: Please tell me about a real problem we have that it is solving.. maybe that'll clarify the point | 12:45 |
| rogpeppe | niemeyer: but we have to continue supporting them | 12:45 |
| rogpeppe | niemeyer: because they're baked into all the upstart scripts | 12:46 |
| rogpeppe | niemeyer: so perhaps in that sense it's more of an aethetic change | 12:46 |
| rogpeppe | aesthetic | 12:46 |
| fwereade | niemeyer, the problem is that implicit version information is encoded in the upstart scripts, and it upsets me to have anyone other than the installer messing with upstart scripts | 12:46 |
| rogpeppe | fwereade: i don't think that's actually a problem in practice | 12:47 |
| niemeyer | fwereade: We have never messed up with upstart scripts | 12:47 |
| fwereade | niemeyer, by removing it, we separate the agent installation concern from the upgrade concern | 12:47 |
| rogpeppe | fwereade: we just support the current command line args forever, and never change tem | 12:47 |
| rogpeppe | them | 12:47 |
| fwereade | rogpeppe, are they currently so wonderful that it seems sensible to enshrine them forever? :) | 12:48 |
| niemeyer | fwereade: But sure, if the argument is "let's remove --ca-cert", so be it.. it's not a real problem we have, but could be one day | 12:48 |
| rogpeppe | fwereade: absolutely not. | 12:48 |
| rogpeppe | fwereade: but it's not a technical problem. | 12:48 |
| niemeyer | Right | 12:49 |
| niemeyer | fwereade: If you want to remove --initial-password as well for the same reason, I also don't mind | 12:49 |
| rogpeppe | fwereade: i want to remove them just because i don't like unnecessary cruft that's just there for backward-compatibility purposes. | 12:49 |
| niemeyer | fwereade: I'm just observing that, in practice, even if we hadn't introduced --ca-cert, compatibility would be broken | 12:49 |
| fwereade | niemeyer, I understand that, and that wasn't what I was trying to address | 12:50 |
| rogpeppe | fwereade: that's totally true. quite apart from the fact we're now dialling a different port and speaking a different protocol :-) | 12:50 |
| rogpeppe | s/fwreade/niemeyer/ :-) | 12:50 |
| fwereade | niemeyer, I can't quite tell if you're -1 on the whole idea or just pointing out that I haven't solved the problem you thought I was trying to | 12:52 |
| rogpeppe | afk | 12:54 |
| niemeyer | fwereade: Dropping options and agreeing on the convention you described sounds like a good idea. Rewording "jujud unit --unit-name u/0" as "jujud agent unit-0" sounds purely fiddly with no benefit. | 12:55 |
| fwereade | niemeyer, I dunno, I think it'll make the jujud code rather nicer actually | 12:56 |
| fwereade | niemeyer, that shared agent stuff is not bad, but not awesome either | 12:56 |
| niemeyer | fwereade: Well, that's why we have reviews for then.. I've been wrong before | 12:57 |
| fwereade | niemeyer, ok, I will add it to my less-critical-maybe-sometime list (unless rogpeppe wants to do it now ;)) | 12:57 |
| niemeyer | fwereade: Well, now is the time to do it if you want to do it | 12:58 |
| fwereade | niemeyer, or maybe I'll turn out to be wrong and I'll write the code and then quietly pretend it never happened ;) | 12:58 |
| niemeyer | fwereade: Because we're breaking compatibility due to the ca-cert stuff | 12:58 |
| fwereade | niemeyer, well, I'd thought so... gaaaaah hmm I think the installer stuff will also break compatibility | 12:59 |
| fwereade | niemeyer, so either I do that *now* (which I might...) and maybe get it into this compatibility-break... or we're due one in the future | 12:59 |
| niemeyer | fwereade: Please try to imagine what we'd have to do if we had different workers requiring different information | 13:00 |
| niemeyer | fwereade: I mean, while doing the change | 13:00 |
| fwereade | niemeyer, I *hope* they'd get their information from the state via their entity name | 13:01 |
| fwereade | niemeyer, as units and machines do now | 13:01 |
| niemeyer | fwereade: Their data-dir doesn't have to look alike either | 13:01 |
| fwereade | niemeyer, agreed -- I'm just proposing that every agent have a few common expected state-info-related files somewhere in their agent dirs | 13:02 |
| niemeyer | fwereade: So basically what's being said is that we'd be using the "unit" in unit-0 instead of the "unit" in "jujud unit' | 13:02 |
| niemeyer | fwereade: Okay | 13:02 |
| fwereade | niemeyer, that should impose no further restrictions on what else is stored there | 13:02 |
| fwereade | niemeyer, yeah | 13:02 |
| niemeyer | fwereade: The point I'm making, just to be clear, is that different workers may require (and do require, I believe) different data | 13:03 |
| niemeyer | fwereade: Right now we have two "agents" only | 13:04 |
| niemeyer | fwereade: Which means two small command files that are clear entry points within cmd/jujud | 13:04 |
| fwereade | niemeyer, I am suggesting that they should always be in a position to get that data from state in their own ways, and to store it in their own ways, but that the mechanism by which they connect to state should be the same | 13:04 |
| niemeyer | fwereade: There's logic that is not about connecting to the state in those files | 13:05 |
| niemeyer | fwereade: although it is true that there's logic that is common too | 13:05 |
| niemeyer | fwereade: Anyway, I'll be happy to review the change.. | 13:06 |
| fwereade | niemeyer, it feels like the common stuff would be a lot clearer, and the differences would be an if or two | 13:06 |
| niemeyer | fwereade: After the refactoring of the watchers, right? | 13:06 |
| niemeyer | fwereade: ;-) | 13:06 |
| fwereade | niemeyer, that was exactly my point re my being able to do it right now ;-) | 13:06 |
| niemeyer | fwereade: Well, it's also my point :-) | 13:07 |
| rogpeppe | back | 13:07 |
| fwereade | niemeyer, well, there we are -- it won't happen this change | 13:07 |
| fwereade | niemeyer, this release^^ | 13:07 |
| fwereade | niemeyer, but if I miss this release with the installer, which I probably will unless *everything* goes right | 13:08 |
| fwereade | niemeyer, there will be a future compatibility-breaker | 13:08 |
| fwereade | niemeyer, and I will consider it for inclusion then | 13:08 |
| niemeyer | fwereade: Well, as long as the change proves fruitful, I personally wouldn't mind introducing it in a follow up | 13:09 |
| niemeyer | fwereade: As long as we don't take too long | 13:09 |
| fwereade | niemeyer, I have a few branching followups on my plate still, I don't want to commit to any more at this moment | 13:10 |
| fwereade | niemeyer, I will try to work it into the interstices of my days but I make no guarantees :) | 13:10 |
| niemeyer | fwereade: Sounds good :) | 13:12 |
| rogpeppe | lunch | 13:59 |
| niemeyer | rogpeppe: Enjoy | 14:10 |
| rogpeppe | niemeyer: i did | 14:11 |
| mgz | ...that was fast devouring | 14:13 |
| niemeyer | rogpeppe: Wow :) | 14:16 |
| niemeyer | I'm going to lunch too, but I'll take a bit longer :) | 14:16 |
| rogpeppe | TheMue, mgz: here's one fix for the broken tests: https://codereview.appspot.com/6850121 | 14:25 |
| TheMue | rogpeppe: Ah, great, I'll take a look. | 14:25 |
| * mgz looksies | 14:27 | |
| TheMue | rogpeppe: You've got a LGTM, testing the new number of instances and that it is contained sounds reasonable. | 14:30 |
| TheMue | rogpeppe: So the old constraint of the test isn't valid anymore, ah. | 14:32 |
| rogpeppe | TheMue: actually, it never was | 14:32 |
| mgz | rogpeppe: hm, one failure | 14:32 |
| rogpeppe | TheMue: just nobody ever ran the tests without that Destroy method | 14:32 |
| mgz | ... value *s3.Error = &s3.Error{StatusCode:409, Code:"BucketNotEmpty", Message:"The bucket you tried to delete is not empty", BucketName:"juju-test-c740682924903b28" .... | 14:33 |
| TheMue | rogpeppe: Oh. | 14:33 |
| rogpeppe | mgz: which test failed there? | 14:33 |
| mgz | 'TestEC2' | 14:33 |
| rogpeppe | mgz: i'm going through trying to fix a few live tests 'cos today seems like a good day for bad eventual consistency | 14:33 |
| rogpeppe | mgz: could you paste the test output? | 14:34 |
| mgz | I'll give you a chunk, basically at the destroy stage | 14:34 |
| rogpeppe | mgz: i'd prefer to see the whole thing... | 14:34 |
| mgz | so, bad eventual consistency seems likely, delete bucket contents then delete bucket before that hits | 14:35 |
| rogpeppe | mgz: but i'll go for whatever you've got | 14:35 |
| mgz | rogpeppe: http://paste.ubuntu.com/1397007/ | 14:36 |
| mgz | oo, and a new failure | 14:37 |
| rogpeppe | mgz: unfortunately that snippet doesn't tell me what test failed | 14:38 |
| rogpeppe | mgz: although i can probably guess the right place to fix | 14:40 |
| mgz | rogpeppe: http://paste.ubuntu.com/1397016/ | 14:40 |
| mgz | perhaps some dirty state, will try again as well | 14:40 |
| rogpeppe | mgz: handshake failure is a common thing. the right solution is to handle it in goamz (or maybe go core) | 14:41 |
| rogpeppe | mgz: niemeyer's been promising to do that for ages | 14:41 |
| rogpeppe | mgz: i don't know if it's amazon messing up there or the Go libraries | 14:41 |
| mgz | what should I run after merging a branch to make go test happy by the way? | 14:41 |
| rogpeppe | mgz: it should be happy anyway | 14:42 |
| rogpeppe | mgz: oh, you mean the warnings | 14:42 |
| rogpeppe | mgz: go test -i | 14:42 |
| rogpeppe | mgz: (as it suggests) | 14:42 |
| mgz | oh, so really just that? | 14:42 |
| rogpeppe | mgz: yeah | 14:42 |
| rogpeppe | mgz: and even that's not necessary | 14:42 |
| mgz | ...piped that run to a file, so of course it passed | 14:42 |
| mgz | one more | 14:43 |
| rogpeppe | mgz: for a while i was running the live tests continually in a loop | 14:43 |
| rogpeppe | mgz: that seems to be the only way to find the less usual failure modes. eventual consistency is a bitch. | 14:43 |
| rogpeppe | mgz: at one stage i did plan on modelling eventual consistency in the test server, but it's a right pain to do, and even if you do, who's to say it's anything like amz's. | 14:44 |
| mgz | well, some things are reason-able | 14:46 |
| mgz | like not being able to delete certain things that depend on other things having already been deleted | 14:47 |
| mgz | (security groups, containers, ....) | 14:47 |
| mgz | ...naturally tests refuse to fail again | 14:47 |
| rogpeppe | mgz: of course | 14:48 |
| mgz | rogpeppe: commented | 14:56 |
| rogpeppe | mgz: i agree with some of your comment. perhaps we should have a specific test that tests AllInstances. the test does, however, control the lifetime of other instances - we can assume, i think, that this test is running in a uniquely named environment (we take steps to ensure that) | 14:59 |
| rogpeppe | mgz: AllInstances doesn't return all instances on the given account | 15:00 |
| rogpeppe | mgz: it returns all instances started by the current environment | 15:00 |
| mgz | rogpeppe: right. main thing would either #1 make the assert actually use set logic, or #2 change that comment | 15:02 |
| mgz | rogpeppe: ah right, and the environment is generated and not from your user's envrionments.yaml, which is the clash I was envisioning | 15:03 |
| rogpeppe | mgz: yeah. i think i'll go with the easier option for the time being. i don't particularly feel we need more AllInstances tests. | 15:04 |
| rogpeppe | mgz: yes | 15:04 |
| rogpeppe | mgz: with a random name | 15:04 |
| rogpeppe | mgz: thing is, even if it used set logic, it wouldn't test anything because currently there's at most one other instance there. | 15:05 |
| rogpeppe | mgz: i suppose we could assert that the initialInsts len is at most 1. | 15:05 |
| mgz | set logic is easy! assertEqual(set([1]), set(after).difference(before)) | 15:06 |
| mgz | it tests the uniqueness of the listing, which isn't really a bug we expect I suspect | 15:07 |
| mgz | so, comment change is probably what I'd go for | 15:07 |
| rogpeppe | mgz: i don't see how that tests the uniqueness of the listing | 15:13 |
| rogpeppe | mgz: it converts everything to sets | 15:13 |
| rogpeppe | mgz: which instantly loses dupes | 15:13 |
| mgz | ...that is entirely correct | 15:13 |
| mgz | I'm just confusing myself for no purpose | 15:14 |
| * rogpeppe just got a 90 quid parking fine notice through the door | 15:14 | |
| rogpeppe | bastards | 15:14 |
| mgz | aich | 15:15 |
| TheMue | rogpeppe: Uuuh. | 15:15 |
| niemeyer | rogpeppe: Did you park it in a wrong place or not? | 15:23 |
| niemeyer | rogpeppe: :) | 15:23 |
| rogpeppe | niemeyer: no, carmen did, as far as i can make out... | 15:24 |
| niemeyer | rogpeppe: Well.. so they were just doing their job.. | 15:24 |
| rogpeppe | niemeyer: i know, but bastards anyway :-) | 15:24 |
| niemeyer | LOL | 15:24 |
| niemeyer | So SpamapS is leaving.. I had no idea | 15:24 |
| rogpeppe | niemeyer: i thought you might know why | 15:25 |
| rogpeppe | niemeyer: it's a great pity | 15:25 |
| mgz | rogpeppe: wait, is that the name of a member of the family? I was trying to parse as car-men and couldn't work out what job they would be doing on your car... | 15:27 |
| rogpeppe | mgz: my wife :-) | 15:27 |
| * rogpeppe still feels a little strange saying "wife" | 15:28 | |
| niemeyer | ROTFL | 15:28 |
| niemeyer | mgz: Arguably, the car-men did help | 15:28 |
| niemeyer | rogpeppe: I don't.. I read warthogs very sparingly, and often too late to even comment since the thread has been dead for ages by then | 15:30 |
| rogpeppe | niemeyer: i read it about once every couple of months myself. | 15:30 |
| rogpeppe | niemeyer: but i thought you might've heard through other channels. | 15:30 |
| niemeyer | rogpeppe: Not this time | 15:31 |
| rogpeppe | mgz, niemeyer: just found the story of the car park - it was in a retail park, and the first 2h30m were free... but Carmen didn't realise that and spent 4 hours shopping... | 16:06 |
| niemeyer | rogpeppe: Aw.. sucks :( | 16:07 |
| mgz | that's horrible... | 16:07 |
| rogpeppe | niemeyer: i bet they get loads of people like that. the shops there are enormous, very easy to spend more than 2.5 hours | 16:07 |
| mgz | four hours shopping! | 16:07 |
| rogpeppe | mgz: yeah, not i! | 16:08 |
| rogpeppe | mgz: 10 minutes is too much | 16:08 |
| TheMue | rogpeppe: Shopping for men leads to a pulse like a jet pilot. ;) | 16:12 |
| rogpeppe | TheMue: actually i find i just want to lie down in a corner somewhere :-) | 16:12 |
| TheMue | TheMue: Or at Amazon. :D | 16:13 |
| * TheMue will drive into the city in 30 minutes too. Christmas market with former colleagues, an anual tradition since about 15 years. | 16:14 | |
| fwereade | niemeyer, rogpeppe: can I get a provisional +1 on dropping MachinerWorker (and making it implicit, like upgrader)? | 16:18 |
| niemeyer | fwereade: Hm? | 16:18 |
| niemeyer | fwereade: I'm out of context.. I thought it being a worker was a great idea? | 16:18 |
| fwereade | niemeyer, ah, I thought you commented on it yesterday... | 16:18 |
| rogpeppe | fwereade: you mean naming it "Machiner" ? | 16:19 |
| fwereade | niemeyer, I just mean the state.MachinerWorker constant with which we always have to start new machines | 16:19 |
| niemeyer | fwereade: I did, but I don't recall saying we should kill the Machiner | 16:19 |
| niemeyer | fwereade: Ah, hmm | 16:19 |
| niemeyer | fwereade: Machiner is a real worker | 16:19 |
| fwereade | niemeyer, the difference between st.Addmachine() and st.AddMachine(state.MachinerWorker) absolutely everywhere | 16:19 |
| niemeyer | fwereade: Upgrader isn't.. it's part of the agent internal mechanisms, I think | 16:20 |
| fwereade | niemeyer, as in, it lives in its own package? couldn't/shouldn't the upgrader? | 16:20 |
| rogpeppe | fwereade: the idea was that we might want to start a new machine without running a machine agent | 16:20 |
| niemeyer | fwereade: The reason .. what Roger said | 16:20 |
| fwereade | rogpeppe, ok, but we error out if we omit it | 16:20 |
| rogpeppe | fwereade: currently, yes | 16:20 |
| niemeyer | fwereade: Yes, because *today* we don't support that | 16:20 |
| fwereade | niemeyer, ok, then I'll change it to InstallerWorker everywhere, np :) | 16:21 |
| niemeyer | fwereade: Hm? | 16:21 |
| fwereade | niemeyer, and keep the requirement in place | 16:21 |
| niemeyer | fwereade: Sorry, I'm seriously out of context | 16:21 |
| fwereade | niemeyer, sorry | 16:22 |
| niemeyer | fwereade: What's InstallerWorker? | 16:22 |
| fwereade | niemeyer, the idea is that an Installer replaces Machiner, by working with both principals and subordinates | 16:22 |
| fwereade | niemeyer, we discussed it a few days ago IIRC | 16:22 |
| fwereade | niemeyer, I have such a thing nearly ready to propose but I want to decompose it into a few easy branches | 16:23 |
| niemeyer | fwereade: We didn't talk about this aspect, I believe | 16:23 |
| niemeyer | fwereade: And honestly, it doesn't seem to make sense to me | 16:23 |
| rogpeppe | .... TLS has finally landed! | 16:24 |
| niemeyer | fwereade: A MachinerWorker is a worker that manages units on the machine.. when we put that on an agent, we want that agent to be managing the duties of a machine manager | 16:24 |
| niemeyer | fwereade: What's what AddMachine(MachinerWorker) means (to me, at least) | 16:24 |
| niemeyer | fwereade: I don't get what AddMachine(InstallerWorker) means.. | 16:25 |
| rogpeppe | niemeyer: +1 | 16:25 |
| fwereade | niemeyer, ok, but all a machiner currently does is install (and maybe, if you're lucky, remove) unit agents | 16:25 |
| rogpeppe | fwereade: we can use an Installer even though we're asked to start a MachinerWorker | 16:25 |
| fwereade | niemeyer, I can imagine other things that *are* fundamental to a machine, and those would I feel be best expressed as implicit | 16:26 |
| niemeyer | fwereade: I'm explaining the semantics.. saying the machiner has bugs is a different topic I think | 16:26 |
| fwereade | rogpeppe, I guess, it just seems a bit weird to have a MachinerWorker with no actual... machiner | 16:26 |
| rogpeppe | fwereade: i think it's ok. the Installer does both the job of the machiner and that part of the uniter | 16:27 |
| fwereade | niemeyer, ok, one of the many responsibilities of a machine agent is to install and uninstall units | 16:27 |
| fwereade | rogpeppe, that part of the unit *agent*, right? | 16:27 |
| niemeyer | fwereade: Can we please preserve the terms | 16:27 |
| rogpeppe | fwereade: the difference is in how you start the installer | 16:27 |
| niemeyer | fwereade: Otherwise it will get confusing | 16:27 |
| rogpeppe | fwereade: (yes) | 16:27 |
| niemeyer | fwereade: The MachinerWorker is not an agent | 16:27 |
| rogpeppe | fwereade: if you start an Installer on a machine, it's a machiner; if you start it on a principal unit, it's a uniter installer. | 16:28 |
| fwereade | niemeyer, yes, it will: because, eg, ssh key management is absolutely the preserve of the "machiner" | 16:28 |
| rogpeppe | fwereade: really? | 16:28 |
| niemeyer | fwereade: I'm somewhat lost now | 16:28 |
| niemeyer | (too) | 16:28 |
| fwereade | rogpeppe, what else would update them? when we get round to env-set etc | 16:28 |
| rogpeppe | fwereade: surely different units can accept different ssh keys? | 16:28 |
| niemeyer | fwereade: The machiner is the thing that manages containers responsible for principal units | 16:28 |
| rogpeppe | fwereade: (assuming they're in different containers) | 16:29 |
| fwereade | rogpeppe, ah, ok then: in that case the unit agent and the machine agent will each run KeyManager (or whatever) tasks | 16:29 |
| fwereade | rogpeppe, which I would expect to implement as a worker package | 16:30 |
| rogpeppe | fwereade: sure | 16:30 |
| rogpeppe | fwereade: i think the MachinerWorker name is still fine though | 16:30 |
| niemeyer | fwereade: Yes, or maybe not.. the Machiner may well manage the ssh keys too.. I don't think we've discussed that before | 16:30 |
| fwereade | rogpeppe, so "machiner" is not a useful term when there is no single corresponding task -- otherwise we'd be using "provisioner" to mean "provisioner+firewaller", for example | 16:31 |
| niemeyer | fwereade: But we're not solving that specific problem now.. can you provide some background about how InstallerWorker came to be? | 16:31 |
| niemeyer | fwereade: We could call it fooer.. I think it's more important that we agree on what it means | 16:31 |
| fwereade | niemeyer, it came to be because principals and subordinates produce the same watcher type now, and the response to the events is very very similar in each case | 16:32 |
| niemeyer | fwereade: My understanding is that the Machiner was responsible for the management of principal units on a machine, including their LXC containers if necessary | 16:32 |
| niemeyer | fwereade: Yes, but we can't have AddMachine(Installer) and suddenly have the machine deplying subordinates | 16:32 |
| niemeyer | fwereade: So I still don't quite get what you're suggesting | 16:33 |
| fwereade | niemeyer, indeed so | 16:33 |
| fwereade | niemeyer, a machine with an Installer task would run an installer worker, based on watching the machine's principals | 16:33 |
| fwereade | niemeyer, a unit would run an Installer task if it were a principal unit | 16:34 |
| niemeyer | fwereade: By hand, I suppose | 16:35 |
| fwereade | niemeyer, I feel it's an implicit part of the agent's duties in either case, and doesn't need to be enforced at the API level | 16:35 |
| niemeyer | fwereade: I disagree | 16:35 |
| niemeyer | fwereade: We can easily have a state server that doesn't deploy any units | 16:35 |
| fwereade | niemeyer, well, I feel it should be automatic in both cases: run it as another standard task, just like the upgrader | 16:35 |
| niemeyer | fwereade: The upgrader is not a worker | 16:35 |
| fwereade | niemeyer, in that case I'm also fine with having to specify it if we want the machine to install anything | 16:36 |
| fwereade | niemeyer, the upgrader is a task | 16:36 |
| fwereade | niemeyer, what the agents actually do is run tasks | 16:36 |
| fwereade | niemeyer, for a machine agent, these tasks *roughly* correspond to the constants; for a unit agent, they're all implicit | 16:37 |
| niemeyer | fwereade: The concept of tasks was introduced precisely so that we could put the upgrader there without it being a worker | 16:37 |
| fwereade | niemeyer, in that case, I'm sorry, I must be missing some crucial context myself | 16:37 |
| niemeyer | fwereade: The constants correspond to workers, exactly | 16:38 |
| niemeyer | fwereade: I don't think you're missing things.. you're just not representing the status quo in the description | 16:38 |
| niemeyer | fwereade: and that in turn may create a bit of confusion | 16:38 |
| fwereade | niemeyer, would you explain the criteria that determine whether a persistent thing an agent does is a "worker" or just a lowly "task"? | 16:39 |
| niemeyer | fwereade: You're arguing about several things at the same time: | 16:40 |
| niemeyer | A) The upgrader is not a worker | 16:40 |
| niemeyer | B) The machiner should be implicit | 16:40 |
| niemeyer | C) The machiner is misnamed | 16:40 |
| niemeyer | D) The unit agent should be using the machiner | 16:41 |
| niemeyer | fwereade: I think it'd be useful to try to isolate the conversation to one issue at a time.. if we migrate over these topics freely, it'll take some time to reach agreement | 16:41 |
| fwereade | niemeyer, yes, agreed | 16:41 |
| fwereade | niemeyer, can I start from where I think the beginning is, and perhaps we won't need to hit any or all of these | 16:41 |
| niemeyer | fwereade: +1 | 16:42 |
| fwereade | niemeyer, I have to implement subordinates | 16:42 |
| fwereade | niemeyer, in the course of considering the problem, it became apparent that there are some very noticeable similarities between principal installation and subordinate installation | 16:43 |
| fwereade | niemeyer, and that it would be helpful to consider sharing an implementation | 16:43 |
| niemeyer | fwereade: +1 | 16:43 |
| fwereade | niemeyer, I communed with the spirits, and discussed with you -- I thought -- the idea that I could try to write an Installer worker that could be run as a task by both machine agents and principal unit agents | 16:45 |
| niemeyer | fwereade: That sounds good | 16:45 |
| fwereade | niemeyer, ok; so, I have done this, and it's turned out quite nice, I think | 16:46 |
| fwereade | niemeyer, and it completely replaces the machiner's *current* duties | 16:46 |
| fwereade | niemeyer, indicating to me that the machiner package could thereby be dropped | 16:47 |
| fwereade | niemeyer, and that, having done so, a MachinerWorker constant would seem a bit silly | 16:47 |
| niemeyer | fwereade: Okay, I think that's a point of contention, and it's happening purely due to the way it's being worded | 16:47 |
| niemeyer | fwereade: You have changed the machiner so that it could be used by the unit agent | 16:48 |
| niemeyer | fwereade: It doesn't replace the machiner duties.. it implements them | 16:48 |
| niemeyer | fwereade: Thus far, we're talking about point (D) above | 16:49 |
| fwereade | niemeyer, well -- is it a *machiner* duty, or a *machine agent* duty? I had considered it the latter, but I guess yu don;t? | 16:49 |
| niemeyer | fwereade: When you talk about dropping the constant, you're talking about point (B) above | 16:49 |
| niemeyer | fwereade: A machiner.. the machine agent can happily run a provisioner and a firewaller and not run a machiner | 16:50 |
| fwereade | niemeyer, but a machiner doesn't have to have a single associated task? | 16:50 |
| niemeyer | fwereade: Can you rephrase the question please | 16:51 |
| fwereade | niemeyer, is it ok for a single Worker constant to indicate multiple tasks? | 16:52 |
| fwereade | niemeyer, it feels to me like it's a bit ...off | 16:52 |
| niemeyer | fwereade: I don't understand the context for the question | 16:52 |
| niemeyer | fwereade: I didn't suggest that | 16:52 |
| fwereade | niemeyer, ok, I have a single task which implements some of the duties of a machine agent, and also some of the duties of a principal unit agent | 16:53 |
| fwereade | niemeyer, with a unit agent, it's easy to tell: run it if we're a principal unit | 16:54 |
| fwereade | niemeyer, with a machine agent, AIUI, we consider it important that this duty be run only when it is specified | 16:54 |
| niemeyer | fwereade: Yes, our current system has the ability to run specific workers | 16:55 |
| fwereade | niemeyer, and we also want to enable/disable possible future functionality under the aegis of whether or not this machine agent is running a MachinerWorker "machiner" | 16:55 |
| niemeyer | fwereade: On the machine agent | 16:55 |
| fwereade | niemeyer, would you explain how you want this to look? I think you have enough context | 16:56 |
| fwereade | niemeyer, I would appreciate your perspective on the problem rather than trying to explain mine further, I don;t seem to be doing it very well :) | 16:56 |
| niemeyer | fwereade: No, it's not entirely clear what the question is. That system is in place today. It's working. | 16:56 |
| fwereade | niemeyer, ok, just to confirm: are you ok with the removal of worker/machiner? | 16:57 |
| niemeyer | fwereade: Certainly not as blank statement like that. It's pretty clear we're not understanding each other, so I don't know what you'd understand by that. | 16:58 |
| fwereade | niemeyer, ok | 16:58 |
| fwereade | niemeyer, I have implemented an Installer worker, which entirely eclipses the current Machiner worker's functionality | 16:58 |
| rogpeppe | fwereade: an Installer worker, or an Installer *task*? :-) | 16:59 |
| fwereade | niemeyer, if the machine agent were to run an Installer instead of a Machiner, it could continue to work as today, but with certain useful features like unit cleanup | 16:59 |
| fwereade | rogpeppe, please, what is the distinction? | 16:59 |
| niemeyer | Let's please not do that. | 17:00 |
| rogpeppe | fwereade: i'm not entirely sure | 17:00 |
| niemeyer | It doesn't matter now | 17:00 |
| niemeyer | fwereade: Right, I think that's excellent progress | 17:00 |
| niemeyer | fwereade: We just have to discuss trivial details of how to land it | 17:00 |
| fwereade | niemeyer, should it perhaps not be dignified with the term "worker", and if I call it a task we can all be happy? :) | 17:00 |
| fwereade | niemeyer, yeah, indeed | 17:00 |
| fwereade | niemeyer, I actually don;t have strong feelings, I thought I was just following logical consequences | 17:01 |
| rogpeppe | fwereade: i see it as a task that's used to implement the machiner worker. | 17:01 |
| niemeyer | fwereade: Kind of.. dropping the machiner constant wasn't a logical consequence | 17:01 |
| fwereade | niemeyer, ok; and it's one of many possible tasks that may one day eventually combine to be a Machiner? | 17:01 |
| fwereade | niemeyer, yeah, i see that | 17:02 |
| fwereade | niemeyer, I did qualify with "I thought" ;) | 17:02 |
| niemeyer | fwereade: Cool, np | 17:02 |
| niemeyer | fwereade: Let's try to find a way in | 17:02 |
| fwereade | niemeyer, ok, can we consider authorized-keys? | 17:02 |
| niemeyer | fwereade: Would be nice to call this one "UniterWorker", but we can't :) | 17:02 |
| niemeyer | fwereade: Yes please | 17:02 |
| fwereade | niemeyer, actually I'm not so sure, because principal units will need to handle that too | 17:03 |
| niemeyer | fwereade: Sorry, silly comment | 17:03 |
| niemeyer | fwereade: Please continue on the authorized-keys line | 17:03 |
| fwereade | niemeyer, can you instead think of something that is *only* done by machines? | 17:03 |
| niemeyer | fwereade: authorized-keys should be managed no matter whether we're deploying units or not | 17:04 |
| fwereade | niemeyer, or we can keep going with authkeys, because it's shared functionality just likethe Installer | 17:04 |
| niemeyer | fwereade: Machiner is misnamed, really | 17:04 |
| fwereade | niemeyer, ok, so that would be something that always ran even with no MachinerWorker? | 17:05 |
| niemeyer | fwereade: Yes, it should run | 17:05 |
| niemeyer | fwereade: Because the machine (the VM or hardware) has to remain accessible no matter what is actually running there | 17:05 |
| fwereade | niemeyer, ok; then can yu think of more possible things the machine agent can do that it might want to switch off? | 17:05 |
| rogpeppe | fwereade: the intra-machine network stack management would probably be run by the machiner only | 17:05 |
| niemeyer | Indeed | 17:06 |
| fwereade | rogpeppe, and that wouldn't need to be done if we weren't installing units, I guess? | 17:06 |
| niemeyer | Indeed, in principle (haven't thought of details) | 17:06 |
| fwereade | rogpeppe, so in that case we have 2 tasks, both of which are controlled by a single flag, MachinerWorker | 17:06 |
| niemeyer | No | 17:06 |
| rogpeppe | fwereade: sure | 17:06 |
| fwereade | niemeyer, ok, go on, how should that look?> | 17:07 |
| niemeyer | fwereade: I don't know.. I'm just saying we don't have that | 17:07 |
| niemeyer | fwereade: It could as well be within the Machiner with the current design | 17:07 |
| niemeyer | fwereade: So I'm just not agreeing upfront with something that we didn't decide upon nor considered consequences of | 17:07 |
| fwereade | niemeyer, I am really just asking how you want this to look | 17:08 |
| niemeyer | fwereade: Whatever we do, we should try to preserve the idea we currently have in place: we can run the workers we want on machines | 17:08 |
| fwereade | niemeyer, I am naturally tending towards having a list of FooerWorker flags, each of which corresponds to a Fooer task | 17:09 |
| fwereade | niemeyer, I think that is something we did consciously with provisioner and firewaller | 17:09 |
| niemeyer | fwereade: One of these workers is responsible for deploying units within their respective containers, and maintaining them across their lifecycle | 17:09 |
| niemeyer | fwereade: and machiner | 17:09 |
| fwereade | niemeyer, so, do we agree that "Machiner" is a bad name for "[a worker that] is responsible for deploying units within their respective containers, and maintaining them across their lifecycle" | 17:10 |
| fwereade | niemeyer, and that possibly "Installer" might be better? | 17:10 |
| fwereade | <fwereade> niemeyer, so, do we agree that "Machiner" is a bad name for "[a worker that] is responsible for deploying units within their respective containers, and maintaining them across their lifecycle" | 17:11 |
| fwereade | <-- niemeyer has quit (*.net *.split) | 17:11 |
| fwereade | <fwereade> niemeyer, and that possibly "Installer" might be better? | 17:11 |
| niemeyer | fwereade: Machiner is not perfectly suiting, agreed. Installer isn't great either, though. | 17:12 |
| fwereade | niemeyer, ok, can you think of a nicer name for, ideally, "[a worker that] is responsible for deploying units [in some configurable way], and maintaining them across their lifecycle" | 17:13 |
| rogpeppe | niemeyer: i thought "Deployer" was a reasonable name | 17:13 |
| fwereade | niemeyer, eg I'd be fine with Deployer, indeed | 17:13 |
| rogpeppe | niemeyer: but it overlaps with deploying services | 17:13 |
| niemeyer | fwereade: Yeah, I'm trying | 17:13 |
| fwereade | rogpeppe, and charms :) | 17:13 |
| rogpeppe | i still think it works ok | 17:13 |
| rogpeppe | it is, after all, the low level thing that's doing the deploying work for the high level deploy | 17:14 |
| fwereade | (fwiw, I suddenly think the Uniter should be called the Charmer, but it's probably best to pretend I never said that) | 17:14 |
| niemeyer | Deployer is probably the best option so far | 17:17 |
| fwereade | niemeyer, ok, cool | 17:18 |
| rogpeppe | i've just found out that i'm going to have to shut down my current juju environment because of this latest change. boo. | 17:18 |
| fwereade | niemeyer, while we're thinking names, what's the opposite of deploy? | 17:18 |
| niemeyer | I've been looking for something else, but can't come up with anything that isn't cool-sounding yet meaningless | 17:18 |
| rogpeppe | fwereade: undeploy ? | 17:18 |
| * fwereade looks pained | 17:18 | |
| rogpeppe | lol | 17:18 |
| fwereade | rogpeppe, ploy? :p | 17:18 |
| niemeyer | fwereade: destroy, at least in the juju context | 17:18 |
| rogpeppe | niemeyer: +1 | 17:19 |
| niemeyer | fwereade: Destroyer would be great.. ;-D | 17:19 |
| rogpeppe | i'll take 2 | 17:19 |
| fwereade | niemeyer, ok, so a Deployer, using Deploy/Destroy terminology | 17:20 |
| fwereade | niemeyer, and s/MachinerWorker/DeployerWorker/? | 17:21 |
| niemeyer | fwereade: Note that it depends on the context | 17:21 |
| fwereade | niemeyer, and, when I get to it also just run one as a task when running a principal unit agent | 17:21 |
| niemeyer | fwereade: We have certain actions that are well named in that context.. (dying, removing, etc) | 17:21 |
| niemeyer | fwereade: destroying is what the user requests on the command line when he wants to get rid of things, and that kicks off a series of actions | 17:21 |
| fwereade | niemeyer, it does: but one of its responsibilities is removing dead units from state | 17:21 |
| niemeyer | fwereade: Yes, *removing* | 17:21 |
| fwereade | niemeyer, ok, so destroy is not right | 17:21 |
| fwereade | niemeyer, unassignment should undeploy but not remove | 17:22 |
| niemeyer | fwereade: *unassignment*!? | 17:22 |
| niemeyer | fwereade: I hope we're not putting that on the mix right now | 17:23 |
| fwereade | niemeyer, yes... one of the branches you asked me to shepherd to completion included the machiner doing that | 17:23 |
| fwereade | niemeyer, it's not really very hard | 17:24 |
| niemeyer | fwereade: Well, I'll take your word on that.. I'm just concerned with your TODO list | 17:25 |
| niemeyer | fwereade: We don't need to name the action of undeploying I think | 17:25 |
| fwereade | niemeyer, I'm talking about something I've already done, which is part of what I understood you to have asked me to do | 17:26 |
| niemeyer | fwereade: I'd call it "removing the content of the container directory" | 17:26 |
| niemeyer | fwereade: Sorry, I was mainly referring to the watchers and to migrating the firewaller and machiner to the new watchers | 17:26 |
| niemeyer | fwereade: But I accept I was vague | 17:27 |
| fwereade | niemeyer, sorry, I thought that included the machiner work already done in those branches ;) | 17:27 |
| niemeyer | fwereade: That's cool.. you already did it, so that's brilliant. Let's not argue because you've been finishing stuff too fast. ;) | 17:27 |
| fwereade | niemeyer, ok, anyway, I can extract some branches that are not contentious in this way | 17:28 |
| niemeyer | fwereade: Your points do make me wonder if we should call these flags on AddMachine something else than "workers" | 17:28 |
| fwereade | niemeyer, +1 | 17:29 |
| niemeyer | fwereade: But at least thus far it has been nicely tangible | 17:29 |
| fwereade | niemeyer, I dunno... both machiner and uniter feel too wooly for my liking | 17:29 |
| fwereade | niemeyer, still | 17:29 |
| niemeyer | fwereade: We don't have a Uniter flag, I think | 17:30 |
| fwereade | niemeyer, depending on how sleepy my family is, I may or may not have some things for you to look at | 17:30 |
| fwereade | niemeyer, indeed so | 17:30 |
| niemeyer | fwereade: Cool | 17:30 |
| fwereade | niemeyer, but that will only be determined later tonight | 17:30 |
| niemeyer | fwereade: Thanks a lot for bringing up the discussion.. it was quite useful | 17:31 |
| fwereade | niemeyer, (I would I think in general like it if we just had one flag per task -- it would help my puny brain -- and I'm not quite clear on whether there are enough interesting groups of tasks that we should go to the effort of naming such things) | 17:32 |
| fwereade | niemeyer, (and would be interested to hear arguments against that in particular) | 17:33 |
| niemeyer | fwereade: Interesting | 17:33 |
| niemeyer | fwereade: My gut feeling goes the opposite way | 17:33 |
| niemeyer | fwereade: I'd prefer to make the flags in the machine less directly connected to code implementation on the other side | 17:33 |
| fwereade | niemeyer, strawman: firewaller/provisioner? | 17:33 |
| niemeyer | fwereade: and more like actual flags | 17:33 |
| fwereade | niemeyer, I'd be fine with that too | 17:34 |
| niemeyer | fwereade: Because I anticipate one day we'll want to tweak the behavior of a machine without a direct connection to code | 17:34 |
| fwereade | niemeyer, ok, I can understand that | 17:34 |
| fwereade | niemeyer, I think I'm done blethering on for a bit | 17:35 |
| fwereade | niemeyer, I'll steer clear of big renames and just get you a Deployer to look at | 17:35 |
| fwereade | later all | 17:35 |
| niemeyer | fwereade: If we find a nice alternative, I'd actually be happy to bundle the flag rename change with it | 17:36 |
| niemeyer | fwereade: But let's keep that for the review perhaps, so we have something more tangible to discuss on top of | 17:36 |
| rogpeppe | niemeyer: i'm wondering if we should bump the major version number, just for the principle of it | 17:51 |
| niemeyer | rogpeppe: I'd rather not end up with version 10 of juju so soon :) | 18:07 |
| rogpeppe | niemeyer: i don't see why not, really. | 18:07 |
| rogpeppe | niemeyer: semantic versions shouldn't be about getting attached to particular numbers, really. | 18:07 |
| niemeyer | rogpeppe: In reality, we really don't want to be breaking major versions all the time | 18:09 |
| rogpeppe | niemeyer: definitely. | 18:09 |
| rogpeppe | niemeyer: but this is one such change | 18:09 |
| rogpeppe | niemeyer: still, i don't mind much. | 18:10 |
| rogpeppe | niemeyer: i should probably say something in juju-dev though | 18:10 |
| rogpeppe | niemeyer: or perhaps we leave that for the release notes | 18:10 |
| niemeyer | rogpeppe: I do mind.. this is exceptional, and I'm fine with handling it as an exception.. I'm not fine with major breakage every other week | 18:11 |
| rogpeppe | niemeyer: agreed. i'm not really sure why it's an exception as far as the major version number goes though. | 18:12 |
| niemeyer | rogpeppe: It's an exception because we're still in heavy development mode | 18:12 |
| rogpeppe | niemeyer: it would still be nice if people could rely on our version numbering, even in this mode. | 18:13 |
| rogpeppe | niemeyer: and it wouldn't be a bad thing if the major version number did actually count the number of breaking changes we've made since the initial release. | 18:15 |
| niemeyer | rogpeppe: Major breakage is bad.. it's not fine to do it all the time. I don't want to paint a picture that makes it feel like it's alright. | 18:17 |
| niemeyer | rogpeppe: Not to users, and not even to ourselves. | 18:17 |
| rogpeppe | niemeyer: absolutely. so we should take the hit and increment the major version number for this occasion, signifying that it's a significant thing, IMHO | 18:17 |
| niemeyer | rogpeppe: It's *not* ok to be doing it every week. | 18:17 |
| niemeyer | rogpeppe: and next week too? and in the following one too? | 18:18 |
| rogpeppe | niemeyer: if we break things in a major way, yes | 18:18 |
| rogpeppe | niemeyer: 'cos as you said, that's not ok | 18:18 |
| rogpeppe | niemeyer: so it should be rare | 18:18 |
| niemeyer | rogpeppe: No, that's exceptional because we're in heavy development mode, releasing alpha releases | 18:19 |
| niemeyer | rogpeppe: and not promising compatibility | 18:19 |
| niemeyer | rogpeppe: Let's focus on finishing the stuff due for that, and then we start respecting the version | 18:19 |
| rogpeppe | niemeyer: i agree. but our version numbers should reflect the compatibility of each release, i think. that's why we have them, no? | 18:19 |
| niemeyer | rogpeppe: I already responded to that above | 18:20 |
| rogpeppe | niemeyer: i think that if we say we do semantic versions, we should do them. i don't see that an aversion to the number 10 is a good reason not to. | 18:21 |
| rogpeppe | niemeyer: and it makes it obvious to anyone that *is* actually using our alpha versions when we are making a breaking change. | 18:22 |
| niemeyer | rogpeppe: Agreed. I already said we're not respecting the version right now at UDS. | 18:22 |
| niemeyer | rogpeppe: So we're good there. | 18:22 |
| rogpeppe | niemeyer: ok. it would be very easy to do so though. | 18:22 |
| niemeyer | rogpeppe: The mood of a team that cares about breakage is a different one. We're not there yet. | 18:23 |
| rogpeppe | niemeyer: ok, so it is ok to break things every week at the moment? | 18:23 |
| niemeyer | rogpeppe: That's what has been happening so far pretty much. You've just landed a change that does, and we've just discussed something like 5 other braking changes in the last couple of hours. | 18:23 |
| niemeyer | breaking | 18:24 |
| rogpeppe | niemeyer: part of the reason for discussing them was that it might be nice to bundle the two together to reduce the overall breakage count. | 18:24 |
| niemeyer | rogpeppe: It would be nicer if we can not spend time managing three different forks, and instead focus on landing them and stabilizing the project. | 18:25 |
| rogpeppe | niemeyer: ok | 18:25 |
| rogpeppe | niemeyer: thanks for the discussion. time for me to stop now. | 18:34 |
| rogpeppe | niemeyer: have a good rest-of-day | 18:35 |
| niemeyer | rogpeppe: np, have a good evening | 18:35 |
| niemeyer | rogpeppe: Cheers | 18:35 |
| rogpeppe | g'night all | 18:35 |
| niemeyer | rogpeppe: Think about Go, since you're usually inspired there, btw. | 18:38 |
| niemeyer | Argh.. someone stole my usual bucket name :) | 18:58 |
| fwereade | rogpeppe, I seem to have a lot of tests hanging in trunk, it's not immediately apparent where but I'd imagine it's to do with state connections -- is there anything I should be sure to have a particular version of? | 19:15 |
| niemeyer | fwereade: I was just having a few issues too using it for real, but I suspect my own network was flaky | 19:47 |
| fss | niemeyer: ping | 20:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!