[07:18] <rogpeppe> davecheney, fwereade_, dimitern: morning all
[07:18] <dimitern> rogpeppe: hiya :)
[07:30] <TheMue> morning
[07:31] <rogpeppe> TheMue: yo!
[07:32] <TheMue> rogpeppe: hi
[07:33] <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:34] <TheMue> rogpeppe: Ah, ok, then I misinterpreted your answer to Dave.
[08:07] <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:20] <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:26] <TheMue> dimitern: Take a look at state/state_test.go, line 235ff.
[08:27] <TheMue> dimitern: There's a var inferEndpointsTests defined as slice of unnamed structs.
[08:28] <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:29] <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:30] <TheMue> dimitern: In TestInferEndpoints in line 378 you loop over the slice and perform actions and asserts depending on those table/slice values.
[08:31] <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:32] <TheMue> dimitern: Exactly. Doing it manually would need by far more code and is not so good readable.
[09:15] <rogpeppe> fwereade_: i'm seeing a uniter test failure in trunk: http://paste.ubuntu.com/1355121/
[09:16] <fwereade_> rogpeppe, oh hell (takes a look)
[09:17] <fwereade_> rogpeppe, hm, I *think* I have a branch that addresses that somewhere -- anyway ty
[09:17] <rogpeppe> fwereade_: np
[09:18] <rogpeppe> fwereade_: it's failing consistently for me, BTW, but not always in the same test.
[09:52] <TheMue> Aram: Moin
[09:52] <Aram> hello.
[09:56] <rogpeppe> fwereade_: a fairly simple change: https://codereview.appspot.com/6849044/
[10:00] <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:04] <fwereade_> rogpeppe, LGTM
[10:04] <rogpeppe> fwereade_: thanks
[10:05] <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:06] <fwereade_> Aram, TheMue: re container abstraction, do you have anything resembling niemeyer-approval? that is my main concern
[10:07] <TheMue> fwereade_: Could you please rephrase it?
[10:08] <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:09] <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:10] <TheMue> fwereade_: And Arams ideas sound reasonable to me so far.
[10:11] <TheMue> fwereade_: We made a first little analysis, where code has to be changed.
[10:17] <TheMue> Ah, split is over.
[10:20] <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:22] <TheMue> rogpeppe: *click*
[10:33] <TheMue> rogpeppe: LGTM, with +1 for fwereade_s comment
[10:33] <Aram> davecheney: you have another review
[10:34] <davecheney> Aram: ty
[10:39] <rogpeppe> TheMue: thanks.
[10:39] <Aram> reboot
[10:41] <Aram> I hate the damn vmware.
[10:41] <Aram> I wish virtualbox didn't suck.
[10:44] <TheMue> Aram: What concrete problem you have with vmware?
[10:45] <Aram> It just rewrote my routing table on my host
[10:45] <TheMue> Iiirks
[10:46] <Aram> and the GUI is so, so, sloow.
[10:47] <Aram> and the updater never works.
[10:49] <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:50] <Aram> the windows interface was rewritten in C#.
[10:50] <Aram> everything went down since then.
[10:56] <TheMue> Aram: Doesn't Parallels also exist for Win?
[10:56] <Aram> no.
[11:03] <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:05] <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:37] <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:38] <TheMue> niemeyer: Oh, did we?
[11:39] <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:40] <TheMue> niemeyer: Iirks, yep, it's 10:40 there now.
[11:41] <TheMue> niemeyer: But also 6:40 right now for Mark. We have a wide span right now.
[11:41] <niemeyer> Yep
[11:43] <jam> niemeyer: is there a reason that "go test -gocheck.v ./..." and "go test ./... -gocheck.v" do different things?
[11:44] <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:46] <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:59] <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... :)
[12:00] <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:01] <mramm> https://plus.google.com/hangouts/_/50b626916b5f85ebad8bc80dde5052b14aa7a6d7?authuser=0&hl=en-GB
[12:02] <jam> dimitern: ^^
[12:02] <mramm> everybody should be invited now
[12:02] <jam> mgz: ^^
[12:06] <mgz> ...hangout is very unhappy
[12:07] <mgz> I think I need to not join last, too much junk being done that I can't disable
[12:08] <mgz> ...and now the room is full, probably with a ghost of me
[12:09] <mgz> should have just used machine downstairs
[12:10] <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:12] <TheMue> See http://bazaar.launchpad.net/~themue/+junk/golxc/files for the LXC code.
[12:32] <niemeyer>         curl, err := charm.InferURL(c.CharmName, conf.DefaultSeries())
[12:41] <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:42] <dimitern> jam: I see, so it's confirmed
[12:42] <jam> dimitern: yeah
[12:45] <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:46] <jam> fwereade_: have a good evening.
[12:49] <TheMue> fwereade_: Enjoy, mine are coming on there own (or are out of school already). ;)
[12:50] <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:51] <TheMue> Aram: Sure, np, here: https://docs.google.com/a/canonical.com/document/d/1Chla4FgaMTlwXFdAzFv-ToN0iNsWKFECNGOCerC8PH0/edit
[12:51] <Aram> thanks
[13:02] <TheMue> lunchtime
[13:06] <rogpeppe> fwereade_, TheMue: i didn't quite get it right last time... https://codereview.appspot.com/6851043
[13:19]  * rogpeppe goes for lunch
[13:25] <niemeyer> rogpeppe: Enjoy
[13:32] <Aram> TheMue: tell me when you're back.
[13:43] <fss> niemeyer: hi :-)
[13:44] <fss> niemeyer: could you take a look at that CL?
[13:44] <fss> niemeyer: https://codereview.appspot.com/6823060/
[13:45] <niemeyer> fss: Neat, I'll have a look this afternoon, thanks!
[13:47] <fss> niemeyer: great, thank you! :)
[13:49] <TheMue> Aram: I'm back
[14:38] <fwereade_> rogpeppe, LGTM
[14:39] <rogpeppe> fwereade_: thanks
[14:42] <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:43]  * fwereade_ looks
[14:46] <TheMue> rogpeppe: From my side also an LGTM to the first one, now looking at the second one.
[14:47] <rogpeppe> TheMue: ta v much
[14:47] <TheMue> rogpeppe: yw
[14:53] <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:54] <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:55] <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:56] <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:57] <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:58] <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:59] <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
[15:00] <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:01] <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:02] <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:03] <fwereade_> rogpeppe, sure -- IMO the right answer is nestable Fixtures
[15:03] <rogpeppe> fwereade_: call/defer :-)
[15:03] <fwereade_> rogpeppe, ha, indeed
[15:04] <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:05] <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:06] <fwereade_> rogpeppe, I think maybe I'd prefer a FakeRoot with unqualified SetUp and TearDown
[15:07] <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:08] <rogpeppe> fwereade_: i like the idea, but i'm not sure it'll get through
[15:09] <rogpeppe> niemeyer: any thoughts?
[15:11] <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:12] <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:13] <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:14] <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:15] <TheMue> rogpeppe: You've got a comment.
[15:15] <rogpeppe> TheMue: thanks
[15:20] <niemeyer> rogpeppe: Why do we need a suite in that case?
[15:20] <niemeyer> rogpeppe: How many tests are using this?
[15:21] <niemeyer> rogpeppe: Or rather, how many suites
[15:21] <rogpeppe> niemeyer: 12
[15:21] <rogpeppe> niemeyer: using FakeRootSuite
[15:22] <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:23] <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:24] <rogpeppe> rogpeppe: os.Mkdir(filepath.Join(home, ".juju"), 0777) etc
[15:25] <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:26] <rogpeppe> niemeyer: that would be better, of course. i didn't think gocheck changes were on the cards.
[15:29] <rogpeppe> niemeyer: fancy doing it?
[15:32] <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:43] <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:44] <rogpeppe> niemeyer: about 26 all told
[15:44] <rogpeppe> niemeyer: not including function headers
[15:45] <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:46] <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:47] <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:48] <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:49] <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:50] <rogpeppe> niemeyer: try grepping for "authorized-keys"
[15:51] <niemeyer> rogpeppe: Yep?
[15:52] <rogpeppe> niemeyer: almost every one of those is there because we can't use the usual config default of reading the .ssh directory.
[15:53] <rogpeppe> niemeyer: i'm just about to add two more equivalent attributes
[15:54] <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:56] <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:57] <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. :-|
[16:25] <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:27] <niemeyer> rogpeppe: Do we need to switch all the tests?
[16:27] <niemeyer> rogpeppe: What's the specific tests being implemented?
[16:28] <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:29] <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:30] <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:31] <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:32] <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:33] <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:34] <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:35] <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:36] <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:37] <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:38] <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:39] <niemeyer> rogpeppe: We talked even about what the parameters should be
[16:40] <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:41] <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:42] <niemeyer> rogpeppe: IIRC we also agreed that if we provided nil, we'd automatically read the file
[16:42] <rogpeppe> niemeyer: scratch that
[16:44]  * rogpeppe thinks
[16:45] <rogpeppe> niemeyer: so we don't want to allow people to have different root CAs for different environments?
[16:47] <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
[17:00] <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:01] <rogpeppe> niemeyer: i'm sorry if i've derailed.
[17:16] <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:23] <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:24] <rogpeppe> niemeyer: which is what i was planning to put into the config.
[17:37]  * rogpeppe is going to have to leave in 25 minutes
[17:50] <niemeyer> rogpeppe: I think our previous model still holds
[17:51] <niemeyer> rogpeppe: There's no need to put anything in environments.yaml.. the user shouldn't have to do that
[17:58] <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/
[18:00] <rogpeppe> niemeyer: does that make more sense to you?
[18:05] <rogpeppe> niemeyer: slightly modified: http://paste.ubuntu.com/1356050/
[18:07] <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:08] <niemeyer> rogpeppe: authorized-keys handles a file that is not juju-specific
[18:09] <niemeyer> / generated and written to $HOME/.juju/<environ-name>-temp-cert.pem
[18:09] <niemeyer> rogpeppe: Why temp-cert?
[18:10] <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:11] <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:13] <niemeyer> rogpeppe: Yeah, lesson taken here.. I should certainly not have assumed that the conversation would be enough
[18:14] <rogpeppe> niemeyer: ok, updated version: http://paste.ubuntu.com/1356068/
[18:16] <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:18] <niemeyer> rogpeppe: Stuffing things in the configuration to avoid parameters to a function is poor reasoning
[18:19] <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:20] <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:22] <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:25] <rogpeppe> niemeyer: anyway, does the above API look reasonable to you?
[18:26] <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:27] <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:28] <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
 niemeyer: do started machines have a cert?
 niemeyer: because it verifies that the server holds a private key and the certificate that certifies that key
