[03:40] niemeyer: error: Get https://api.launchpad.net/devel/people/+me: x509: certificate has expired or is not yet valid [03:52] andrewsmedina: I get Object: , name: u'+me:' [03:59] niemeyer: Im trying to send a proposal with lbox and returns this error [04:03] andrewsmedina: Ok, not sure then [04:04] andrewsmedina: Please ping me tomorrow if you still have the issue.. I really need some bed time now [06:35] davecheney: yo! [06:36] rogpeppe: howdy [06:36] you've got some commits to make my man [06:36] brilliant [06:36] gustavo green lighted a heap of branches overnight [06:37] I would also be very keen to hear your feedback on my proposal for the provisioning agent [06:38] davecheney: i only see one actually, but maybe i'm missing something [06:38] rogpeppe: the ConfigNode one got the tick [06:38] what about upload-tools ? [06:38] davecheney: i already submitted the confignode one [06:39] ok [06:39] davecheney: i'm interested in feedback on https://codereview.appspot.com/6213050/ [06:39] * davecheney looks [06:50] davecheney: any particular reason that ProviderService is an interface? [06:50] So I can mock it [06:50] you could make an argument either way [06:50] it's still a wip [06:51] davecheney: i'm wondering if there's a need to mock it when we can mock the state itself. [06:51] rogpeppe: indeed, there are probably other ways to do it [06:56] rogpeppe: but putting that to one side, do you have any comments on the use of the an internal goroutine which insulates callers from the environ reloading ? [06:56] davecheney: i think it looks good. [06:56] davecheney: although i'm still mulling over the implications [06:56] understood [06:57] rogpeppe: when I sat down yesterday and realised I had two loops of control going on at once; the machines watcher and the environ watcher [06:57] it appeared simpler to model it this way [06:58] there are also interesting possibilities to introduce paralism [06:59] rogpeppe: also, rewriting machine watcher (again), https://codereview.appspot.com/6210066/ [07:00] davecheney: i guess i'm slightly surprised that the machines watcher doesn't just watch the environs config too [07:00] davecheney: it looks like you've still got two loops of control going on [07:01] davecheney: although i may misunderstand how AddMachine etc are intended to be used. [07:01] rogpeppe: s/AddMachine/StartInstance/g, s/RemoveMachine/StopInstance/g [07:01] I should have used better names [07:02] davecheney: i don't think that affects the point though. who's calling those methods? [07:02] rogpeppe: provisioning.go [07:03] rogpeppe: it also just occured to me, why don't I just implement the environs.Envrion interface [07:03] davecheney: we've got dummy for that, perhaps. [07:03] the goal is to buffer callers to those methods from having to deal wit the fact the environ is not ready/available [07:03] davecheney: that's only right at the start though, yes? [07:04] davecheney: can we do anything at all until that happens, in fact? [07:06] rogpeppe: hmm, the way gustavo explained it, we have to deal with the fact that environ can change at any time [07:07] davecheney: that's no problem i think. i'll paste a little pseudo code to try and explain what i'm thinking. [07:07] kk [07:11] davecheney: http://paste.ubuntu.com/993735/ [07:11] davecheney: as a very rough sketch [07:11] rogpeppe: yup, that is what I had first [07:11] davecheney: so where's the other loop of control? [07:12] so, what happens if case e := <-envWatcher: env = e [07:12] fires, and the env is now broken or nil [07:13] also, once c := <-configWatcher has fired, we need to keep trying that action until it succeeds, or the process exits [07:13] so, if e is broken, then we need to put c somewhere, then come back to it when e is not broken [07:14] davecheney: two possibilities: either you loop inside that arm of the select when env is broken, until it's not; or you introduce another goroutine so that only valid environments are send on the env watch channel [07:14] rogpeppe: I think i've implemented the latter [07:15] rogpeppe: but sort of inside out [07:15] davecheney: yeah [07:15] davecheney: i *think* things would be clearer (and probably smaller) if the extra goroutine *just* did that - another component in the pipeline, with no side effects. [07:16] rogpeppe: hmm, i do like simplicity [07:16] and it would resolve the requirement to have two stages, waiting for the first environ, then acting on changes [07:17] rogpeppe: you are right, that is a lot simpler [07:17] davecheney: we have to decide if having an invalid environ should cause the provisioning agent to stop until it's valid, or continue with the old, valid environ [07:17] rogpeppe: that could be the blocker [07:17] davecheney: my problem with the current proposal is that there are really two loci of control, and i think that's awkward. [07:17] davecheney: both are possible, i think, and not hard. [07:18] davecheney: we just have to decide what semantic we actually want [07:18] rogpeppe: in your env <- channel approach, you always have _an_ environ; but there is no way to give it a broken one [07:18] in my approach, you always hold a proxy environ, which may block calls through it if the undernlying environ is invalid [07:18] davecheney: in that case, you choose the first approach i mentioned [07:19] davecheney: "loop inside that arm of the select when env is broken, until it's not" [07:19] rogpeppe: i need to ponder this [07:19] davecheney: that automatically excludes the other part of the select from acting on it. [07:19] i like your approach, it's less code and clearer [07:20] davecheney: cool. [07:21] rogpeppe: i guess it comes down to 'what is broken' [07:21] davecheney: yes - and "what do we want to do about that?" [07:21] i see there are two kinds of broken, one is missing key fields, basically unyaml'ing "" [07:22] the other is valid, but incorrect, so incorrect AWS credentials [07:22] which I don't think is invalid, tf/ it shuld be passed to the provisioning agent, and provisioning attempted against it [07:23] davecheney: yeah. so the first *should* never happen. a goroutine filtering out those occurrences and logging them would probably be fine. [07:23] rogpeppe: i think it's the opposite [07:23] the first will always happen [07:23] davecheney: agreed. i don't think you can tell otherwise. [07:23] davecheney: really? [07:23] when the provisioning agent starts up, /environment is "" [07:24] yes, but that's a special case at the start, which we cater for specifically [07:24] it has to wait until it gets a config node that is properly formed [07:24] we wait until that time has passed before entering the provisioning loop proper [07:24] what about when we're *in* the loop? [07:24] i don't *think* we should see it then [07:25] unless something else fucks up [07:26] davecheney: BTW what happened to our idea of having a goroutine per machine? [07:27] rogpeppe: kinda fell in a heap when I understood that environment could change over time [07:28] davecheney: hmm. i *wonder*... we could just model the environ as a global variable, guarded by an RWMutex. [07:28] rogpeppe: that is what I was aiming for with the ProviderService [07:28] by communicating with it via a channel, it has a mutex of sorts [07:28] it only accepts your commands when it's in a state to act on them [07:29] otherwise they block [07:30] * rogpeppe thinks [07:33] davecheney: thing is, if we want any concurrency at all, when the environment changes, there are still going to be actions acting on the old environment. [07:34] rogpeppe: i agree [07:34] davecheney: which i think is ok. we just want to make sure that any new actions use the new environment. [07:34] rogpeppe: so actions on the Environ are going to fail, and should be retried (via some business logic) [07:35] so the key will be they can pick up the new value of Environ [07:35] rogpeppe: which sort of leans me back to my original proposal this morning [07:35] davecheney: exactly - we need to distribute the new Environ to everyone [07:35] 'except i'll make it implment a full proxy Environ, so you can just keep retrying against the proxy. [07:36] davecheney: i think it's quite a lot of code for something that's really just a mutexed global variable at heart. [07:38] davecheney: and if you do it that way, we can keep the original vision of having a separate goroutine for each machine, right at the heart of the provisioning agent. [07:38] rogpeppe: here is a quick stab at your version, http://paste.ubuntu.com/993760/ [07:39] rogpeppe: yes! so each 'machine' proxy has a channel for commands, provision yourself, deprovision yourself [07:39] and those commands talk to the Environ proxy [07:39] davecheney: yeah [07:40] and they retry according to some business logic [07:40] that would solve one of my concerns about running adds and deletes in parallel [07:40] davecheney: yeah [07:40] this has been very useful [07:40] davecheney: great! [07:40] unfortuntely i'm going out in 20 minutes [07:41] but i'll hack on this when I get home [07:41] davecheney: np, i'm glad i got up early... [07:41] what time is it in +1 over there ? [07:41] it's 17:40 [07:41] davecheney: 0841 [07:42] right [07:43] davecheney: thanks for the comments on the simplified provider interface, BTW [07:43] rogpeppe: i think i attempted a half assed version of that when I did environ.NewEnviron, but ended up backing out most of it [07:44] davecheney: it seems to mesh well. and i think the overall line count probably dropped, which is always a good sign... [07:45] never hurts [07:46] davecheney: i like the fact that Check now matches NewEnviron. and when we have Marshal, that'll return the same type too. [07:48] rogpeppe: now that is good, and less untyped interface{}'s [07:48] davecheney: defo [07:51] davecheney: BTW in the provisioning agent, i *think* you'll only want one channel to the machine goroutine - to remove the machine. [07:51] rogpeppe: yeah, i'll be doing some surgery on that tomorrow [07:51] but for now, it's good night from me [07:51] davecheney: have a good one! [10:18] fwereade: ping [10:21] rogpeppe, pong [10:21] fwereade: hiya [10:21] rogpeppe, (landing stuff doesn't count as working :p) [10:21] rogpeppe, heyhey [10:21] ? [10:21] rogpeppe, but I am actually about to stop ;p [10:21] ah... [10:21] rogpeppe, I'm off until weds now :0 [10:21] cool [10:22] fwereade: just wondered if you could clarify about the machine key stuff, but don't worry if you're stopping [10:22] rogpeppe, regardless, what can I do for you while I'm here? [10:22] rogpeppe, it's just a vague sense that the correspondence between keys and ids feel coincidental rather than fundamental [10:22] fwereade: what is a machine key? [10:22] fwereade: i know about machine ids and instance ids [10:23] but not machine keys... [10:23] rogpeppe, it's the node name in zookeeper [10:23] rogpeppe, machine-0000000001 [10:23] fwereade: and that's not named after the machine id? [10:24] rogpeppe, it feels to me that that's an accident of happenstance rather than a fundamental truth [10:24] fwereade: it's not always fmt.Sprintf("machine-%010d", machine.Id) ? [10:24] fwereade: what's primary? [10:24] fwereade: we talk about machine id 0 for the bootstrap machine, for example [10:25] rogpeppe, I guess it's just an idea that juju ids *ought* to increase "smoothly" rather than just monotonically [10:25] fwereade: what's the difference? [10:25] rogpeppe, just that the fact that we can end up skipping an id that's held by an orphan node has the feel of a leaked implementation detail [10:26] fwereade: when are we going to add more than 1 to the new machine id? [10:26] ah [10:26] rogpeppe, and that the platonic ideal of juju would have machines 0-N without skipping any [10:26] fwereade: when do we get an orphan node? [10:26] rogpeppe, when something bad happens after the node has been created but before the topology is updated [10:26] "something bad"? [10:27] rogpeppe, someone trips over a network cable, say [10:28] rogpeppe, this is not something I'm strongly invested in though [10:28] rogpeppe, I think I'm -0 rather than -1 [10:28] fwereade: i'm slightly surprised that the node is created *before* the topology is changed. [10:28] rogpeppe, the topology needs to know which node it's pointing to [10:28] fwereade: that doesn't square with my understanding of the way things work, but that's fairly sketchy! [10:29] rogpeppe, if we update the topology first, we can't guarantee what the next sequence node will be [10:29] fwereade: the topology doesn't just talk about "machine 0", "machine 1", etc? [10:30] rogpeppe, I'm pretty sure it knows which keys it's pointing to, but I could be on crack [10:30] fwereade: so the machine-000001 node name can skip numbers, but not the machine id, right? [10:30] rogpeppe, coincidentally they do always correspond IIRC [10:30] fwereade: what about orphans? [10:30] rogpeppe, they're just trash [10:31] rogpeppe, they don't exist according to the topology, which is the sole source of truth [10:31] fwereade: what are they named? [10:31] rogpeppe, they would, I think, be named after the key; but they don't exist so the question is philosophically shaky ;) [10:31] fwereade: i'll try to explain what i think i understand, and perhaps you can tell me if i'm more-or-less right [10:31] 1) someone calls add-unit [10:32] 2) the client adds a machine node to the state [10:32] 3) the client adds a topology node referencing the new machine node [10:32] rogpeppe, I think so, yeah [10:32] 4) the provisioning agent sees the change to the topology node and starts a new instance [10:33] rogpeppe, exactly [10:33] 5) the new machine registers that it's up in its machine node. [10:33] so the problem with orphan nodes happens if the network breaks between 2) and 3) [10:34] rogpeppe, probably, I forget the details of the machine agent; I think it has a separate presence node [10:34] rogpeppe, yeah [10:34] rogpeppe, sorry: but lunch is on the table [10:34] fwereade: ok [10:34] fwereade: one last question to ponder: [10:34] rogpeppe, may have a moment before I leave later but don;t count on it [10:34] * fwereade listens [10:34] fwereade: why doesn't the provisioning agent allocate the new machine node? [10:35] fwereade: anyway, enjoy your time at home! go to lunch! (early lunch, BTW! i've just had breaky...) [10:36] rogpeppe, I can't think of a good reason, that may be a nicer way to do it [10:36] I'll think :) [10:36] rogpeppe, train at proper lunchtime :) [10:36] rogpeppe, cheers [10:36] fwereade: ttfn [11:23] there ought to be a word for the noise a branch makes when landing. [13:30] GOod morning all [13:39] niemeyer: hiya! [13:39] niemeyer: pretty quiet around here... [13:39] niemeyer: thanks for okaying that huge branch BTW [13:46] rogpeppe: Yeah, quiet indeed [13:46] rogpeppe: Must be Friday :) [13:46] rogpeppe: I'm just sipping some chimarrão and going over the inbox for a moment [13:46] niemeyer: fwereade's on hols. don't know about TheMue [13:46] mthaddon: Thanks for checking out that charm [13:47] rogpeppe: He said he'd be out too.. don't recall if he'd be back today or not [13:47] niemeyer: i'm thinking about refactoring dummy a little [13:47] rogpeppe: I think it's fine for the moment.. [13:47] niemeyer: i realised that i wanted it to serve urls (for the storage URL service) and it's awkwardly structured for that [13:48] rogpeppe: I'd prefer to keep pushing forward, and then get back later once we have some more use cases known [13:48] rogpeppe: Hmm [13:48] rogpeppe: What's the issue? [13:49] niemeyer: the difficulty is that we now want two storage services from the same dummy environ [13:49] rogpeppe: How's that a problem? [13:49] niemeyer: and the way environ is the same as storage doesn't work too well with that [13:50] rogpeppe: Ah, I see, yeah, might be good to have that fixed [13:50] niemeyer: and i realised that really the environ shouldn't be recreated with every Environ.Open [13:50] niemeyer: it should be shared, as part of state. [13:50] niemeyer: so... [13:51] niemeyer: that means that we can't take all the environ settings from the environ config (otherwise that gives too much precedence to the first one parsed) [13:51] niemeyer: so... [13:51] rogpeppe: Hmm.. yeah, and it wasn't recreated..? [13:51] rogpeppe: That's what we had Reset for, right? [13:51] niemeyer: i'm thinking that perhaps Reset should take an argument which asks for the kind of capabilities we want [13:51] rogpeppe: I don't think that's necessary [13:52] niemeyer: so you can ask for a dummy env that mocks zookeeper, perhaps (in the future), or serves a storage web server, or has a required field in the config [13:53] niemeyer: at the moment all those things are determined by the provider config, which seems slightly wrong. [13:53] rogpeppe: I don't think that's necessary.. config is passed onto Open.. mocking ZooKeeper is not on the table right now, and serving a storage web server may be done a single way [13:53] rogpeppe: There's really no great reason to increase the number of knobs there [13:54] rogpeppe: Why is it wrong ? dummy is a provider.. and you're talking about configuring it [13:54] rogpeppe: I'd like to make it simpler, not more complex [13:54] niemeyer: because the configuration is shared; the configuration is used to connect to it, not create it. [13:55] niemeyer: also, i was slightly hoping to avoid starting a new web server on every Reset. but i guess that's ok really. [13:57] niemeyer: it currently seems slightly bogus that i require a zookeeper attribute on all dummy environ configs, just so i can check that starting an environment with a missing attribute fails correctly. [13:58] [14:54:39] niemeyer: because the configuration is shared; the configuration is used to connect to it, not create it. [13:58] that was badly said [13:58] i meant "the environment is shared" [14:18] evening. [14:19] Aram: Heya [14:20] niemeyer: Hi [14:39] andrewsmedina: Yo [14:43] rogpeppe: Re. https://codereview.appspot.com/6203083/, did you discuss ideas with Dave this morning? [14:44] niemeyer: yeah. we came up with something quite nice i think. [14:44] rogpeppe: That's great, thanks a lot [14:44] niemeyer: i could paste the relevant log if you like [14:44] rogpeppe: I'll mark the branch as WIP [14:44] rogpeppe: I'm happy to wait for the result of it [14:44] niemeyer: i think it should be marked as that anyway - at least that was his intention [14:45] niemeyer: did you take a look at https://codereview.appspot.com/6213050/ ? [14:45] Ah, and so it is [14:45] niemeyer: it's my "i have an idea" from the other evening [14:45] rogpeppe: Not yet.. it's the largest branch in the queue, so I've been reviewing the others first [14:45] niemeyer: np [14:46] rogpeppe: But I'll get there [14:46] We should dial back the branch sizes.. yesterday most of them were over 400 lines [14:46] (of diff) [14:47] niemeyer: BTW the tests are broken at the moment. i think william forgot to run tests before submitting... [14:47] rogpeppe: Cool, we should get a fix in soon [14:48] niemeyer: i wanted to but the fix wasn't immediately obvious to me and i'm trying to get this stuff proposed. [14:48] niemeyer: only problem is, in integrating the previous branches, i want to insert a branch before one i've already proposed... it's a pity that's not easy. i'll just not stack them, i think, and mark the last one as WIP [14:51] niemeyer: some of the diffs are made larger by the fact that not everyone runs gofmt before proposing/submitting. [14:52] niemeyer: some time it might be nice to make lbox fail if go files aren't gofmted. [14:53] rogpeppe: I generally try to make branches independent when pushing my own work [14:53] rogpeppe: Tends to pay off in these cases [14:54] niemeyer: me too, but in this case, the reason i want to insert a branch is because i want to use some of that functionality in the upcoming branch, but don't want to bloat it. [14:54] rogpeppe: Well, in that case there's no choice.. just propose the branch and put the follow up as WIP or repropose with pre-req [14:55] niemeyer: can't change the prereq once proposed, sadly [14:55] i think [14:55] i'll just wait until the prereq is submitted [15:04] Cool [15:14] Lunch! [16:47] niemeyer: here's the prereq: https://codereview.appspot.com/6209078/ [16:49] rogpeppe: Checking [17:02] niemeyer: it's time for me to go; have a great weekend! [17:03] rogpeppe: For you as well.. almost finishing the review [17:03] niemeyer: great, thanks a lot [17:03] rogpeppe, have a good one [17:05] hazmat: and you. you still up for that editor challenge BTW? :-) [17:06] rogpeppe, anytime! :-) [17:07] hazmat: alright, i'll see how much sublime costs and whether i can deal with it... [17:07] * hazmat wonders if he should start recruiting some ringers for the challenge [17:07] rogpeppe, its free to try out [17:07] hazmat: ringers? [17:07] rogpeppe, experts posing as novices [17:08] rogpeppe, so wait.. i have to learn acme then? [17:08] :-) [17:08] hazmat: that's the deal [17:08] * hazmat forget the challenge details [17:08] hazmat: acme exclusively for a month [17:08] hazmat: well, apart from when it's not possible [17:08] rogpeppe, not this month then [17:08] rogpeppe, incidentally how do you install it? [17:09] hazmat: grab the plan9port tarball, run INSTALL [17:10] rogpeppe, cool thanks [17:10] rogpeppe, yeah.. i'm under some tight deadlines, so not this month, but i'm game [17:11] hazmat: i am too (he says, worried about dropping productivity :-]) [17:11] http://swtch.com/plan9port/plan9port.tgz [17:11] anyway, gotta go [17:33] niemeyer: I still could not send the proposal [17:33] andrewsmedina: Ok, let's see then [17:33] andrewsmedina: What's going on? [17:39] niemeyer: http://dpaste.org/XKeHn/ [17:42] andrewsmedina: Try to load https://api.launchpad.net/ in your browser [17:42] andrewsmedina: What OS and OS version are you using? [17:42] niemeyer: ubuntu and centos [17:42] andrewsmedina: At the same time!? :-) [17:43] niemeyer: yes, with vms :) [17:43] andrewsmedina: I mean where is this command failing [17:44] andrewsmedina: On both? [17:44] niemeyer: I tryed do a wget http://paste.ubuntu.com/ [17:44] niemeyer: I tried on ubuntu and centos [17:44] ubuntu 12.04 [17:44] andrewsmedina: Ok, that's pretty weird [17:45] andrewsmedina: Are you under a proxy? [17:45] andrewsmedina: Could the proxy be getting in the way of the https connection? [17:46] niemeyer: I dont use proxy here [17:46] andrewsmedina: Wow, do you develop as root? [17:47] niemeyer: :-p [17:47] andrewsmedina: Can you see my look of disapproval from there? ;-) [17:48] niemeyer: I use "andrezias" user to (on ubuntu). But in centos I use root :-p [17:48] andrewsmedina: Can you please try to wget from https://api.launchpad.net/devel/branches? [17:48] andrewsmedina: Tsc tsc :) [17:50] niemeyer: same result [17:50] http://paste.ubuntu.com/994583/ [17:55] andrewsmedina: Sounds like you have a bad set of certs [17:55] andrewsmedina: Have you tried to update your installation? [17:58] niemeyer: installation of? [18:01] andrewsmedina: Of your OS [18:03] why? how so version can affect the launchpad certs? [18:04] so == OS :p [18:15] andrewsmedina: The certificates that are used to verify the validity of a given site certificate are installed in your disk [18:16] niemeyer: humm.. my vms are headless [18:17] but I already used lbox another times without problem [18:18] andrewsmedina: Why is it an issue that your vms are headless? [18:25] niemeyer: when lpad tell do aprove the req I opened it on my mac os ( :-p ) [18:25] andrewsmedina: This is irrelevant for the problem.. the certificates within the vms must work too [18:28] niemeyer: you're right [18:43] * hazmat lunches bbiab