| rogpeppe | davecheney, fwereade_, dimitern: morning all | 07:18 |
|---|---|---|
| dimitern | rogpeppe: hiya :) | 07:18 |
| TheMue | morning | 07:30 |
| rogpeppe | TheMue: yo! | 07:31 |
| TheMue | rogpeppe: hi | 07:32 |
| TheMue | rogpeppe: Today next round in your fight connecting MongoDB via SSL? | 07:33 |
| rogpeppe | TheMue: no, i got that working last week | 07:33 |
| rogpeppe | TheMue: (in a piece of example code, anyway) | 07:33 |
| TheMue | rogpeppe: Ah, ok, then I misinterpreted your answer to Dave. | 07:34 |
| dimitern | anybody has a handy link on how to write table-based tests for go? | 08:07 |
| dimitern | I can't seem to find it, and I'm sure there was one somewhere.. | 08:07 |
| TheMue | dimitern: We're using them in some of our tests. I'll look for an example. | 08:20 |
| TheMue | dimitern: Hi btw. | 08:20 |
| dimitern | TheMue: hi :) 10x! | 08:20 |
| TheMue | dimitern: Take a look at state/state_test.go, line 235ff. | 08:26 |
| TheMue | dimitern: There's a var inferEndpointsTests defined as slice of unnamed structs. | 08:27 |
| TheMue | dimitern: The fields of those structs depend on your needed in- and outputs (to compare) or expected errors (have to be tested too). | 08:28 |
| TheMue | dimitern: It directly follows a number of struct values. | 08:29 |
| dimitern | TheMue: I see! 10x again, I'll use it as a reference | 08:29 |
| TheMue | dimitern: In TestInferEndpoints in line 378 you loop over the slice and perform actions and asserts depending on those table/slice values. | 08:30 |
| TheMue | dimitern: Cheers, it's a nice technique to cover a large number of different tests of the same kind. | 08:31 |
| dimitern | TheMue: interesting pattern - I see how expressive the table is - you can see every test at one place | 08:31 |
| TheMue | dimitern: Exactly. Doing it manually would need by far more code and is not so good readable. | 08:32 |
| rogpeppe | fwereade_: i'm seeing a uniter test failure in trunk: http://paste.ubuntu.com/1355121/ | 09:15 |
| fwereade_ | rogpeppe, oh hell (takes a look) | 09:16 |
| fwereade_ | rogpeppe, hm, I *think* I have a branch that addresses that somewhere -- anyway ty | 09:17 |
| rogpeppe | fwereade_: np | 09:17 |
| rogpeppe | fwereade_: it's failing consistently for me, BTW, but not always in the same test. | 09:18 |
| TheMue | Aram: Moin | 09:52 |
| Aram | hello. | 09:52 |
| rogpeppe | fwereade_: a fairly simple change: https://codereview.appspot.com/6849044/ | 09:56 |
| TheMue | Aram: We should talk about the container abstraction this morning. I don't think I've got the full picture, but as far as you (and fwereade_ ) talked about it I like the abstraction. | 10:00 |
| fwereade_ | rogpeppe, LGTM | 10:04 |
| rogpeppe | fwereade_: thanks | 10:04 |
| rogpeppe | fwereade_: i've been meaning to get around to that for ages, and finally found a place where it made things easier | 10:05 |
| fwereade_ | rogpeppe, yeah, it's much nicer | 10:05 |
| fwereade_ | Aram, TheMue: re container abstraction, do you have anything resembling niemeyer-approval? that is my main concern | 10:06 |
| TheMue | fwereade_: Could you please rephrase it? | 10:07 |
| fwereade_ | Aram, TheMue: I have a suspicion that it may be more expedient to proceed without introducing an abstraction niemeyer does not approve of, and then to propose a CL that demonstrably reduces complexity later | 10:08 |
| Aram | fwereade_: I believe it would significantly reduce complexity even now, especially for watchers. | 10:08 |
| fwereade_ | Aram, TheMue: I like the idea but not enough to feel I have the resources for a protracted battle over it | 10:08 |
| fwereade_ | Aram, if you think you can make a compelling case in code then that definitely changes the situation for the better :) | 10:09 |
| TheMue | fwereade_: Currently I want to know the advantages and disadvantages of a changed approach to see, if it's worth a change. Absolutely neutral. | 10:09 |
| TheMue | fwereade_: And Arams ideas sound reasonable to me so far. | 10:10 |
| TheMue | fwereade_: We made a first little analysis, where code has to be changed. | 10:11 |
| TheMue | Ah, split is over. | 10:17 |
| rogpeppe | anyone else want to have a look at this? i think it's simple enough that I'll submit after two LGTMs: https://codereview.appspot.com/6849044/ | 10:20 |
| TheMue | rogpeppe: *click* | 10:22 |
| TheMue | rogpeppe: LGTM, with +1 for fwereade_s comment | 10:33 |
| Aram | davecheney: you have another review | 10:33 |
| davecheney | Aram: ty | 10:34 |
| rogpeppe | TheMue: thanks. | 10:39 |
| Aram | reboot | 10:39 |
| Aram | I hate the damn vmware. | 10:41 |
| Aram | I wish virtualbox didn't suck. | 10:41 |
| TheMue | Aram: What concrete problem you have with vmware? | 10:44 |
| Aram | It just rewrote my routing table on my host | 10:45 |
| TheMue | Iiirks | 10:45 |
| Aram | and the GUI is so, so, sloow. | 10:46 |
| Aram | and the updater never works. | 10:47 |
| TheMue | Aram: Here I thankfully have no problems. Yesterday I had an update. But I don't know how far the Win and the OS X versions differ. | 10:49 |
| Aram | the windows interface was rewritten in C#. | 10:50 |
| Aram | everything went down since then. | 10:50 |
| TheMue | Aram: Doesn't Parallels also exist for Win? | 10:56 |
| Aram | no. | 10:56 |
| TheMue | Aram: Could you please open the LXC document? So here we both can collect the pros and cons of the container abstraction and also add a first effort estimation. | 11:03 |
| Aram | TheMue: after I'me done with breakfast, in the meantime please share the link | 11:05 |
| TheMue | Aram: OK, here it is https://docs.google.com/a/canonical.com/document/d/1Chla4FgaMTlwXFdAzFv-ToN0iNsWKFECNGOCerC8PH0/edit | 11:05 |
| niemeyer | Hello all | 11:37 |
| TheMue | niemeyer: Hiya | 11:37 |
| niemeyer | Why did we switch the meeting time by 2h today? | 11:37 |
| niemeyer | Well, 1h.. | 11:37 |
| TheMue | niemeyer: Oh, did we? | 11:38 |
| TheMue | niemeyer: I have it here as the same time as always. But DST is over, so maybe there's the reason for a movement. | 11:39 |
| TheMue | s/as the/at the/ | 11:39 |
| niemeyer | TheMue: Yep, but hemispheres shift DST in a different direction, so what is "same time" there is 2h off here | 11:39 |
| niemeyer | It's great for me, but it's probably not nice for davecheney | 11:39 |
| TheMue | niemeyer: Iirks, yep, it's 10:40 there now. | 11:40 |
| TheMue | niemeyer: But also 6:40 right now for Mark. We have a wide span right now. | 11:41 |
| niemeyer | Yep | 11:41 |
| jam | niemeyer: is there a reason that "go test -gocheck.v ./..." and "go test ./... -gocheck.v" do different things? | 11:43 |
| jam | (the former runs the current package's tests in verbose mode, and the latter runs all the tests in all subdirectories but without verbose mode) | 11:44 |
| niemeyer | jam: Probably a bug in go test | 11:46 |
| niemeyer | jam: Without looking, I'd guess that they're making a decision based on number of flags seen, without considering foreign flags | 11:46 |
| Aram | so, when is the meeting? | 11:59 |
| Aram | now? | 11:59 |
| jam | nowish | 11:59 |
| mramm | So, meeting is now | 11:59 |
| jam | 10 | 11:59 |
| mramm | for those who have not been to a meeting before -- can you send me your G+ info | 11:59 |
| davecheney | invite anyone ? | 11:59 |
| jam | 9 | 11:59 |
| jam | 8 | 11:59 |
| mramm | so I can add you to the invite | 11:59 |
| jam | too fast... :) | 11:59 |
| jam | mramm: john.meinel@canonical.com is fine | 12:00 |
| dimitern | dimiter.naydenov@canonical.com | 12:00 |
| jam | mramm: I imagine martin.packman@canonical.com as well | 12:00 |
| mgz | right. | 12:00 |
| mramm | https://plus.google.com/hangouts/_/50b626916b5f85ebad8bc80dde5052b14aa7a6d7?authuser=0&hl=en-GB | 12:01 |
| jam | dimitern: ^^ | 12:02 |
| mramm | everybody should be invited now | 12:02 |
| jam | mgz: ^^ | 12:02 |
| mgz | ...hangout is very unhappy | 12:06 |
| mgz | I think I need to not join last, too much junk being done that I can't disable | 12:07 |
| mgz | ...and now the room is full, probably with a ghost of me | 12:08 |
| mgz | should have just used machine downstairs | 12:09 |
| jam | mgz: I'm guessing you can join downstairs still. I tried to paste the URL to w7z | 12:10 |
| mgz | ta, will do that | 12:10 |
| TheMue | See http://bazaar.launchpad.net/~themue/+junk/golxc/files for the LXC code. | 12:12 |
| niemeyer | curl, err := charm.InferURL(c.CharmName, conf.DefaultSeries()) | 12:32 |
| niemeyer | jam: Good news re. Ian | 12:41 |
| dimitern | yeah :) | 12:41 |
| jam | niemeyer: thanks, it should good having him around. | 12:41 |
| niemeyer | jam: Will be nice to have more people close to davecheney too | 12:41 |
| jam | dimitern, mgz: I was trying to mention it to you on mumble, but mgz never joined :) | 12:41 |
| dimitern | jam: I see, so it's confirmed | 12:42 |
| jam | dimitern: yeah | 12:42 |
| fwereade_ | gents, since I appear not to be currently blocking anyone, I'm off to pick up laura from school | 12:45 |
| Aram | fwereade_: cheers. | 12:45 |
| jam | fwereade_: have a good evening. | 12:46 |
| TheMue | fwereade_: Enjoy, mine are coming on there own (or are out of school already). ;) | 12:49 |
| TheMue | Aram: I added some first points about the container abstraction to the doc, but you surely have more. | 12:50 |
| Aram | TheMue: would you be so kind to share the link with me again? | 12:50 |
| Aram | I lost it | 12:50 |
| TheMue | Aram: Sure, np, here: https://docs.google.com/a/canonical.com/document/d/1Chla4FgaMTlwXFdAzFv-ToN0iNsWKFECNGOCerC8PH0/edit | 12:51 |
| Aram | thanks | 12:51 |
| === fss is now known as offline | ||
| === offline is now known as fss | ||
| TheMue | lunchtime | 13:02 |
| rogpeppe | fwereade_, TheMue: i didn't quite get it right last time... https://codereview.appspot.com/6851043 | 13:06 |
| * rogpeppe goes for lunch | 13:19 | |
| niemeyer | rogpeppe: Enjoy | 13:25 |
| Aram | TheMue: tell me when you're back. | 13:32 |
| fss | niemeyer: hi :-) | 13:43 |
| fss | niemeyer: could you take a look at that CL? | 13:44 |
| fss | niemeyer: https://codereview.appspot.com/6823060/ | 13:44 |
| niemeyer | fss: Neat, I'll have a look this afternoon, thanks! | 13:45 |
| fss | niemeyer: great, thank you! :) | 13:47 |
| TheMue | Aram: I'm back | 13:49 |
| === TheMue_ is now known as TheMue | ||
| fwereade_ | rogpeppe, LGTM | 14:38 |
| rogpeppe | fwereade_: thanks | 14:39 |
| rogpeppe | fwereade_: here's the followup: https://codereview.appspot.com/6853043 | 14:42 |
| rogpeppe | fwereade_: not quite so trivial, i'm afraid. i'm *hoping* it's not too crackful. | 14:42 |
| * fwereade_ looks | 14:43 | |
| TheMue | rogpeppe: From my side also an LGTM to the first one, now looking at the second one. | 14:46 |
| rogpeppe | TheMue: ta v much | 14:47 |
| TheMue | rogpeppe: yw | 14:47 |
| fwereade_ | rogpeppe, I'm conflicted on the second one... the extra suite is nice; the SetUpSuite/SetUpTest stuff is a bit off, maybe, but ok given that there's no neater fixture concept; but all the new SetUp/TearDown methods on other suites make me a bit sad | 14:53 |
| fwereade_ | rogpeppe, I guess that's just a consequence of the decisions we've made, and it's not like they're hard to understand | 14:54 |
| rogpeppe | fwereade_: yeah, i agree, they're annoying. it's a consequence of the inflexibility of our test harness unfortunately. | 14:54 |
| fwereade_ | rogpeppe, if there's anything that qualifies as crack it's SetUpTest calls in SetUpSuite methods, but that's fruit from the same tree | 14:55 |
| rogpeppe | fwereade_: yeah, that's my most dubious bit | 14:56 |
| rogpeppe | fwereade_: but i'm like, why *shouldn't* we have a test context for a whole suite? | 14:56 |
| rogpeppe | fwereade_: we could lose the SetUp/TearDown methods in environs, as they're a consequence of me adding LoggingSuite too. | 14:57 |
| fwereade_ | rogpeppe, I'm +1 on LoggingSuite everywhere :) | 14:57 |
| rogpeppe | fwereade_: me too. it's a pity it's not easy to make automatic | 14:58 |
| fwereade_ | rogpeppe, is the cost of putting those SetUpTest calls the in SetUpTest methods prohbitive? | 14:58 |
| rogpeppe | fwereade_: it can't be done, because that particular suite opens an environment in SetUpSuite and uses it for the entire suite run. | 14:58 |
| rogpeppe | fwereade_: so we *need* the faked-up root inside SetUpSuite. | 14:59 |
| fwereade_ | rogpeppe, can't you write the same file in each SetUpTest? | 14:59 |
| rogpeppe | fwereade_: if the faked-up root isn't there for SetUpSuite, we can't open the environment | 14:59 |
| fwereade_ | rogpeppe, I don't *think* a... gahh ok | 14:59 |
| fwereade_ | rogpeppe, right, makes sense | 15:00 |
| rogpeppe | fwereade_: part of the whole point of this is so i can add some code to environs/config that adds two default files to read without adding those attributes *everywhere* a config is made. | 15:00 |
| fwereade_ | rogpeppe, what's your immediate response to the idea of having two FakeRootSuites, one of which does its thing at the test level, and one at the suite level? | 15:01 |
| fwereade_ | rogpeppe, feels like the code to do so will be quite small, and will eliminate that Test/Suite issue | 15:01 |
| fwereade_ | rogpeppe, which is IIRC in 2 places... right? | 15:02 |
| rogpeppe | fwereade_: seems like make-work, but if you can think of decent names for 'em, that is a reasonable thing | 15:02 |
| rogpeppe | fwereade_: yeah. but i really don't see why i shouldn't be able to use a Suite as i like. we've got a very inheritance-based view of this whole test suite thing. | 15:02 |
| fwereade_ | rogpeppe, the only reason for it is that I worry that those Suite+Test bits will slide right by the eyes, even with the comment, and that in a year someone will spend 2 hours debugging ;p | 15:02 |
| fwereade_ | rogpeppe, sure -- IMO the right answer is nestable Fixtures | 15:03 |
| rogpeppe | fwereade_: call/defer :-) | 15:03 |
| fwereade_ | rogpeppe, ha, indeed | 15:03 |
| rogpeppe | fwereade_: no need for a "fixture" concept at all :-) | 15:04 |
| rogpeppe | fwereade_: anyway.... | 15:04 |
| rogpeppe | fwereade_: have you got a reasonable name for the FakeRootSuite that sets up for the suite only rather than the tests? | 15:04 |
| Aram | I don't like fixtures. | 15:04 |
| rogpeppe | SuiteFakeRootSuite? :-) | 15:04 |
| rogpeppe | Aram: me neither. | 15:05 |
| fwereade_ | rogpeppe, heh, that question has indeed been exercising me | 15:05 |
| fwereade_ | rogpeppe, basically, no I don't | 15:05 |
| fwereade_ | rogpeppe, I think maybe I'd prefer a FakeRoot with unqualified SetUp and TearDown | 15:06 |
| fwereade_ | rogpeppe, and, well, no tests, so it ain't a suite, but I'm not sure whether that'll be popular | 15:07 |
| rogpeppe | fwereade_: none of the fixtures are suites in that respect | 15:07 |
| fwereade_ | rogpeppe, indeed, I just seem to recall that argument falling on deaf ears in the past | 15:07 |
| rogpeppe | fwereade_: i like the idea, but i'm not sure it'll get through | 15:08 |
| rogpeppe | niemeyer: any thoughts? | 15:09 |
| niemeyer | rogpeppe: None.. I don't know what the context/problem we're trying to solve is | 15:11 |
| rogpeppe | niemeyer: i'll try to explain | 15:11 |
| rogpeppe | niemeyer: in this CL (https://codereview.appspot.com/6853043) i've added FakeRootSuite (a slightly different name for the FakeHomeSuite we talked about) | 15:11 |
| rogpeppe | niemeyer: in at least one context, we need a fake home/root for the extent of a suite run, rather than to be set up every test. | 15:12 |
| rogpeppe | niemeyer: the question is: what's a good way to do that? | 15:12 |
| rogpeppe | niemeyer: in this CL, i'm calling both FakeRootSuite.SetUpSuite and FakeRootSuite.SetUpTest within the test suite's SetUpSuite method | 15:13 |
| rogpeppe | niemeyer: which has the desired effect, but is perhaps non-intuitive. | 15:13 |
| rogpeppe | niemeyer: another possibility is to lose the "Suite" suffix and simply have SetUp and TearDown methods (so it's clear they can be called in any context) | 15:14 |
| TheMue | rogpeppe: You've got a comment. | 15:15 |
| rogpeppe | TheMue: thanks | 15:15 |
| niemeyer | rogpeppe: Why do we need a suite in that case? | 15:20 |
| niemeyer | rogpeppe: How many tests are using this? | 15:20 |
| niemeyer | rogpeppe: Or rather, how many suites | 15:21 |
| rogpeppe | niemeyer: 12 | 15:21 |
| rogpeppe | niemeyer: using FakeRootSuite | 15:21 |
| niemeyer | rogpeppe: Wow, why do they need it? | 15:22 |
| rogpeppe | niemeyer: in most places they're replacing ad-hoc $H | 15:22 |
| rogpeppe | OME setup code | 15:22 |
| niemeyer | rogpeppe: Which I assume it's just os.Setenv("HOME", foo) + os.Setenv("HOME", oldenv)? | 15:23 |
| rogpeppe | niemeyer: plus making the relevant directories | 15:23 |
| niemeyer | rogpeppe: That's c.MkDir() | 15:23 |
| rogpeppe | rogpeppe: os.Mkdir(filepath.Join(home, ".juju"), 0777) etc | 15:24 |
| rogpeppe | niemeyer: this just abstracts out the relevant piece from JujuConnSuite | 15:25 |
| rogpeppe | niemeyer: as we discussed | 15:25 |
| niemeyer | rogpeppe: I think I'd rather fix gocheck so that it preserves the environment across runs, and have a trivial SetupHome directory | 15:25 |
| rogpeppe | niemeyer: that would be better, of course. i didn't think gocheck changes were on the cards. | 15:26 |
| rogpeppe | niemeyer: fancy doing it? | 15:29 |
| rogpeppe | niemeyer: can we put this in in the meantime? then it's all abstracted out and easy to remove in one fell swoop. | 15:32 |
| niemeyer | rogpeppe: I'd prefer to solve the issue at once | 15:43 |
| rogpeppe | niemeyer: ok, sounds good. | 15:43 |
| niemeyer | rogpeppe: Even because that whole thing is taking more time to talk about than to do it | 15:43 |
| niemeyer | rogpeppe: How many lines does this function have? 3? | 15:43 |
| rogpeppe | niemeyer: about 26 all told | 15:44 |
| rogpeppe | niemeyer: not including function headers | 15:44 |
| niemeyer | rogpeppe: :-) | 15:45 |
| niemeyer | rogpeppe: Put it in a loop and let's count again! | 15:45 |
| niemeyer | rogpeppe: No, seriously.. this is trivial | 15:45 |
| rogpeppe | niemeyer: i agree that it would not have been much work to add yet another place that set up $HOME and created a skeleton juju directory, but it felt wrong, which was why i mentioned it to you recently | 15:45 |
| rogpeppe | niemeyer: and we agreed to do this | 15:45 |
| rogpeppe | niemeyer: and now i've done it you don't like it, which is a bit galling | 15:46 |
| niemeyer | rogpeppe: Also, why are we creating .ssh and .juju directories? | 15:46 |
| niemeyer | rogpeppe: I've seen one or two places that create it | 15:47 |
| rogpeppe | niemeyer: so that we can pick up authorized keys and (in a CL later in the pipeline) tls certs from the "home" dir | 15:47 |
| niemeyer | rogpeppe: .ssh, specifically | 15:47 |
| rogpeppe | niemeyer: so that we don't need to add attributes to every single place that creates a juju config | 15:47 |
| niemeyer | rogpeppe: I'm concerned that we continue to grow up stock harness | 15:48 |
| rogpeppe | niemeyer: i'm concerned by the number of places we have to change if we change anything about the config. | 15:48 |
| rogpeppe | niemeyer: a second or two at an absolute maximum, over all the tests, is not going to affect things badly. | 15:49 |
| niemeyer | % grep '"\.ssh"' * -r 2>/dev/null | grep _test | wc -l | 15:49 |
| niemeyer | 2 | 15:49 |
| rogpeppe | niemeyer: try grepping for "authorized-keys" | 15:50 |
| niemeyer | rogpeppe: Yep? | 15:51 |
| rogpeppe | niemeyer: almost every one of those is there because we can't use the usual config default of reading the .ssh directory. | 15:52 |
| rogpeppe | niemeyer: i'm just about to add two more equivalent attributes | 15:53 |
| rogpeppe | niemeyer: and i'd quite like not to add the new attributes (which can likewise be sourced by reading from $HOME) to every place that currently mentions "authorized-keys" | 15:54 |
| niemeyer | rogpeppe: Okay, so you want to replace that one-line entry in the dummy configuration by a member suite and multiple function calls that setup up a fake environment? | 15:54 |
| niemeyer | rogpeppe: Doesn't seem like an improvement at all to me? | 15:54 |
| rogpeppe | niemeyer: if fixtures weren't so heavy weight, it would be just two function calls, but yeah, you're probably right, it's not worth it. i'll abandon. | 15:56 |
| niemeyer | rogpeppe: A lighter function of it might be interesting, but I'm concerned that I've seen more meta-development happening around TLS than actual progress | 15:57 |
| rogpeppe | niemeyer: yeah. :-| | 15:57 |
| rogpeppe | niemeyer: how about this? it's the specific case that caused me to want to generalise to FakeRootSuite. https://codereview.appspot.com/6843046/ | 16:25 |
| niemeyer | rogpeppe: Do we need to switch all the tests? | 16:27 |
| niemeyer | rogpeppe: What's the specific tests being implemented? | 16:27 |
| rogpeppe | niemeyer: sorry, what do you mean by "switch all the tests"? | 16:28 |
| rogpeppe | niemeyer: are you asking whether it's necessary to set up the directory for all the tests? | 16:28 |
| niemeyer | rogpeppe: Yes, I'm asking about the feature we're adding.. this is adding logic to a test suite that wasn't there before | 16:29 |
| niemeyer | rogpeppe: So supposedly there are quite a few tests there which do not need additional harness | 16:30 |
| rogpeppe | niemeyer: yes, that's true. should i split the suite? | 16:30 |
| niemeyer | rogpeppe: Can we do nothing? | 16:30 |
| rogpeppe | niemeyer: we can do nothing if we're prepared to have an x509 certificate sitting in the middle of every textual config in that file. | 16:30 |
| rogpeppe | niemeyer: personally, i think that would clutter the code quite badly | 16:31 |
| niemeyer | rogpeppe: You're creating an .ssh directory, not a .x509 one.. I'm having to guess what you have in mind at this point | 16:31 |
| rogpeppe | niemeyer: the .ssh directory is just a convenience. it means we don't need to specifically mention authorized-keys in the configurations. i can remove it if you like. | 16:32 |
| niemeyer | rogpeppe: Can we talk about the problem we're solving? | 16:33 |
| rogpeppe | niemeyer: ok | 16:33 |
| niemeyer | rogpeppe: You continue to ask my opinion without context | 16:33 |
| rogpeppe | niemeyer: i'm trying to add some values to the environs.Config | 16:33 |
| niemeyer | rogpeppe: Why? | 16:33 |
| niemeyer | rogpeppe: nothing in the conversation we had in UDS requires changes to Config, IIRC | 16:34 |
| rogpeppe | niemeyer: so that we can specify the tls root certificate in environments.yaml | 16:34 |
| niemeyer | rogpeppe: That's not what we discussed? | 16:34 |
| rogpeppe | niemeyer: it seems to me that it was, but ok... we need to get a root certificate from somewhere. where do we get it from? | 16:34 |
| niemeyer | rogpeppe: Nope | 16:35 |
| niemeyer | rogpeppe: We never talked about any changes in environments.yaml | 16:35 |
| rogpeppe | niemeyer: ok, so... we | 16:35 |
| niemeyer | rogpeppe: and we certainly won't be asking people to configure root certificates in their environments.yaml.. that would be a freaking terrible user experience | 16:35 |
| rogpeppe | niemeyer: ok, so... how do we know what the root certificate is? | 16:36 |
| niemeyer | rogpeppe: Oh no | 16:36 |
| niemeyer | rogpeppe: Please tell me you still remember the conversation we had at UDS.. :-( | 16:36 |
| rogpeppe | niemeyer: i thought i did | 16:36 |
| * niemeyer saddens | 16:36 | |
| rogpeppe | niemeyer: so, *somehow*, juju.Conn needs to know what the root certificate is, so it can sign the certificate that goes out to the bootstrap node | 16:37 |
| niemeyer | rogpeppe: Yep, it generates it | 16:38 |
| rogpeppe | niemeyer: ok, so what about the next time, when we connect to the environment again? | 16:38 |
| niemeyer | rogpeppe: We read it from disk | 16:38 |
| rogpeppe | niemeyer: juju.Conn reads it from disk? | 16:38 |
| niemeyer | rogpeppe: Man.. we did talk about this before | 16:38 |
| niemeyer | rogpeppe: We talked even about what the parameters should be | 16:39 |
| rogpeppe | niemeyer: ok, i've obviously distorted over the last week | 16:40 |
| rogpeppe | niemeyer: please outline very briefly what you understood from our conversation | 16:40 |
| rogpeppe | niemeyer: hold on, are you saying that there should be no way of making a juju connection without having a home directory? | 16:41 |
| niemeyer | rogpeppe: We need to pass some information into it so that we can decide what to use | 16:41 |
| niemeyer | rogpeppe: IIRC we also agreed that if we provided nil, we'd automatically read the file | 16:42 |
| rogpeppe | niemeyer: scratch that | 16:42 |
| * rogpeppe thinks | 16:44 | |
| rogpeppe | niemeyer: so we don't want to allow people to have different root CAs for different environments? | 16:45 |
| rogpeppe | niemeyer: my thought was that if no certificate was specified in environments.yaml, one would be read from $HOME, same as authorized-keys today | 16:47 |
| rogpeppe | niemeyer: when we were talking about passing the information in, i was thinking that was about the saved temporary root certificate, not the permanent root cert. | 17:00 |
| rogpeppe | niemeyer: i'm sorry if i've derailed. | 17:01 |
| TheMue | *: So, I'm stepping out. | 17:16 |
| rogpeppe | niemeyer: can we perhaps G+ this, before i go further awry? | 17:16 |
| TheMue | Aram: Thanks for the detailed informations, we'll continue tomorrow. | 17:16 |
| rogpeppe | niemeyer: for the recording, this CL is what i understood by passing some information independently of the config: https://codereview.appspot.com/6819115 | 17:23 |
| rogpeppe | s/recording/record/ | 17:23 |
| rogpeppe | niemeyer: that certificate and key being independent of the root cert and key | 17:23 |
| rogpeppe | niemeyer: which is what i was planning to put into the config. | 17:24 |
| * rogpeppe is going to have to leave in 25 minutes | 17:37 | |
| niemeyer | rogpeppe: I think our previous model still holds | 17:50 |
| niemeyer | rogpeppe: There's no need to put anything in environments.yaml.. the user shouldn't have to do that | 17:51 |
| rogpeppe | niemeyer: ok. i thought perhaps the user may want to specify a root CA in environments.yaml. anyway, here's a possible sketch of how things might work without putting anything in environments.yam (the functions and methods that would need to change) http://paste.ubuntu.com/1356036/ | 17:58 |
| rogpeppe | niemeyer: does that make more sense to you? | 18:00 |
| rogpeppe | niemeyer: slightly modified: http://paste.ubuntu.com/1356050/ | 18:05 |
| niemeyer | rogpeppe: Looking | 18:07 |
| rogpeppe | niemeyer: BTW i was not going to force the user to put anything extra in environments.yaml (hence the file-reading default in environs/config, like authorized-keys) | 18:07 |
| niemeyer | rogpeppe: So there's no reason to change Config.. | 18:07 |
| niemeyer | rogpeppe: authorized-keys handles a file that is not juju-specific | 18:08 |
| niemeyer | / generated and written to $HOME/.juju/<environ-name>-temp-cert.pem | 18:09 |
| niemeyer | rogpeppe: Why temp-cert? | 18:09 |
| niemeyer | / The temporary root certificate is required only | 18:10 |
| niemeyer | / for the first connection to a juju environment. | 18:10 |
| rogpeppe | niemeyer: that's for making the bootstrap instance safe against cloudinit-peekers, but... come to think of it, we'd agreed that wasn't a priority, right? | 18:10 |
| niemeyer | rogpeppe: I'm sure we've agreed to not do this dance at UDS | 18:10 |
| rogpeppe | niemeyer: yeah, ok, that's cool | 18:11 |
| niemeyer | rogpeppe: Was that a different Roger I was talking to? :) | 18:11 |
| rogpeppe | niemeyer: one that has been looking at the wrong set of notes, it seems :-) | 18:11 |
| niemeyer | rogpeppe: Yeah, lesson taken here.. I should certainly not have assumed that the conversation would be enough | 18:13 |
| rogpeppe | niemeyer: ok, updated version: http://paste.ubuntu.com/1356068/ | 18:14 |
| rogpeppe | niemeyer: it still seems to me that the extra arguments are unnecessary if we can store the root cert in the config, but i'm happy to go this way. | 18:16 |
| niemeyer | rogpeppe: Stuffing things in the configuration to avoid parameters to a function is poor reasoning | 18:18 |
| niemeyer | rogpeppe: We should put that in the environment configuration if we're indeed using that as an environment setting | 18:19 |
| rogpeppe | niemeyer: ISTM that the configuration parameters currently hold everything necessary for connecting to an environment, and the root certificate is such a thing, hence i thought it a good fit. | 18:19 |
| rogpeppe | niemeyer: but tbh changing the configuration is a right pain, so i'm happy to go this way | 18:19 |
| niemeyer | rogpeppe: We have only one configuration that is not an actual configuration, admin-secret, and that's a bad idea.. it's been cargo-culted from py | 18:20 |
| rogpeppe | niemeyer: we can get rid of that when we talk directly to the our own servers, i think | 18:20 |
| niemeyer | rogpeppe: It's not about being a pain or not, and it's not about avoid parameters to a function or not.. the question is simple: is this an environment configuration setting? If it's not, let's not put in the config | 18:20 |
| rogpeppe | niemeyer: i see where you're coming from. i was thinking of environment as "a juju environment" rather than as a provider environment. | 18:22 |
| rogpeppe | niemeyer: anyway, does the above API look reasonable to you? | 18:25 |
| niemeyer | rogpeppe: Yeah, it doesn't say how started machines get their cert, but what's there looks good | 18:26 |
| rogpeppe | niemeyer: do started machines have a cert? | 18:26 |
| rogpeppe | niemeyer: rather, will they? | 18:26 |
| niemeyer | rogpeppe: Oh nos | 18:26 |
| rogpeppe | niemeyer: i thought we were using passwords for client identification | 18:27 |
| niemeyer | rogpeppe: Why do we need a root cert? | 18:27 |
| rogpeppe | niemeyer: so that clients know who they're talking to | 18:27 |
| niemeyer | rogpeppe: and how does that happen? | 18:27 |
| rogpeppe | niemeyer: via TLS. | 18:28 |
| rogpeppe | niemeyer: no client certificate necessary there. | 18:28 |
| niemeyer | rogpeppe: Yes, and how can TLS verify that the client is talking to the right server | 18:28 |
| rogpeppe | niemeyer: because it verifies that the server holds a private key and the certificate that certifies that key | 18:28 |
| niemeyer | <rogpeppe> niemeyer: do started machines have a cert? | 18:28 |
| niemeyer | <rogpeppe> niemeyer: because it verifies that the server holds a private key and the certificate that certifies that key | 18:28 |
| rogpeppe | niemeyer: ah, started state machines, yes. | 18:29 |
| rogpeppe | niemeyer: others don't need a cert. | 18:29 |
| rogpeppe | niemeyer: perhaps we should just make the private key and certificate available in the state. | 18:31 |
| rogpeppe | niemeyer: then a started machine that needs to become a state server can fetch it when necessary | 18:32 |
| rogpeppe | niemeyer: no need for any additions to the above API if we do that. | 18:33 |
| rogpeppe | niemeyer: gotta go. i hear a voice from below. tomorrow i will move forward as discussed. | 18:35 |
| niemeyer | rogpeppe: We've already discussed this at length before | 18:35 |
| niemeyer | rogpeppe: My opinion is still the same | 18:35 |
| fss | niemeyer: I have another CL for you, but I'm not sure if you will like this one... | 19:30 |
| niemeyer | fss? | 19:31 |
| fss | niemeyer: I'm going to start testing tsuru with go version of juju, but before I've adapted python version to work with vpc | 19:31 |
| fss | niemeyer: https://codereview.appspot.com/6850044/ | 19:31 |
| niemeyer | fss: I won't like it or dislike it either :) | 19:31 |
| niemeyer | fss: I'm interested on the concept, though | 19:32 |
| niemeyer | fss: How was it done? | 19:32 |
| fss | niemeyer: actually, we don't mind if it does not get merged, but some deadlines pushed me to do so | 19:32 |
| niemeyer | fss: That's certainly fair | 19:32 |
| niemeyer | fss: It might even get merged | 19:33 |
| niemeyer | fss: But ideally we should have talked about that beforehadn | 19:33 |
| niemeyer | fss: How was the change done? | 19:33 |
| fss | niemeyer: I see, sorry about that :-) | 19:33 |
| fss | niemeyer: we've added two new environment settings: vpc_id and subnet_id | 19:34 |
| fss | at this point, every machine in an environment is launched in the same subnet_id | 19:34 |
| niemeyer | fss: How do you handle private ip vs. public ip? | 19:34 |
| fss | niemeyer: that's a good question, I don't handle this yet :-( | 19:37 |
| niemeyer | fss: Okay | 19:37 |
| niemeyer | fss: Yeah, looks like a few things there | 19:37 |
| fss | niemeyer: well, I will work on this now. What approach would you suggest? | 19:37 |
| niemeyer | fss: Expose? | 19:37 |
| niemeyer | fss: What about juju expose? | 19:41 |
| fss | niemeyer: hmm, I didn't look at that too =/ | 19:41 |
| niemeyer | fss: Okay, there are a few complicators for an actual implementation | 19:42 |
| niemeyer | fss: The subnet_id/vpc_id must also be internally managed | 19:43 |
| niemeyer | fss: We shouldn't have to ask people to learn about the crazy interface/API Amazon puts in place to get things going | 19:43 |
| fss | niemeyer: my terminal was freak, sorry | 19:44 |
| niemeyer | <niemeyer> fss: We shouldn't have to ask people to learn about the crazy interface/API Amazon puts in place to get things going | 19:44 |
| niemeyer | fss: np | 19:44 |
| niemeyer | That was about | 19:44 |
| niemeyer | <niemeyer> fss: The subnet_id/vpc_id must also be internally managed | 19:44 |
| fss | niemeyer: I see, but how would juju manage it? creating new vpc's and subnet's? | 19:45 |
| niemeyer | fss: Yeah, I haven't really detailed anything | 19:49 |
| niemeyer | fss: in my mind, that is | 19:49 |
| niemeyer | fss: But the principle is that the user shouldn't have to know all the ins and outs to make use of juju | 19:49 |
| niemeyer | fss: So that necessarily means managing vpc's, subnet's, and I suppose elastic IPs | 19:50 |
| niemeyer | fss: Which makes it somewhat involved | 19:50 |
| fss | niemeyer: but in the case that I'm creating a VPN connection between a VPC and my internal network, I have to know | 19:50 |
| niemeyer | fss: But we'll have to really put some thinking in place and actually do it | 19:50 |
| niemeyer | fss: Well, you can bootstrap the environment, and then do whatever, I think | 19:51 |
| fss | niemeyer: I see | 19:51 |
| niemeyer | fss: Am I missing important details there? | 19:51 |
| fss | niemeyer: in our scenario, we have a security/networking team. They created the VPC, VPN connection and the subnet, and gave to us the id of the subnet and the vpc, that's why I took this approach, where the juju user already knows the id of the vpc and the subnet | 19:53 |
| niemeyer | fss: Sounds like a reasonable scenario | 19:54 |
| niemeyer | fss: We should support it, but we should also have a default mechanism that doesn't require everybody to have a security/networking team :-) | 19:55 |
| fss | niemeyer: sure, makes sense | 19:56 |
| fss | niemeyer: I definitely should talked to you before, or at least to some one that is not in the same environment that I am | 19:58 |
| niemeyer | fss: Doesn't feel like you wasted too much time, though | 19:58 |
| niemeyer | fss: There's just more to be considered and handled | 19:59 |
| niemeyer | fss: Have you been playing with the Go port already? | 20:00 |
| niemeyer | fss: What are the chances of getting you using the port sooner rather than later? | 20:00 |
| niemeyer | fss: So that we could jointly develop this there? | 20:01 |
| fss | niemeyer: not yet, but I want do to this in our next big weekend in brazil | 20:01 |
| niemeyer | fss: :) | 20:01 |
| niemeyer | fss: Any chance of getting some of you in a sprint in the south of Brazil soon? | 20:02 |
| fss | niemeyer: I want to start hacking it out on thursday, and I'll let you know | 20:02 |
| fss | niemeyer: I don't, next FISL? :-P | 20:03 |
| fss | I don't know* | 20:03 |
| niemeyer | fss: No, I mean a specific event to get this going | 20:03 |
| fss | niemeyer: hmm, I think there's a chance | 20:03 |
| niemeyer | fss: I want to add support in the Go version real soon | 20:04 |
| niemeyer | fss: We could try to organize a one week sprint here to get these concepts in place | 20:04 |
| niemeyer | fss: Then you could either use the Go version, or port the chances we make to Python, so we have compatibility | 20:05 |
| fss | niemeyer: I will talk to my sponsors :-) | 20:09 |
| fss | niemeyer: they'll probably ask if you can come here too | 20:09 |
| niemeyer | fss: Cool, it would be great to have the juju-involved developers here for a week | 20:09 |
| fss | :-) | 20:09 |
| niemeyer | fss: I can't this time around, specifically, but maybe in the future | 20:09 |
| niemeyer | fss: Something about babies | 20:10 |
| fss | niemeyer: hmm, I see | 20:10 |
| niemeyer | fss: I'd be game for an event in town, though | 20:10 |
| niemeyer | fss: and really, it's not too expensive to have that kind of event all things considered | 20:10 |
| fss | niemeyer: PythonBrasil is two weeks from now :-) | 20:11 |
| niemeyer | fss: I know.. I had to tell Tatiana the same story, unfortunately (in that sense) | 20:12 |
| fss | niemeyer: talking about PythonBrasil, I have to go, we need to add some new stuff to the website, and before that I'm going to get some traffic jam :-( | 20:16 |
| niemeyer | fss: Have fun there | 20:16 |
| fss | niemeyer: thanks | 20:23 |
| davecheney | booh - amazon are blocking pings to ap-southeast-2 hosts | 23:39 |
| davecheney | it is ~30 ms from me | 23:39 |
| davecheney | but I can't confirm | 23:39 |
| davecheney | in related news | 23:40 |
| davecheney | m1.small, i/o still really slow | 23:40 |
| davecheney | cloudinit takes ~10 mins | 23:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!