[07:18] davecheney, fwereade_, dimitern: morning all [07:18] rogpeppe: hiya :) [07:30] morning [07:31] TheMue: yo! [07:32] rogpeppe: hi [07:33] rogpeppe: Today next round in your fight connecting MongoDB via SSL? [07:33] TheMue: no, i got that working last week [07:33] TheMue: (in a piece of example code, anyway) [07:34] rogpeppe: Ah, ok, then I misinterpreted your answer to Dave. [08:07] anybody has a handy link on how to write table-based tests for go? [08:07] I can't seem to find it, and I'm sure there was one somewhere.. [08:20] dimitern: We're using them in some of our tests. I'll look for an example. [08:20] dimitern: Hi btw. [08:20] TheMue: hi :) 10x! [08:26] dimitern: Take a look at state/state_test.go, line 235ff. [08:27] dimitern: There's a var inferEndpointsTests defined as slice of unnamed structs. [08:28] 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] dimitern: It directly follows a number of struct values. [08:29] TheMue: I see! 10x again, I'll use it as a reference [08:30] dimitern: In TestInferEndpoints in line 378 you loop over the slice and perform actions and asserts depending on those table/slice values. [08:31] dimitern: Cheers, it's a nice technique to cover a large number of different tests of the same kind. [08:31] TheMue: interesting pattern - I see how expressive the table is - you can see every test at one place [08:32] dimitern: Exactly. Doing it manually would need by far more code and is not so good readable. [09:15] fwereade_: i'm seeing a uniter test failure in trunk: http://paste.ubuntu.com/1355121/ [09:16] rogpeppe, oh hell (takes a look) [09:17] rogpeppe, hm, I *think* I have a branch that addresses that somewhere -- anyway ty [09:17] fwereade_: np [09:18] fwereade_: it's failing consistently for me, BTW, but not always in the same test. [09:52] Aram: Moin [09:52] hello. [09:56] fwereade_: a fairly simple change: https://codereview.appspot.com/6849044/ [10:00] 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] rogpeppe, LGTM [10:04] fwereade_: thanks [10:05] fwereade_: i've been meaning to get around to that for ages, and finally found a place where it made things easier [10:05] rogpeppe, yeah, it's much nicer [10:06] Aram, TheMue: re container abstraction, do you have anything resembling niemeyer-approval? that is my main concern [10:07] fwereade_: Could you please rephrase it? [10:08] 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] fwereade_: I believe it would significantly reduce complexity even now, especially for watchers. [10:08] Aram, TheMue: I like the idea but not enough to feel I have the resources for a protracted battle over it [10:09] Aram, if you think you can make a compelling case in code then that definitely changes the situation for the better :) [10:09] 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] fwereade_: And Arams ideas sound reasonable to me so far. [10:11] fwereade_: We made a first little analysis, where code has to be changed. [10:17] Ah, split is over. [10:20] 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] rogpeppe: *click* [10:33] rogpeppe: LGTM, with +1 for fwereade_s comment [10:33] davecheney: you have another review [10:34] Aram: ty [10:39] TheMue: thanks. [10:39] reboot [10:41] I hate the damn vmware. [10:41] I wish virtualbox didn't suck. [10:44] Aram: What concrete problem you have with vmware? [10:45] It just rewrote my routing table on my host [10:45] Iiirks [10:46] and the GUI is so, so, sloow. [10:47] and the updater never works. [10:49] 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] the windows interface was rewritten in C#. [10:50] everything went down since then. [10:56] Aram: Doesn't Parallels also exist for Win? [10:56] no. [11:03] 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] TheMue: after I'me done with breakfast, in the meantime please share the link [11:05] Aram: OK, here it is https://docs.google.com/a/canonical.com/document/d/1Chla4FgaMTlwXFdAzFv-ToN0iNsWKFECNGOCerC8PH0/edit [11:37] Hello all [11:37] niemeyer: Hiya [11:37] Why did we switch the meeting time by 2h today? [11:37] Well, 1h.. [11:38] niemeyer: Oh, did we? [11:39] 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] s/as the/at the/ [11:39] TheMue: Yep, but hemispheres shift DST in a different direction, so what is "same time" there is 2h off here [11:39] It's great for me, but it's probably not nice for davecheney [11:40] niemeyer: Iirks, yep, it's 10:40 there now. [11:41] niemeyer: But also 6:40 right now for Mark. We have a wide span right now. [11:41] Yep [11:43] niemeyer: is there a reason that "go test -gocheck.v ./..." and "go test ./... -gocheck.v" do different things? [11:44] (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] jam: Probably a bug in go test [11:46] jam: Without looking, I'd guess that they're making a decision based on number of flags seen, without considering foreign flags [11:59] so, when is the meeting? [11:59] now? [11:59] nowish [11:59] So, meeting is now [11:59] 10 [11:59] for those who have not been to a meeting before -- can you send me your G+ info [11:59] invite anyone ? [11:59] 9 [11:59] 8 [11:59] so I can add you to the invite [11:59] too fast... :) [12:00] mramm: john.meinel@canonical.com is fine [12:00] dimiter.naydenov@canonical.com [12:00] mramm: I imagine martin.packman@canonical.com as well [12:00] right. [12:01] https://plus.google.com/hangouts/_/50b626916b5f85ebad8bc80dde5052b14aa7a6d7?authuser=0&hl=en-GB [12:02] dimitern: ^^ [12:02] everybody should be invited now [12:02] mgz: ^^ [12:06] ...hangout is very unhappy [12:07] I think I need to not join last, too much junk being done that I can't disable [12:08] ...and now the room is full, probably with a ghost of me [12:09] should have just used machine downstairs [12:10] mgz: I'm guessing you can join downstairs still. I tried to paste the URL to w7z [12:10] ta, will do that [12:12] See http://bazaar.launchpad.net/~themue/+junk/golxc/files for the LXC code. [12:32] curl, err := charm.InferURL(c.CharmName, conf.DefaultSeries()) [12:41] jam: Good news re. Ian [12:41] yeah :) [12:41] niemeyer: thanks, it should good having him around. [12:41] jam: Will be nice to have more people close to davecheney too [12:41] dimitern, mgz: I was trying to mention it to you on mumble, but mgz never joined :) [12:42] jam: I see, so it's confirmed [12:42] dimitern: yeah [12:45] gents, since I appear not to be currently blocking anyone, I'm off to pick up laura from school [12:45] fwereade_: cheers. [12:46] fwereade_: have a good evening. [12:49] fwereade_: Enjoy, mine are coming on there own (or are out of school already). ;) [12:50] Aram: I added some first points about the container abstraction to the doc, but you surely have more. [12:50] TheMue: would you be so kind to share the link with me again? [12:50] I lost it [12:51] Aram: Sure, np, here: https://docs.google.com/a/canonical.com/document/d/1Chla4FgaMTlwXFdAzFv-ToN0iNsWKFECNGOCerC8PH0/edit [12:51] thanks === fss is now known as offline === offline is now known as fss [13:02] lunchtime [13:06] fwereade_, TheMue: i didn't quite get it right last time... https://codereview.appspot.com/6851043 [13:19] * rogpeppe goes for lunch [13:25] rogpeppe: Enjoy [13:32] TheMue: tell me when you're back. [13:43] niemeyer: hi :-) [13:44] niemeyer: could you take a look at that CL? [13:44] niemeyer: https://codereview.appspot.com/6823060/ [13:45] fss: Neat, I'll have a look this afternoon, thanks! [13:47] niemeyer: great, thank you! :) [13:49] Aram: I'm back === TheMue_ is now known as TheMue [14:38] rogpeppe, LGTM [14:39] fwereade_: thanks [14:42] fwereade_: here's the followup: https://codereview.appspot.com/6853043 [14:42] fwereade_: not quite so trivial, i'm afraid. i'm *hoping* it's not too crackful. [14:43] * fwereade_ looks [14:46] rogpeppe: From my side also an LGTM to the first one, now looking at the second one. [14:47] TheMue: ta v much [14:47] rogpeppe: yw [14:53] 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] 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] fwereade_: yeah, i agree, they're annoying. it's a consequence of the inflexibility of our test harness unfortunately. [14:55] 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] fwereade_: yeah, that's my most dubious bit [14:56] fwereade_: but i'm like, why *shouldn't* we have a test context for a whole suite? [14:57] fwereade_: we could lose the SetUp/TearDown methods in environs, as they're a consequence of me adding LoggingSuite too. [14:57] rogpeppe, I'm +1 on LoggingSuite everywhere :) [14:58] fwereade_: me too. it's a pity it's not easy to make automatic [14:58] rogpeppe, is the cost of putting those SetUpTest calls the in SetUpTest methods prohbitive? [14:58] 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] fwereade_: so we *need* the faked-up root inside SetUpSuite. [14:59] rogpeppe, can't you write the same file in each SetUpTest? [14:59] fwereade_: if the faked-up root isn't there for SetUpSuite, we can't open the environment [14:59] rogpeppe, I don't *think* a... gahh ok [15:00] rogpeppe, right, makes sense [15:00] 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] 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] rogpeppe, feels like the code to do so will be quite small, and will eliminate that Test/Suite issue [15:02] rogpeppe, which is IIRC in 2 places... right? [15:02] fwereade_: seems like make-work, but if you can think of decent names for 'em, that is a reasonable thing [15:02] 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] 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] rogpeppe, sure -- IMO the right answer is nestable Fixtures [15:03] fwereade_: call/defer :-) [15:03] rogpeppe, ha, indeed [15:04] fwereade_: no need for a "fixture" concept at all :-) [15:04] fwereade_: anyway.... [15:04] fwereade_: have you got a reasonable name for the FakeRootSuite that sets up for the suite only rather than the tests? [15:04] I don't like fixtures. [15:04] SuiteFakeRootSuite? :-) [15:05] Aram: me neither. [15:05] rogpeppe, heh, that question has indeed been exercising me [15:05] rogpeppe, basically, no I don't [15:06] rogpeppe, I think maybe I'd prefer a FakeRoot with unqualified SetUp and TearDown [15:07] rogpeppe, and, well, no tests, so it ain't a suite, but I'm not sure whether that'll be popular [15:07] fwereade_: none of the fixtures are suites in that respect [15:07] rogpeppe, indeed, I just seem to recall that argument falling on deaf ears in the past [15:08] fwereade_: i like the idea, but i'm not sure it'll get through [15:09] niemeyer: any thoughts? [15:11] rogpeppe: None.. I don't know what the context/problem we're trying to solve is [15:11] niemeyer: i'll try to explain [15:11] 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] 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] niemeyer: the question is: what's a good way to do that? [15:13] niemeyer: in this CL, i'm calling both FakeRootSuite.SetUpSuite and FakeRootSuite.SetUpTest within the test suite's SetUpSuite method [15:13] niemeyer: which has the desired effect, but is perhaps non-intuitive. [15:14] 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] rogpeppe: You've got a comment. [15:15] TheMue: thanks [15:20] rogpeppe: Why do we need a suite in that case? [15:20] rogpeppe: How many tests are using this? [15:21] rogpeppe: Or rather, how many suites [15:21] niemeyer: 12 [15:21] niemeyer: using FakeRootSuite [15:22] rogpeppe: Wow, why do they need it? [15:22] niemeyer: in most places they're replacing ad-hoc $H [15:22] OME setup code [15:23] rogpeppe: Which I assume it's just os.Setenv("HOME", foo) + os.Setenv("HOME", oldenv)? [15:23] niemeyer: plus making the relevant directories [15:23] rogpeppe: That's c.MkDir() [15:24] rogpeppe: os.Mkdir(filepath.Join(home, ".juju"), 0777) etc [15:25] niemeyer: this just abstracts out the relevant piece from JujuConnSuite [15:25] niemeyer: as we discussed [15:25] rogpeppe: I think I'd rather fix gocheck so that it preserves the environment across runs, and have a trivial SetupHome directory [15:26] niemeyer: that would be better, of course. i didn't think gocheck changes were on the cards. [15:29] niemeyer: fancy doing it? [15:32] 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] rogpeppe: I'd prefer to solve the issue at once [15:43] niemeyer: ok, sounds good. [15:43] rogpeppe: Even because that whole thing is taking more time to talk about than to do it [15:43] rogpeppe: How many lines does this function have? 3? [15:44] niemeyer: about 26 all told [15:44] niemeyer: not including function headers [15:45] rogpeppe: :-) [15:45] rogpeppe: Put it in a loop and let's count again! [15:45] rogpeppe: No, seriously.. this is trivial [15:45] 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] niemeyer: and we agreed to do this [15:46] niemeyer: and now i've done it you don't like it, which is a bit galling [15:46] rogpeppe: Also, why are we creating .ssh and .juju directories? [15:47] rogpeppe: I've seen one or two places that create it [15:47] 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] rogpeppe: .ssh, specifically [15:47] niemeyer: so that we don't need to add attributes to every single place that creates a juju config [15:48] rogpeppe: I'm concerned that we continue to grow up stock harness [15:48] niemeyer: i'm concerned by the number of places we have to change if we change anything about the config. [15:49] niemeyer: a second or two at an absolute maximum, over all the tests, is not going to affect things badly. [15:49] % grep '"\.ssh"' * -r 2>/dev/null | grep _test | wc -l [15:49] 2 [15:50] niemeyer: try grepping for "authorized-keys" [15:51] rogpeppe: Yep? [15:52] niemeyer: almost every one of those is there because we can't use the usual config default of reading the .ssh directory. [15:53] niemeyer: i'm just about to add two more equivalent attributes [15:54] 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] 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] rogpeppe: Doesn't seem like an improvement at all to me? [15:56] 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] 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] niemeyer: yeah. :-| [16:25] 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] rogpeppe: Do we need to switch all the tests? [16:27] rogpeppe: What's the specific tests being implemented? [16:28] niemeyer: sorry, what do you mean by "switch all the tests"? [16:28] niemeyer: are you asking whether it's necessary to set up the directory for all the tests? [16:29] 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] rogpeppe: So supposedly there are quite a few tests there which do not need additional harness [16:30] niemeyer: yes, that's true. should i split the suite? [16:30] rogpeppe: Can we do nothing? [16:30] 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] niemeyer: personally, i think that would clutter the code quite badly [16:31] 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] 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] rogpeppe: Can we talk about the problem we're solving? [16:33] niemeyer: ok [16:33] rogpeppe: You continue to ask my opinion without context [16:33] niemeyer: i'm trying to add some values to the environs.Config [16:33] rogpeppe: Why? [16:34] rogpeppe: nothing in the conversation we had in UDS requires changes to Config, IIRC [16:34] niemeyer: so that we can specify the tls root certificate in environments.yaml [16:34] rogpeppe: That's not what we discussed? [16:34] 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] rogpeppe: Nope [16:35] rogpeppe: We never talked about any changes in environments.yaml [16:35] niemeyer: ok, so... we [16:35] 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] niemeyer: ok, so... how do we know what the root certificate is? [16:36] rogpeppe: Oh no [16:36] rogpeppe: Please tell me you still remember the conversation we had at UDS.. :-( [16:36] niemeyer: i thought i did [16:36] * niemeyer saddens [16:37] 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] rogpeppe: Yep, it generates it [16:38] niemeyer: ok, so what about the next time, when we connect to the environment again? [16:38] rogpeppe: We read it from disk [16:38] niemeyer: juju.Conn reads it from disk? [16:38] rogpeppe: Man.. we did talk about this before [16:39] rogpeppe: We talked even about what the parameters should be [16:40] niemeyer: ok, i've obviously distorted over the last week [16:40] niemeyer: please outline very briefly what you understood from our conversation [16:41] niemeyer: hold on, are you saying that there should be no way of making a juju connection without having a home directory? [16:41] rogpeppe: We need to pass some information into it so that we can decide what to use [16:42] rogpeppe: IIRC we also agreed that if we provided nil, we'd automatically read the file [16:42] niemeyer: scratch that [16:44] * rogpeppe thinks [16:45] niemeyer: so we don't want to allow people to have different root CAs for different environments? [16:47] 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] 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] niemeyer: i'm sorry if i've derailed. [17:16] *: So, I'm stepping out. [17:16] niemeyer: can we perhaps G+ this, before i go further awry? [17:16] Aram: Thanks for the detailed informations, we'll continue tomorrow. [17:23] 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] s/recording/record/ [17:23] niemeyer: that certificate and key being independent of the root cert and key [17:24] 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] rogpeppe: I think our previous model still holds [17:51] rogpeppe: There's no need to put anything in environments.yaml.. the user shouldn't have to do that [17:58] 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] niemeyer: does that make more sense to you? [18:05] niemeyer: slightly modified: http://paste.ubuntu.com/1356050/ [18:07] rogpeppe: Looking [18:07] 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] rogpeppe: So there's no reason to change Config.. [18:08] rogpeppe: authorized-keys handles a file that is not juju-specific [18:09] / generated and written to $HOME/.juju/-temp-cert.pem [18:09] rogpeppe: Why temp-cert? [18:10] / The temporary root certificate is required only [18:10] / for the first connection to a juju environment. [18:10] 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] rogpeppe: I'm sure we've agreed to not do this dance at UDS [18:11] niemeyer: yeah, ok, that's cool [18:11] rogpeppe: Was that a different Roger I was talking to? :) [18:11] niemeyer: one that has been looking at the wrong set of notes, it seems :-) [18:13] rogpeppe: Yeah, lesson taken here.. I should certainly not have assumed that the conversation would be enough [18:14] niemeyer: ok, updated version: http://paste.ubuntu.com/1356068/ [18:16] 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] rogpeppe: Stuffing things in the configuration to avoid parameters to a function is poor reasoning [18:19] rogpeppe: We should put that in the environment configuration if we're indeed using that as an environment setting [18:19] 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] niemeyer: but tbh changing the configuration is a right pain, so i'm happy to go this way [18:20] 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] niemeyer: we can get rid of that when we talk directly to the our own servers, i think [18:20] 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] 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] niemeyer: anyway, does the above API look reasonable to you? [18:26] rogpeppe: Yeah, it doesn't say how started machines get their cert, but what's there looks good [18:26] niemeyer: do started machines have a cert? [18:26] niemeyer: rather, will they? [18:26] rogpeppe: Oh nos [18:27] niemeyer: i thought we were using passwords for client identification [18:27] rogpeppe: Why do we need a root cert? [18:27] niemeyer: so that clients know who they're talking to [18:27] rogpeppe: and how does that happen? [18:28] niemeyer: via TLS. [18:28] niemeyer: no client certificate necessary there. [18:28] rogpeppe: Yes, and how can TLS verify that the client is talking to the right server [18:28] niemeyer: because it verifies that the server holds a private key and the certificate that certifies that key [18:28] niemeyer: do started machines have a cert? [18:28] niemeyer: because it verifies that the server holds a private key and the certificate that certifies that key [18:29] niemeyer: ah, started state machines, yes. [18:29] niemeyer: others don't need a cert. [18:31] niemeyer: perhaps we should just make the private key and certificate available in the state. [18:32] niemeyer: then a started machine that needs to become a state server can fetch it when necessary [18:33] niemeyer: no need for any additions to the above API if we do that. [18:35] niemeyer: gotta go. i hear a voice from below. tomorrow i will move forward as discussed. [18:35] rogpeppe: We've already discussed this at length before [18:35] rogpeppe: My opinion is still the same [19:30] niemeyer: I have another CL for you, but I'm not sure if you will like this one... [19:31] fss? [19:31] 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] niemeyer: https://codereview.appspot.com/6850044/ [19:31] fss: I won't like it or dislike it either :) [19:32] fss: I'm interested on the concept, though [19:32] fss: How was it done? [19:32] niemeyer: actually, we don't mind if it does not get merged, but some deadlines pushed me to do so [19:32] fss: That's certainly fair [19:33] fss: It might even get merged [19:33] fss: But ideally we should have talked about that beforehadn [19:33] fss: How was the change done? [19:33] niemeyer: I see, sorry about that :-) [19:34] niemeyer: we've added two new environment settings: vpc_id and subnet_id [19:34] at this point, every machine in an environment is launched in the same subnet_id [19:34] fss: How do you handle private ip vs. public ip? [19:37] niemeyer: that's a good question, I don't handle this yet :-( [19:37] fss: Okay [19:37] fss: Yeah, looks like a few things there [19:37] niemeyer: well, I will work on this now. What approach would you suggest? [19:37] fss: Expose? [19:41] fss: What about juju expose? [19:41] niemeyer: hmm, I didn't look at that too =/ [19:42] fss: Okay, there are a few complicators for an actual implementation [19:43] fss: The subnet_id/vpc_id must also be internally managed [19:43] 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: my terminal was freak, sorry [19:44] 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: np [19:44] That was about [19:44] fss: The subnet_id/vpc_id must also be internally managed [19:45] niemeyer: I see, but how would juju manage it? creating new vpc's and subnet's? [19:49] fss: Yeah, I haven't really detailed anything [19:49] fss: in my mind, that is [19:49] 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] fss: So that necessarily means managing vpc's, subnet's, and I suppose elastic IPs [19:50] fss: Which makes it somewhat involved [19:50] 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] fss: But we'll have to really put some thinking in place and actually do it [19:51] fss: Well, you can bootstrap the environment, and then do whatever, I think [19:51] niemeyer: I see [19:51] fss: Am I missing important details there? [19:53] 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] fss: Sounds like a reasonable scenario [19:55] 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]