[18:29] <rogpeppe> niemeyer: ah, started state machines, yes.
[18:29] <rogpeppe> niemeyer: others don't need a cert.
[18:31] <rogpeppe> niemeyer: perhaps we should just make the private key and certificate available in the state.
[18:32] <rogpeppe> niemeyer: then a started machine that needs to become a state server can fetch it when necessary
[18:33] <rogpeppe> niemeyer: no need for any additions to the above API if we do that.
[18:35] <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
[19:30] <fss> niemeyer: I have another CL for you, but I'm not sure if you will like this one...
[19:31] <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:32] <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:33] <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:34] <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:37] <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:41] <niemeyer> fss: What about juju expose?
[19:41] <fss> niemeyer: hmm, I didn't look at that too =/
[19:42] <niemeyer> fss: Okay, there are a few complicators for an actual implementation
[19:43] <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:44] <fss> niemeyer: my terminal was freak, sorry
 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
 fss: The subnet_id/vpc_id must also be internally managed
[19:45] <fss> niemeyer: I see, but how would juju manage it? creating new vpc's and subnet's?
[19:49] <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:50] <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:51] <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:53] <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:54] <niemeyer> fss: Sounds like a reasonable scenario
[19:55] <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:56] <fss> niemeyer: sure, makes sense
[19:58] <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:59] <niemeyer> fss: There's just more to be considered and handled
[20:00] <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:01] <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:02] <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:03] <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:04] <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:05] <niemeyer> fss: Then you could either use the Go version, or port the chances we make to Python, so we have compatibility
[20:09] <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:10] <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:11] <fss> niemeyer: PythonBrasil is two weeks from now :-)
[20:12] <niemeyer> fss: I know.. I had to tell Tatiana the same story, unfortunately (in that sense)
[20:16] <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:23] <fss> niemeyer: thanks
[23:39] <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:40] <davecheney> in related news
[23:40] <davecheney> m1.small, i/o still really slow
[23:40] <davecheney> cloudinit takes ~10 mins