| davecheney | hey hey | 05:46 |
|---|---|---|
| davecheney | the good news, juju can now bootstrap from quantal to precise | 05:46 |
| davecheney | the bad news, do-release-upgrade on my precise system totally hosed it :( | 05:46 |
| fwereade | davecheney, heyhey | 07:07 |
| davecheney | fwereade: hey | 07:08 |
| fwereade | davecheney, reviewed one, with unhelpful whining about tests, I'm afraid | 07:09 |
| davecheney | understood | 07:09 |
| davecheney | it is a non trivial amount of work to add 409 response behavior to s3test | 07:09 |
| davecheney | i'll man up and do it | 07:09 |
| fwereade | davecheney, on the other, trying to figure out what the deal is with the arch change in cloudinit_test | 07:10 |
| fwereade | davecheney, thanks very much :) | 07:11 |
| fwereade | davecheney, I expect it makes sense somehow, but I just cannot figure out where that i386 came from | 07:11 |
| davecheney | fwereade: i386 is just to double check that cloudinit isn't amd64 only | 07:14 |
| fwereade | davecheney, I just can't see what change caused it to use i386 where once it used amd64 | 07:15 |
| davecheney | fwereade: i can remove the i386 thing if it is confusing | 07:15 |
| davecheney | it isn't testing anything important | 07:15 |
| fwereade | davecheney, sorry, I have just come to realise I am being stupid | 07:16 |
| fwereade | davecheney, so that one basically LGTM -- but the description should be fixed if it is now actually intended for submission ;) | 07:17 |
| davecheney | fwereade: cool | 07:18 |
| davecheney | that is the one i really care about | 07:18 |
| davecheney | as i upgraded to quantal today (twice) | 07:19 |
| fwereade | davecheney, ah, cool | 07:21 |
| fwereade | davecheney, you have an LGTM with one nitpick | 07:21 |
| fwereade | bbiab | 07:23 |
| rogpeppe | fwereade: hiya | 07:47 |
| fwereade | rogpeppe, heyhey | 08:09 |
| TheMue | morning | 08:13 |
| rogpeppe | TheMue: hi | 08:39 |
| TheMue | rogpeppe: hiya | 08:40 |
| rogpeppe | fwereade: what's our current position on watchers returning updates for any changes, not just lifecycle? (i'm looking at MachinePrincipalUnitsWatcher here) | 08:40 |
| rogpeppe | fwereade: it seems a bit silly that when we're told about a unit changing, we fetch its unit doc twice. ISTM that hardly any logic in the client (worker/machiner) would have to change, and we could get rid of a big chink of logic in the watcher | 08:43 |
| TheMue | rogpeppe: I like the idea of getting notified on any change, but I then like to get the watched entitiy (not only the id) and a useful information what has changed (e.g. the lifecycle state) | 08:45 |
| fwereade | rogpeppe, I am still undecided tbh | 08:46 |
| rogpeppe | TheMue: from what i see of the clients, they don't make that much use of that info. | 08:46 |
| fwereade | rogpeppe, the trouble is that different use cases are different and I think that both behaviours are wanted in different places | 08:47 |
| TheMue | rogpeppe: The old added/removed separation has been more helpful than today iterating over ids, retrieve the state and compare it. | 08:47 |
| rogpeppe | fwereade: if we're just sending ids, then i think it makes sense that the client is responsible for doing the refresh and doing the diffs itself | 08:47 |
| rogpeppe | TheMue: i agree, but since we've moved away from that, i think it makes sense to take advantage of that | 08:48 |
| fwereade | rogpeppe, this is true, up to a point -- let me read some code a mo | 08:48 |
| rogpeppe | TheMue: there's no need for both the watcher *and* the client to be independently fetching the doc | 08:48 |
| TheMue | rogpeppe: That's true | 08:48 |
| fwereade | rogpeppe, I consider it to be a good thing, though, that the ServiceRelationsWatcher filters out irrelevant changes and only tells me about life changes | 08:50 |
| rogpeppe | fwereade: how much would your logic need to change if it told you about other changes too? | 08:50 |
| fwereade | rogpeppe, it could be more efficient -- it only needs to grab 2 fields to do the comparison -- but I think we need to consider the HTTP API here | 08:50 |
| rogpeppe | fwereade: after all, you need to fetch the doc to find out exactly *what* has changed | 08:51 |
| fwereade | rogpeppe, I think it *is* worth getting the document twice, because once the watcher is implemented behind the API, right next to the state, it is cheap for it to get a document | 08:51 |
| fwereade | rogpeppe, and by doing so it can send fewer updates to remote clients on the other side of the API | 08:52 |
| fwereade | rogpeppe, and those clients, for whom getting a document is expensive, don't have to repeatedly get and inspect the documents to do their own filtering | 08:52 |
| fwereade | rogpeppe, sane? | 08:53 |
| rogpeppe | fwereade: hmm | 08:53 |
| rogpeppe | fwereade: that's a reasonable point | 08:55 |
| rogpeppe | fwereade: o | 08:57 |
| rogpeppe | fwereade: darn, i thought we could get rid of large chunks of code | 08:57 |
| fwereade | rogpeppe, annoying, innit ;) | 09:04 |
| * rogpeppe grumbles | 09:05 | |
| fwereade | rogpeppe, TheMue: so, given that, I think the answer really is annoyingly situational | 09:05 |
| fwereade | rogpeppe, TheMue: for the firewaller, it's perfect to get life and ports changes only | 09:05 |
| fwereade | rogpeppe, service relations we want life only | 09:06 |
| fwereade | rogpeppe, TheMue: again, for the (?)deployer and/or machiner, life changes only | 09:06 |
| rogpeppe | fwereade: i'm happy with that now. | 09:07 |
| fwereade | rogpeppe, cool, sorry :) | 09:07 |
| TheMue | :D | 09:07 |
| === mcclurmc_away is now known as mcclurmc | ||
| Aram | morning. | 10:29 |
| TheMue | Aram: hi | 10:32 |
| rogpeppe | Aram: you've got a couple of reviews | 10:41 |
| rogpeppe | Aram, fwereade: what's the story regarding https://codereview.appspot.com/6811091 vs https://codereview.appspot.com/6820112 ? | 10:41 |
| rogpeppe | looks like there are quite a few conflicts there | 10:42 |
| Aram | rogpeppe: unfortunate duplication of effort | 10:42 |
| rogpeppe | Aram: well, yours does more, as it uses WatchUnits rather than WatchPrincipalUnits. maybe fwereade's should go in first. | 10:44 |
| rogpeppe | hmm, looks like my gmail account has been hacked | 11:06 |
| TheMue | rogpeppe: Yesterday there also has been a strange twitter message by you. | 11:07 |
| rogpeppe | TheMue: yeah, that was hacked too. seems a bit strange - they both had different passwords | 11:07 |
| rogpeppe | TheMue: although, to be fair, both passwords were terribly weak | 11:07 |
| TheMue | rogpeppe: OK, so maybe just brute force. | 11:08 |
| rogpeppe | TheMue: i think so | 11:08 |
| TheMue | rogpeppe: I like the xkcd, where long curious sentences are better than "P4ssw0rd". ;) | 11:09 |
| rogpeppe | TheMue: yeah, that's the approach i'm using | 11:09 |
| rogpeppe | TheMue: with a couple of weird chars thrown in for good measure | 11:10 |
| TheMue | rogpeppe: I've changed it and now have stupid sentences. | 11:10 |
| TheMue | rogpeppe: But today I had to set one with 8 to 15 chars and no specia characters. Why those constraints? *sigh* | 11:12 |
| rogpeppe | TheMue: yeah, that's outrageous. don't they know that you can run sha1 in javascript? :-) | 11:12 |
| TheMue | rogpeppe: Yep ;) | 11:13 |
| rogpeppe | interesting to see the spam machine in action | 11:24 |
| rogpeppe | none of the sent messages addressed more than 5 recipients | 11:24 |
| rogpeppe | and they all sent a different link | 11:25 |
| TheMue | rogpeppe: Yeah, they do their best to not being catched by spamassassin or postgrey. | 11:27 |
| rogpeppe | they got as far as "j" in my address book | 11:29 |
| rogpeppe | 65 spam messages sent in total | 11:30 |
| === dimitern is now known as dimitern_lunch | ||
| rogpeppe | fwereade: ping | 12:38 |
| Aram | rogpeppe: I want acme integration with codereview. | 12:44 |
| rogpeppe | Aram: how would you want it to work? | 12:45 |
| Aram | rogpeppe: somewhat like mail. | 12:46 |
| Aram | in fact even using that with the email you get now from codereview is almost usable, aparte from the fact that you can't reply. | 12:46 |
| rogpeppe | Aram: do you still use acme mail? | 12:47 |
| Aram | no. | 12:47 |
| rogpeppe | Aram: i used it for years actually, but the lack of threading finally got to me | 12:47 |
| rogpeppe | Aram: and the benefits aren't so great if you're not running under plan 9 | 12:48 |
| Aram | yeah... | 12:48 |
| fwereade | rogpeppe, deferred pong | 12:48 |
| fwereade | rogpeppe, I have to pop out for a while and will be somewhat spottily around this afternoon and evening | 12:48 |
| Aram | acme mail is not so useful at this point anymore, but I think for specialized things, an acme mail thing would be useful. | 12:48 |
| fwereade | rogpeppe, I will grab you this pm though | 12:48 |
| rogpeppe | fwereade: ok. sometime i'd like a chat about some new attributes in config | 12:48 |
| rogpeppe | fwereade: but i think i've decided on a reasonable approach actually | 12:49 |
| fwereade | rogpeppe, cool -- I look forward to seeing it :) | 12:49 |
| fwereade | tytyl | 12:49 |
| rogpeppe | fwereade: have fun | 12:49 |
| rogpeppe | Aram: go for it; i'd like to see what you come up with. | 12:50 |
| === dimitern_lunch is now known as dimitern | ||
| === flaviamissi is now known as flaviamissi_ | ||
| === TheMue_ is now known as TheMue | ||
| === flaviamissi_ is now known as flaviamissi | ||
| rogpeppe | fwereade: i'll just run the config stuff by you to check for crackfullness, if that's ok | 15:13 |
| fwereade | rogpeppe, sgtm | 15:13 |
| rogpeppe | fwereade: so, we want to be able to specify a root CA when bootstrapping and when connecting to an environment | 15:14 |
| fwereade | rogpeppe, ok | 15:14 |
| rogpeppe | fwereade: when bootstrapping we'll need the private key too, so we can sign a new key/cert pair and hand it off to the first instance | 15:15 |
| rogpeppe | fwereade: so my thought is to add three new attributes to config | 15:15 |
| rogpeppe | fwereade: root-cert-path, root-cert and root-private-key | 15:15 |
| rogpeppe | fwereade: root-cert-path acts a little like authorized-keys-path | 15:15 |
| rogpeppe | fwereade: that is, if it's set, the cert/key pair is read from that file; otherwise if root-cert isn't set in config, we'll try to read from ~/.juju/rootcert.pem | 15:16 |
| fwereade | rogpeppe, yep, that makes sense | 15:17 |
| rogpeppe | fwereade: we verify that the cert parses and that, if given, the key matches the cert. | 15:17 |
| rogpeppe | fwereade: which prevents going a long way down the road with a bogus cert/key pair | 15:18 |
| fwereade | rogpeppe, ok, yep | 15:18 |
| rogpeppe | fwereade: i think that's it, for the time being | 15:18 |
| rogpeppe | fwereade: i'm just doing the tests | 15:19 |
| rogpeppe | fwereade: it's a pity that it's yet one more step to getting a juju up and running | 15:19 |
| rogpeppe | fwereade: i wonder if we might have a juju helper that prompts for the necessary information and does everything else necessary (e.g. generating the key, generating an admin secret, etc) and writes an environments.yaml file. | 15:20 |
| fwereade | rogpeppe, just one of many, really, we'll get there :) | 15:21 |
| fwereade | rogpeppe, yeah, new-user experience would be very much helped by that | 15:21 |
| rogpeppe | fwereade: juju new-environment ? | 15:22 |
| rogpeppe | fwereade: i'm not sure that we can rewrite environments.yaml losslessly though, sadly | 15:22 |
| fwereade | rogpeppe, I'm pretty sure we can't | 15:22 |
| rogpeppe | fwereade: me too. +1 to json :-) | 15:23 |
| rogpeppe | fwereade: actually, maybe it could just spit out an environments.yaml to stdout | 15:23 |
| rogpeppe | fwereade: anyway, that's way down the line. | 15:23 |
| rogpeppe | fwereade: if all that SGTY, i'll carry on | 15:23 |
| fwereade | rogpeppe, I *think* it does | 15:24 |
| fwereade | rogpeppe, I am not sure how to handle changing the root cert | 15:24 |
| fwereade | rogpeppe, or in general how to (or whether we should) change any of those new fields | 15:24 |
| fwereade | rogpeppe, (I guess root-cert-path is not really a setting, at least, just a sort of input filter) | 15:25 |
| rogpeppe | fwereade: yeah, changing the root cert is hard | 15:25 |
| rogpeppe | fwereade: and what about certificate revocation | 15:25 |
| rogpeppe | ? | 15:25 |
| fwereade | rogpeppe, quite so | 15:26 |
| fwereade | rogpeppe, I guess it would be worth trying to think a little way through those questions to ensure we're not closing any future doors, even if we don't support anything like that at this stage | 15:27 |
| rogpeppe | fwereade: tbh, i think that both with changing the root cert and revocation, what we're building now is a necessary prerequisite. we are always going to need to pass at least one certificate into the cloud. | 15:30 |
| fwereade | rogpeppe, that does sound solid to me | 15:31 |
| rogpeppe | fwereade: revocation, i think happens automatically, as long as clients are checking revocation lists appropriately. | 15:31 |
| rogpeppe | fwereade: changing the root cert we'd probably do by leveraging the existing root cert to produce another cert. you'd probably do it by using a level of indirection and revoking the original certificate but not the original *root* certificate (he says, hand-waving wildly) | 15:33 |
| fwereade | rogpeppe, I think that's outside the realm of things I can claim to have a reasoned opinion on ;) | 15:35 |
| fwereade | rogpeppe, incidentally, I was wondering something related... ISTM that the user is already adequately identified with the authorized key, and I'm suddenly unsure what we get out of admin-secret... what am I missing? | 15:52 |
| Aram | rogpeppe: significantly refined version https://codereview.appspot.com/6820112/ , when you have time | 15:53 |
| rogpeppe | fwereade: that may well be true in the future. for the time being, i don't know of a way to get mongodb do client authentication | 15:54 |
| fwereade | rogpeppe, ok, cool, so it's purely for admin auth with mongo? | 15:55 |
| rogpeppe | fwereade: yes, i *think* so | 15:55 |
| rogpeppe | Aram: looking | 15:56 |
| Aram | rogpeppe: also https://codereview.appspot.com/6814108/ | 16:50 |
| rogpeppe | Aram: sorry, i got some way through, then realised i really wanted to propose my CL by the end of the day... | 16:51 |
| Aram | rogpeppe: don't worry, I'm only pinging you, I don't expect reviews right away. | 16:51 |
| rogpeppe | Aram: that's find. just letting you know in case you expected one after my "looking" | 16:52 |
| rogpeppe | s/find/fine/ | 16:52 |
| rogpeppe | fwereade: ping | 18:03 |
| fwereade | rogpeppe, pong | 18:03 |
| rogpeppe | fwereade: i've just realised, i think, that i'm slightly askew in my assumptions | 18:03 |
| fwereade | rogpeppe, oh yes? | 18:03 |
| === mcclurmc is now known as mcclurmc_away | ||
| rogpeppe | fwereade: i've been assuming that it's mandatory to have a root certificate | 18:04 |
| rogpeppe | fwereade: but actually, i think we perhaps want the capability to connect to a server without checking | 18:04 |
| fwereade | rogpeppe, expand please | 18:04 |
| fwereade | rogpeppe, naively it seems like a good idea | 18:04 |
| rogpeppe | fwereade: well, say we have a juju environment but we've lost the root cert key | 18:05 |
| rogpeppe | fwereade: the checking that juju does is, i think, something that should be a choice (the default choice) | 18:05 |
| rogpeppe | fwereade: 'cos otherwise we can't connect | 18:05 |
| rogpeppe | fwereade: a bit like the way ssh automatically adds a key if you ask for it | 18:06 |
| fwereade | rogpeppe, I kinda favour just advising people that "keys are important; don't lose them" | 18:06 |
| rogpeppe | fwereade: i was just wondering if i really want the root cert to be mandatory in config | 18:07 |
| rogpeppe | fwereade: (i've just spent the last while putting it everywhere...) | 18:07 |
| fwereade | rogpeppe, ha, yeah, it is usually at such junctures that I start to question things | 18:08 |
| fwereade | rogpeppe, hmm | 18:08 |
| fwereade | rogpeppe, honestly I don;t know what is really meant by "everywhere" so it is hard for me to follow intuitively | 18:08 |
| rogpeppe | fwereade: i got to environs/ec2, and realised that it uses your actual authorized keys, so i'm wondering whether we want to the same approach for root cert, or if we should generate one on the fly | 18:09 |
| rogpeppe | fwereade: everywhere we've got a set of attributes for a config | 18:09 |
| rogpeppe | fwereade: pretty much everywhere we've got an authorized-keys attribute now | 18:09 |
| rogpeppe | fwereade: i'm thinking that it might be fine just to hard-code a root cert for testing. | 18:10 |
| rogpeppe | fwereade: there's another thing which is a source of discomfort currently | 18:11 |
| rogpeppe | fwereade: which is that the cert and key are specified in a single file, but they get two attributes in the config. | 18:12 |
| fwereade | rogpeppe, yeah, that definitely seems wrong | 18:12 |
| fwereade | rogpeppe, except hmm | 18:12 |
| fwereade | rogpeppe, maybe not | 18:13 |
| rogpeppe | fwereade: there are +s and -s | 18:13 |
| fwereade | rogpeppe, but, yeah, it doesn't sit quite right | 18:13 |
| rogpeppe | fwereade: i was trying to avoid having *two* more path attributes in the config. | 18:13 |
| fwereade | rogpeppe, hmm, just a mo | 18:13 |
| rogpeppe | fwereade: but perhaps that makes more sense in fact; keep them separate at all times. | 18:14 |
| fwereade | rogpeppe, if that is as convenient that sgtm | 18:14 |
| rogpeppe | fwereade: it's not convenient at the moment - i'd have to rewrite some code and lots of tests :-) | 18:15 |
| fwereade | rogpeppe, ha, indeed | 18:15 |
| rogpeppe | fwereade: but on balance, i think it's probably a better approach | 18:16 |
| rogpeppe | fwereade: bugger | 18:16 |
| * fwereade sympathises | 18:16 | |
| fwereade | rogpeppe, a strawmanny thought | 18:20 |
| * rogpeppe gets out the wooden axe | 18:21 | |
| fwereade | rogpeppe, how would it be if the administrator who created the environment were to have keys and certificates automatically generated and stored in ~/.juju/environments/<name>? | 18:22 |
| fwereade | rogpeppe, they could of course be overridden by config settings | 18:22 |
| rogpeppe | fwereade: i think that's a reasonable thought, and i've thought about something similar myself | 18:23 |
| rogpeppe | fwereade: but i think it's orthogonal to what i'm doing currently | 18:23 |
| rogpeppe | fwereade: which enables that, trivially | 18:24 |
| fwereade | rogpeppe, agreed... maybe a suggestion for the lists, see if it draws popular support, if it does it should indeed be easy to build on top | 18:24 |
| rogpeppe | fwereade: yeah. actually, i don't think there needs to be a key per environment | 18:25 |
| rogpeppe | fwereade: i think one root key for all environments is just fine | 18:25 |
| rogpeppe | fwereade: so the command line tool could generate ~/.juju/rootcert.pem if it doesn't already exist | 18:26 |
| fwereade | rogpeppe, I dunno, I think one per environment is saner in a multi-admin situation | 18:27 |
| fwereade | rogpeppe, but I don't feel very strongly about it, haven't really thought it through | 18:27 |
| rogpeppe | fwereade: if you want one per environment, that's easy to do. but a single name space also makes sense, i think. | 18:27 |
| rogpeppe | fwereade: it means there's only one public key to distribute, for one | 18:28 |
| fwereade | rogpeppe, yeah, also sounds reasonable :) | 18:28 |
| rogpeppe | right, i can't launch into changing all this now; time to stop for the night, i think. | 18:30 |
| rogpeppe | a pint beckons | 18:30 |
| rogpeppe | fwereade: have a great weekend, see ya monday | 18:31 |
| rogpeppe | night all | 18:31 |
| fwereade | rogpeppe, have fun :) | 18:31 |
| === mcclurmc_away is now known as mcclurmc | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!