[06:14] fwereade_: mornin'! [06:31] wrtp, heyhey [06:32] fwereade_: how's tricks? [06:32] wrtp, not too bad [06:33] fwereade_: BTW are you getting the initial mail for each codereview proposal? [06:33] fwereade_: i'm not, and i can't see what's going wrong. i've just been through all my mail filter patterns and can't see any likely candidate. [06:34] wrtp, hmm, yes, it looks like I am in general [06:34] wrtp, maybe something about LP? [06:34] fwereade_: i'm getting the initial '[Merge]' mail, but those [Merge] mails are so noisy i archive them immediately. [06:35] fwereade_: the strange thing is i see any replies [06:35] wrtp, ah, ok, that is weird then [06:35] fwereade_: so the first thing i'll know about any CL is when someone replies to it [06:35] yeah, it's odd, and quite annoying actually [06:36] wrtp, yeah, I bet :( [06:56] fwereade_: hmm, the odd thing is i do see *some* initial emails. Aram's and gustavo's seem to come through ok. [06:56] wrtp, heh that's even weirder [06:57] fwereade_: i wonder if there's a way to check in launchpad what messages it's sent me [06:59] wrtp, I doubt that sort of thing specifically is logger [06:59] Morning [06:59] wrtp, I bet we all have a subtly different combination of LP settings, and memberships of various things [06:59] TheMue, heyhey [06:59] fwereade_: can you think of a CL you've replied to recently that i wasn't involved in? [07:00] TheMue: yo! [07:04] wrtp, I don't think I have done much of that lately :( [07:04] fwereade_: hmm. TheMue? [07:05] wrtp: What? [07:05] TheMue: (i'm trying to work out why i'm not seeing some emails from launchpad) [07:05] TheMue: can you think of a CL you've replied to recently that i wasn't involved in? [07:07] wrtp: Have to look, but have to change systems fir it. [07:08] TheMue: any CL that someone else created and you replied earlier than me would do too [07:09] wrtp: If so, then mostly Williams CLs. [07:09] TheMue: one example would be good, if you could, thanks! [07:13] TheMue: here's an updated version of my firewaller sketch, BTW. http://paste.ubuntu.com/1087489/ [07:14] TheMue: i realised that tracking machine instance ids was unnecessary, because the OpenPort/ClosePort functions should operate on Environ with a machine id rather than on an environs.Instance. [07:15] wrtp: Great, thx, will today integrate it into the firewaller outline of dave [07:15] TheMue: good plan [07:18] TheMue: i'm not sure of a good way to build it up bit by bit though. i can't think of any useful tests for the intermediate stages. [07:18] wrtp: That has been my prob with the first approach. [07:19] wrtp: Now I'll use stubs for intermediate CLs [07:21] TheMue: i suppose you could put hooks in for the intermediate stages, to be removed later. but writing tests only to delete them later seems a bit wrong. [07:22] wrtp: No, the tests shall be the right ones and make the right asserts [07:22] TheMue: yeah, and the problem is that the only observable side-effects of this code are the calls to OpenPort/ClosePort [07:22] wrtp: But while they first may get constants it will get more and more live with each iteration [07:23] TheMue: which won't happen until all the rest is there. [07:23] wrtp: So the tests verify the impl [07:24] wrtp: See the current approach. I've used an interface and a mock for call verification. [07:25] TheMue: the first stage AFAICS is to get the machine watcher done. but there are no calls to anything when the machine watcher fires, so no verification to do AFAICS [07:25] TheMue: i suppose you could put in a fake call to OpenPort for the time being, to be changed later. [07:27] wrtp: Yep, that's what I meant. The Py firewall gets a provider and I reduced it to the three methods of the PortManager interface. Will see how I can temoporarilly inject something similar here and remove it later. [07:42] TheMue: i'm doing the port manager implementation in ec2, and i think the Environ port manager interface might look something like this: http://paste.ubuntu.com/1087531/ [07:42] wrtp: So, changed client. === TheRealMue is now known as TheMue [07:43] TheMue: did you see my message a few seconds ago? [07:43] oh yeah, you should've [07:43] wrtp: About the port manager interface? Yes, just looking at it [07:44] TheMue: in fact, scratch that, i think it's not easy to implement well in ec2 [07:45] wrtp: So SetPorts() would ensure that only the passed ports are open afterwards? [07:45] TheMue: yeah, but i think it's wrong [07:46] TheMue: i think this is better: http://paste.ubuntu.com/1087535/ [07:46] wrtp: Today the FirewallManager retrieves the current real state, compares it to the wanted state and builds the diffs to explicitely open and close the ports. [07:46] TheMue: i don't think it needs to do that [07:47] TheMue: apart from at the very beginning [07:47] wrtp: ??? [07:47] wrtp: The new interface matches exactly to that. [07:47] TheMue: it only needs to do the diff once, when the firewaller starts up, i think. [07:48] TheMue: from then on it knows the "real" provider state, and can just apply OpenPorts and ClosePorts methods as the State changes [07:49] TheMue: i.e. it will need to call Ports once only [07:49] wrtp: Understand, yes. [07:49] wrtp: In todays model the provisioner called individual methods after each service and machine change, so a different approach [07:50] TheMue: yes - the difference is that, if you follow my sketch, we keep track of the state in one place, so we know exactly what's going on at all times [07:52] TheMue: BTW the reason that SetPorts is a bad idea is that the ec2 primitives are AuthorizeSecurityGroup and RevokeSecurityGroup - there's no way to set the entire set of permissions of a security group at once. [09:15] fwereade_, TheMue: what do you think should happen to a machine's open ports if it's restarted on a different instance? [09:16] niemeyer: ^ [09:17] niemeyer: mornin' BTW [09:21] wrtp, hmm, given that that *can* happen... are we not in a situation where we *cannot* depend on our local state to know what ports are really open? [09:21] wrtp, this is not a solution but it does maybe feel like a fundamental problem with the maintain-local-state approach... [09:21] niemeyer, morning [09:22] fwereade_: as currently conceived, the machine's open ports are independent of its instance [09:23] fwereade_: but currently when a new instance is started, it ensures that the machine's group has no permissions [09:23] wrtp, I think that is a restatement of the problem? [09:24] wrtp, the *obvious* answer is to put a watch on a machine's instance ID, but I'm not sure it's a *good* one [09:24] fwereade_: yeah, i think that's right [09:24] wrtp, however I don;t think we have any other way of telling [09:24] wrtp, wait a mo [09:25] wrtp, is it easy to reuse the security group from the original machine? [09:25] fwereade_: i think perhaps it's up to the provisioner to change the port settings for a machine when it starts an instance [09:25] fwereade_: it *doesn* use the security group from the original machine [09:25] s/doesn/does/ [09:26] fwereade_: but currently it will zero the perms when the instance starts [09:26] wrtp, ah, but it clears it out? [09:26] yeah [09:26] fwereade_: i'm thinking that it shouldn't [09:26] wrtp, hmmmmmmm, so, consider the lifecycle of the unit agent on the new machine [09:26] wrtp, that will start up, open ports, blah blah [09:26] * wrtp is considering [09:26] wrtp, won't it Just Work already? [09:27] wrtp, I think it might :) [09:27] fwereade_: it would *if* all the security groups from a previous instance of the environment had been destroyed [09:27] fwereade_: but i'm not sure we can guarantee that [09:28] fwereade_: thus i think that when starting a new instance, the PA should perhaps call Ports and ClosePorts to clear out any old cruft [09:28] s/starting a new instance/starting a new machine/ [09:29] fwereade_: i *think* that would solve the problem [09:29] niemeyer_: yo! [09:29] wrtp: Kind of CloseAllPorts() sounds good, yes [09:29] TheMue: env.ClosePorts(m, m.Ports()) [09:29] TheMue: (with error checking of course :-]) [09:30] wrtp, I'm confused: I thought you said that the perms *were* zeroed whenever we start an instance [09:30] TheMue: that's essentially what it does now, behind the scenes [09:30] fwereade_: they are, by the ec2 environ [09:30] fwereade_: but that means we can create a new instance for an existing machine [09:30] wrtp, ok, so what doesn't already do the Right Thing? [09:30] wrtp: You can't pass m.Ports() [09:31] TheMue: m.Ports would return an error [09:31] oops, env.Ports(m) of course [09:31] wrtp, if and when that machine needs some ports opened, it'll do an open-port in a hook, and... oh [09:31] wrtp, the unit will say "meh, those ports are already open, no state changes here!" [09:31] fwereade_: this was the source of my original question [09:32] fwereade_: i'm not sure what behaviour we *want* here [09:32] fwereade_: perhaps a new instance *should* always come up with no open ports [09:32] wrtp, so actually we need the unit agent to realise when *it* is being started on a fresh machine, and clear out its own ports to begin with, so the Right Thing happens when the hooks reopen them [09:33] wrtp, I think new instances should certainly come up with no open ports [09:33] wrtp, I'm pretty sure the difficulty is at the unit agent level [09:33] fwereade_: given that the PA is starting the new instance, it's in a good position to clear out the ports first [09:33] wrtp, I thought that always happened already? [09:33] wrtp: Exactly [09:33] fwereade_: it does currently, but i wasn't sure if it should [09:34] wrtp, I guess that ideally this *should* be done by the PA rather than by the environ [09:34] fwereade_: i'm now thinking the current behaviour is correct [09:34] fwereade_: well, yeah [09:34] fwereade_: that would seem better [09:34] wrtp, because then we won't need every single environ to mess with ports on instance start [09:35] fwereade_: well, the same code will be executed - it'll just be called from the PA [09:35] ahh, but... [09:35] wrtp, yeah, but we only have to write it once instead of N times [09:35] this all interacts with the firewall code [09:36] wrtp, and the firewall code will then get an inaccurate view of state? [09:36] because the firewall is keeping track of what ports are supposed to be open [09:36] fwereade_: yeah [09:36] wrtp, I don't *think* it matters if we depend on the UA doing the Right Thing wrt closing all ports when it starts up on a fresh machine [09:36] wrtp: that's its task [09:37] fwereade_: actually, i think you're right [09:37] fwereade_: if the UA does it, we have no problems [09:37] fwereade_: and the firewaller doesn't have to keep track of instance ids [09:37] wrtp, yep, think so [09:38] fwereade_: then *all* port opening and closing is done via the state open/close port [09:38] wrtp, yeah, exactly [09:38] wrtp, the firewaller can watch that alone and it'll catch up when it becomes important to [09:38] fwereade_: and the environ won't clear out ports when starting a new instance [09:39] wrtp, the environs should still clear out ports [09:39] wrtp, ah wait [09:39] yeah [09:39] there's a difficulty [09:40] no, it's ok i think [09:40] fwereade_: the PA clears out ports when it starts a new *machine* [09:40] fwereade_: because machine ids are never reused [09:41] fwereade_: thus we ensure that all new machines start in a known state, and the firewaller can track them properly. [09:42] wrtp, I think that clearing them at *instance* start time is the Right Thing: I don't see any benefit to keeping the ports open while launching the machine [09:42] wrtp, the UA will clear out the desired ports in state when it comes up [09:42] wrtp, and at that point the firewaller will be back in sync [09:43] fwereade_: yes, that sounds reasonable [09:43] fwereade_: if *slightly* tricksy [09:44] fwereade_: i think StartInstance should document that the ports for the machine id will be closed when it's called. [09:45] wrtp, honestly this feels like a job for an Environ struct type that tells an internal EC2-or-whatever env to (1) StartInstance, (2) CloseAllPorts [09:46] wrtp, StartInstance having to magically mess with ports in every provider STM like a recipe for bugs [09:46] fwereade_: s/struct type/function/ ? [09:46] wrtp, IMO having the real environ accessible for people to mess with is similarly a recipe for bugs, but YMMV [09:46] fwereade_: my mileage does :-) [09:47] fwereade_: tbh i'd be happy for the PA to implement that logic [09:47] wrtp, IMO `env.StartInstance(...` rather than StartInstance(env, ...` not not sufficiently obviously a bug [09:47] fwereade_: it's very straightforward, and then there's no hidden interaction between StartInstance and ClosePorts. [09:48] fwereade_: nothing else calls StartInstance [09:48] afaik [09:48] fwereade_: so there's really no need for another layer [09:48] wrtp, we'll see [09:49] fwereade_: for the time being, i'll implement Ports, OpenPorts and ClosePorts, and remove the port closing logic from StartInstance [09:49] fwereade_: i think that should be sufficient [09:50] wrtp, fwereade_: Heya! [09:50] niemeyer_: does that sound reasonable? [09:50] niemeyer_, heyhey [09:50] wrtp: Sorry, I wasn't following [09:50] wrtp: Breakfast made a lot of sense, though :-) [09:50] lol [09:50] wrtp, IMO any situation in which you're saying "a call to Foo must be immediately followed by a call to Bar" is a bug waiting to happen [09:51] * fwereade_ shrugs [09:51] niemeyer_: perhaps you could read over the recent conversation [09:51] fwereade_: only in the context of the provisioner is that true [09:51] wrtp: Will definitely do, but I have to take Ale to work first, as she's starting in a few minutes.. I'll be back soon, though [09:51] wrtp, and on bootstrap? [09:51] niemeyer_: np [09:51] fwereade_: that's just a specialised kind of provisioning :-) [09:52] wrtp, as you like [09:52] fwereade_: we're only talking about 3 lines of code in two places here... [09:52] wrtp: line 24 of http://paste.ubuntu.com/1087489/, how would you manage the watcher of all units for a machine? based on your outline I only see one per machine. [09:53] wrtp, one of which you apparently forgot about [09:53] wrtp, bug waiting to happen [09:53] fwereade_: there are many bugs waiting to happen :-) [09:54] wrtp, which is why in general I prefer to make the ones I can see unpossible ;p [09:54] TheMue: there's one units watcher per machine. then line 36 starts a new watcher for any new unit on a given machine [09:54] fwereade_: [09:55] * wrtp finds that less bugs come from less code [09:55] wrtp: ah, so I misunderstood the plural sentence [09:56] wrtp, I don't think we're going to convince one another here [09:56] TheMue: yeah by "machine units watcher" i meant a watcher to watch the units on a given machine [09:56] wrtp: That definitely makes more sense [09:57] fwereade_: you're probably right :-| [09:57] wrtp, fwereade_: have to be afk for a moment, once again daddy-daughter-taxi [09:59] fwereade_: there's just as many bugs waiting to happen with a Environ shim BTW - you'd need to remember to insert the shim that does the StartInstance magic. [09:59] fwereade_: and then that shim wouldn't strictly implement environs.Environ, because it would do magic on StartInstance... [10:00] wrtp, yeah, environs.Environ is IMO the wrong thing to be exposing [10:00] wrtp, but I am not interested in reachitecting anything we don't *have* to at this stage [10:00] fwereade_: the wrong thing to be exposing to what? [10:00] wrtp, so let's just drop it :) [10:00] fwereade_: np [10:00] fwereade_: i'm interested in your thoughts though [10:02] wrtp, they're not really relevant at this stage -- we made the decision to stick all the common stuff into the EC2 provider ages ago [10:02] fwereade_: the common stuff can easily be factored out later while retaining the same environs.Environ interface. [10:02] fwereade_: i think [10:02] wrtp, we'll worry about that when we have to [10:02] fwereade_: my thought too [10:11] fwereade_, wrtp: I'm not sure I undertand what's the last consensus, despite the fact I've read the backlog [10:11] niemeyer_: as i understand it, the consensus is this: [10:12] niemeyer_: 1) we add these methods to environs.Environ: http://paste.ubuntu.com/1087700/ [10:12] wrtp, niemeyer_: clear all provider ports on instance start; clear all state ports on UA start; firewaller will catch up when it needs to [10:13] wrtp, niemeyer_: AIUI ;) [10:13] niemeyer_: 2) we change the ec2 StartInstance so that it doesn't automatically clear out machine ports [10:13] LOL [10:14] Looks like there's no consensus indeed [10:14] niemeyer_: we're not in conflict there [10:14] niemeyer_: the question is *where* the provider ports get cleared out [10:14] "clear all provider ports on instance start" != "change the ec2 StartInstance so that it doesn't automatically clear out machine ports" [10:14] niemeyer_: 3) make the PA clear out ports when it starts a new instance [10:15] niemeyer_: this is so that there's no behind-the-scenes interaction between StartInstance and the open ports [10:15] niemeyer_: but i'm happy for StartInstance to be documented as closing any machine ports too [10:16] niemeyer_: 4) make the UA clear out state ports on unit start [10:16] Huh [10:16] niemeyer_: oops. [10:16] That seems to turn a trivial issue into a multi-faceted problem on three different entities [10:16] niemeyer_: 3) make the PA clear out ports when it starts a new *machine*. [10:17] niemeyer_: what does? [10:17] 1+2+3+4 [10:17] What's the issue we have? [10:18] wrtp: (1) looks good, btw [10:18] niemeyer_: one issue is: what happens when the PA starts a new instance for a machine that had an instance before? [10:18] niemeyer_: open ports are attached to machines, not instances [10:19] wrtp: Not exactly [10:19] niemeyer_: and it would be nice if the firewaller doesn't have to track instances [10:19] wrtp: Both contain data about it [10:19] wrtp: But, ok.. [10:19] wrtp: The provisioner doesn't care about ports at all [10:20] wrtp: It's not its problem [10:20] niemeyer_: there is a problem [10:20] wrtp: Ok.. go on [10:21] niemeyer_: if the provisioner starts a new instance for a machine, we want to close all the ports for that machine [10:21] niemeyer_: probably [10:21] wrtp: No, we don't [10:21] niemeyer_: although we could choose not to [10:21] wrtp: Machines should be started with no open ports [10:21] niemeyer_: fwereade_ thought we should. i'm on the fence. [10:21] Sorry [10:21] Bad term [10:21] wrtp: Instances should be started with no open ports [10:21] niemeyer_: exactly [10:21] wrtp: That's a problem for the environment to solve [10:21] niemeyer_: so we want to close all the ports for the existing machine [10:22] niemeyer_: in the state [10:22] wrtp: No! [10:22] wrtp: The state is something else! [10:22] niemeyer_: so we'd have a machine in the state with open ports, but the instance would have no open ports? [10:22] wrtp: This was just about the environment itself.. [10:22] wrtp: I think I'm missing the actual issue [10:23] wrtp: Yeah, I was missing indeed. [10:23] wrtp: Okay [10:23] wrtp: So there are two separate issues [10:23] wrtp: One of them concerns management of ports of the instance.. the other about management of ports in the state [10:24] yup [10:24] wrtp: Which one are we talking about? [10:24] both [10:24] niemeyer_: how they interact with each other [10:24] wrtp: Okay, so can we please separate them up [10:24] wrtp: Not really.. they are independent issues [10:25] niemeyer_: there is no management of ports of the instance [10:25] wrtp: !? [10:25] niemeyer_: there is management of ports of the *machine* [10:26] niemeyer_: OpenPorts(machineId int, ports []state.Port) error [10:26] wrtp: Oops [10:26] wrtp: Yeah, just now I realize that.. this seems wrong [10:26] wrtp: Environ manages instances, not machines [10:27] niemeyer_: so we manufacture a new security group every time we start a new instance? [10:27] wrtp: Is there any other way? [10:27] wrtp: We talkeda about this yesterday [10:27] niemeyer_: well, currently we name the instance group after the machine id [10:27] niemeyer_: but i think you're suggesting that we don't do that [10:28] wrtp: I'm suggesting something else.. I'm suggesting that Environ manages instances, not machines. Do we agree on that? [10:29] niemeyer_: currently the Environ uses the machine id for some things [10:29] wrtp: Do we agree on that? [10:29] niemeyer_: "manages", yes. [10:29] wrtp: Okay, thanks [10:30] niemeyer_: but setting the ports for a machine isn't "managing" the machine, i think. [10:31] wrtp: So the question is what interface makes sense given that. I understand the ec2 implementation does certain things a given way [10:31] wrtp: It's managing the instance information for sure [10:31] niemeyer_: the ec2 implementation is a fairly close reflection of the python implementation in this respect [10:31] wrtp: It's controlling the firewall data associated with the instance [10:32] niemeyer_: currently it's controlling the firewall data associated with the *machine* [10:32] wrtp: Not really [10:32] niemeyer_: because the security group is named after the machine, not the instance [10:32] wrtp: The firewall data associated the machine is controlled via state [10:32] wrtp: It's not doing anything with that [10:32] ? [10:32] ? [10:33] Can't answer that :) [10:33] :-) [10:33] i could also say "the firewall associated with the machine is controlled by the provider" [10:34] wrtp: Machine lives in *State [10:35] wrtp: Everythign about the Machine is controlled via *State [10:35] ok, s/machine/machine id/ [10:35] wrtp: Instance is the name we give to a provider's virtual machine [10:35] wrtp: Environ.OpenPort manages the Instance, not the Machine [10:35] wrtp: That's what I'm trying to point out [10:35] niemeyer_: in the ec2 implementation that's not true [10:35] wrtp: In all environs/* implementations, that is true [10:35] niemeyer_: because the security group is associated with the machine id, not the instance id [10:35] wrtp: That's completely irrelevant.. we could name it as "abacate" [10:35] niemeyer_: and there can be several instances for a given machine id [10:36] wrtp: It's still associated with the Instance, and it's still managing the firewall for the Instance [10:36] wrtp: Machine is an abstraction we decided on for referring to the *State information [10:36] niemeyer_: originally, i had Instance.OpenPort [10:36] niemeyer_: but that seems wrong [10:36] wrtp: Yes, and you changed that to make it more convenient [10:36] niemeyer_: not more convenient, more true to reality [10:37] wrtp: The fact we use machine ids on the security group name is an implementation detail.. the fact we have to *use* security groups like that is also an implementation detail [10:37] wrtp: In the future this will live within the instance [10:37] niemeyer_: in that case, the Environ interface must change [10:37] niemeyer_: because the PA won't be able to control it from outside [10:37] wrtp: Yes, it will have to change eventually, by simply losing these methods [10:37] niemeyer_: exactly. [10:38] niemeyer_: so for the time being, this is what we've got - the ports for an instance are managed by changing attributes associated with the machine id, not the instance. [10:38] wrtp: But disagreeing that Environ controls Instances is a blocker on that conversation.. we StartInstance, we StopInstance, we ask for Instance and AllInstances.. [10:39] niemeyer_: i certainly didn't disagree that Environ controls Instances [10:39] wrtp: That may be the best way to move forward, but it's hard to get there if we can't even agree on obvious facts [10:40] niemeyer_: the issue of the interaction of machine id and the Environ is a tricky one [10:40] niemeyer_: why are we passing the machine id into StartInstance at all? [10:40] wrtp: To get the machine id into the state initialization [10:40] wrtp: That was the real reason it got there [10:41] niemeyer_: so maybe it *is* wrong that the instance's security group is named after the machine id [10:42] niemeyer_: (but it's going to be a bit awkward to come up with new unique names) [10:42] wrtp: I see it merely as an implementation convenience as we need something unique per machine [10:42] niemeyer_: per machine or per instance? [10:42] wrtp: This is completely hidden away from the interface [10:42] wrtp: Per instance, sorry [10:42] wrtp: I also see it as a nasty hack we have to do for AWS [10:42] niemeyer_: currently, it's *not* unique per instance [10:42] niemeyer_: sure [10:43] niemeyer_: i agree it's not great. [10:43] wrtp: Surely it must be unique.. a security group name is unique, and we have one security group per instance.. [10:43] niemeyer_: we can have multiple instances using the same security group [10:44] niemeyer_: if they're started with the same machine id [10:44] niemeyer_: there's nothing in the Environ API that prevents that [10:44] wrtp: Oh, you mean if there are multiple environments in a single AWS account? [10:44] wrtp: Fuck, that's a bug [10:44] niemeyer_: no [10:45] niemeyer_: if i call StartInstance(1); StartInstance(1) [10:45] wrtp: Oh, wait.. the security group has the env name in it too [10:45] niemeyer_: yeah [10:45] wrtp: Oh, sure.. that'd be broken usage of the environment [10:45] niemeyer_: if i do the above, i'll get two instances sharing the same security group [10:46] niemeyer_: not necessarily, if the first instance has stopped for some reason [10:46] niemeyer_: and the PA is restarting it [10:46] wrtp: Stopped or destroyed? [10:46] niemeyer_: crashed [10:46] wrtp: Crashed and destroyed or crashed and stopped? [10:46] wrtp: Both are possible [10:47] niemeyer_: crashed and stopped. [10:47] niemeyer_: but you're going to say that the PA won't restart in that case, right? [10:47] wrtp: That means the instance is still alive [10:47] wrtp: Yes, it shouldn't [10:48] [11:44:30] niemeyer_: there's nothing in the Environ API that prevents that [10:48] it's just a convention upheld by the PA [10:48] wrtp: Sure.. I don't undertand what your underlying point is, though. This is our backyard.. are you suggesting we implement a second *State within the environment? [10:48] wrtp: Just so we can control the correct use of *State? [10:48] niemeyer_: which is why i thought it might be better to make the environ API better reflect the reality of what's underneath [10:49] niemeyer_: (and as a bonus, it makes the firewaller code easier) [10:49] wrtp: Sorry, I can buy that.. that's completely unrelated to the point above, though [10:50] niemeyer_: i'm suggesting that the OpenPorts calls associate ports with machine ids, not instances, because that's what's actually going on underneath [10:50] wrtp: "Environ has an unsafe API, thus we can make the API simpler to use" makes no sense to me [10:50] niemeyer_: then the API isn't unsafe [10:51] niemeyer_: because it's not trying to pretend that ports are associated directly with instances. [10:51] wrtp: How come? You're saying we can have multiple machines associated with a single security group, and then we associated ports with whatever machine is using, and that's fine!? [10:51] wrtp: This is going in a pretty strange direction [10:51] wrtp: If our implementation can't control the association between security group and instance correctly, that's a MAJOR PROBLEM. [10:51] s/multiple machines/multiple instances/ and yes, that's ok i think [10:53] niemeyer_: our implementation controls the association between security group and port, not between instance and port. that's the basic difficulty. [10:53] wrtp: Agreed. Cool, that's a good baseline [10:54] niemeyer_: the "bonus" above is that the firewaller wouldn't need to keep track of every machine's allocated instance, because all it needs to change is the ports associated with a *machine* not an instance. [10:55] wrtp: machine.InstanceId()? How is doing that any harder than using a machine id? [10:55] niemeyer_: FWIW the open_port code in the python version takes an instance as an argument but only ever uses the machine id [10:55] niemeyer_: because the instance id can come and go [10:56] niemeyer_: so it's one more thing to track [10:56] niemeyer_: i had a sketch version of the firewaller code that did that [10:57] http://paste.ubuntu.com/1087751/ [10:57] wrtp: We don't have to "track" that, I think.. if the instance id "goes", everything inside it is gone too. [10:58] vs: http://paste.ubuntu.com/1087753/ [10:58] niemeyer_: yes, so that firewaller needs to know when that happens, right? [10:58] niemeyer_: and it needs to know when the machine is allocated a new instance id too [10:59]