[09:00] fwereade: Morning [09:00] heya niemeyer [09:03] rogpeppe: Morning [09:05] niemeyer: hiya, up early... [09:07] rogpeppe: Yeah, lost sleep and decided to push some pending tasks forward [09:09] niemeyer: i've been up about 2 hours myself, but went for a nice long bike ride. [09:09] rogpeppe: Oh, that sounds very nice [09:09] rogpeppe: Haven't been biking in a long while [09:10] rogpeppe: I'm a one-sport man.. squash took over.. ;-) [09:10] niemeyer: i've been going out in the mornings 'cos i realised that moving from bedroom to desk wasn't getting me much exercise! [09:10] rogpeppe: Nice that you've handled that quickly.. indeed it's an amazing recipe for couch potatoing :) [09:11] niemeyer: rock climbing was always my big thing, but it's harder to get out these days... [09:11] been going out on the bike most days for 2 weeks now, and i haven't repeated a route once... [09:29] Wow [09:30] rogpeppe: Just submitted a review for the robustness branch [09:30] Will step out to have coffee with Ale [09:30] Back soonish [09:30] niemeyer: thanks [09:45] popping out for a coffee myself, might kickstart my brain [10:05] * niemeyer returns [10:13] TheMue: Morning [10:13] niemeyer: morning, back again [10:36] TheMue, btw, you mentioned a blocker on relation state; do you have a mo to fill me in on that? [10:37] fwereade: niemeyer told me that there are some open discussions and i should defer it and continue with other open parts meanwhile [10:37] TheMue, ah yeah, cool, that makes sense [10:38] fwereade: Subordinates are on going in Python.. I suggested waiting for that so that the implementation may be done once [10:38] fwereade: right now i'm going through presence package. should be difficult to switch my agent code to use it. [10:38] TheMue, should be? :( [10:38] fwereade: oh, sorry, typo [10:38] TheMue, phew :) [10:38] fwereade: ahoulsn't ;) [10:39] TheMue, now *that's* a typo :p [10:39] fwereade: hehe [10:39] TheMue, what's next on your roadmap? [10:39] TheMue, just want to make sure we don't collide again ;) [10:40] fwereade: no, indeed, your package looks good. maybe an integration of tomb for save goroutine handling would make sense [10:40] TheMue, the intent was to have as much as possible the same semantics as normal ZK watches [10:41] fwereade: i've got three reviews in the pipe, one is the agent proposal. once that one is ready for integration i would extend the entities i already have and which shall have agents with it [10:42] fwereade: beside that i've got to compare what's still open in state [10:42] TheMue, cool; I'm looking into hook execution so I don't think we'll cause each other too much trouble ;) [10:42] fwereade: i'll post here what i'll start next [10:43] fwereade: did you took a look into my agent code? [10:43] TheMue, one thing I noticed is that we don't seem to have state.Unit.OpenPort yet [10:43] TheMue, I started; I have a couple of draft comments, I'll try to get them finished for you now [10:43] fwereade: OpenPort() is one of the proposals [10:44] TheMue, oh, fantastic, sorry I missed that one [10:44] fwereade: the code is submitted for review [10:44] TheMue, I'll take another look at +activereviews [10:47] TheMue, hasn't go-state-continued-machine been merged already? [10:48] TheMue, and go-state-gocheck-change too? [10:49] fwereade: all they are missing an LGTM [10:50] fwereade: the latter is also needless, it's also part of the others. rog and i thought it had to be done earlier, so i made an extra branch. but the changes have been so few that another brach already had them [10:50] TheMue, ah cool, maybe reject that one then? [10:51] fwereade: how to do that? [10:51] TheMue, go to the LP merge proposal and click the status field at the top [10:52] fwereade: important are the two go-state-continued-… and the go-state-first-agent-draft [10:52] TheMue, cool, I'll get up to date on those then [10:52] TheMue, thanks [10:54] fwereade: hmm, i'm somehow lost and don't find the mentioned status field at the top [10:55] TheMue, it's currently an orange "needs review" [10:59] fwereade: ah, have not gone far enough in lp [10:59] TheMue, ah sorry you were looking at the branch? [11:00] fwereade: yep, i still have my troubles with the usability of lp [11:00] TheMue, haha, LP seemed like sweetness and light to me after the rubbish we were using at my last place [11:01] TheMue, the tool was *worse* than doing bug/iteration tracking with google docs spreadsheets [11:01] fwereade: i've worked with JIRA. it's not as powerful as LP, but the UI is more clear [11:01] fwereade: uh, sounds horrible [11:01] TheMue, (I know that to be true because that was what we were using before) [11:01] * fwereade cries quietly in a corner [11:02] * TheMue dcc's fwereade a tissue [11:02] :) [11:05] fwereade: so, it's rejected but still with status "Development". can i now change this to "Abandoned"? [11:05] TheMue, sounds good to me (I usually forget to do that myself) [11:06] fwereade: ok, i like a clean workplace ;) [11:13] niemeyer: oh, i just rejected go-state-gocheck-change after discussion with fwereade, those changes have already been in a former branch and are merged into state [11:13] niemeyer: this overlapped, sorry [11:15] TheMue, review on https://codereview.appspot.com/5690051/ [11:16] fwereade: thx, take a look [11:16] TheMue: That's cool, no worries [11:23] fwereade: in your review you say that in todays code the only caller of RemoveMachine() care's if it doisn't exist? [11:23] TheMue, seems so to me [11:25] fwereade: do you know the reason behind it? from states perspective it's ok if there's nothing to remove. [11:26] fwereade: but state has online a very limited view. [11:26] TheMue, tbh I'd be just as happy if it silently ignored nonexistent machines [11:26] TheMue, it's just the mismatch between the state's view of what's acceptable and the single client's view [11:27] TheMue, I'd rather just return an error than return a value (false) that's always turned into an error [11:34] fwereade: hmm, it's just todays code only ported to go [11:35] fwereade: should ask niemeyer [11:36] TheMue, understood; and there may be reasons for it that I've missed; but I'm not sure that we should feel too bound by python implementation details [11:37] fwereade: if i got it right we first shall catch the current status and later optimize it for go [11:37] TheMue, my view is that that particular implementation detail is either a misprediction of future needs, or an appendix left over after the removal of some pre-existing need [11:38] fwereade: maybe, you are more safe than me i the existing code. [11:40] TheMue, that hadn't been my perception -- while we should maintain externally observable characteristics wherever possible, I'd prefer to strip ickiness where possible [11:40] TheMue, for example, presence nodes vs ephemeral nodes [11:41] niemeyer, opinion? [11:41] fwereade++ [11:42] TheMue: If the only use of this method actually does what fwereade suggests, turning around and saying "Hah! Actually, that's an error!", then it feels like the API was mispredicted when first written [11:43] I didn't even know that was the case, FWIW [11:44] niemeyer: yep, i do code scans to see where a meth/func is used to se how it is intended when it's unclear to me [11:45] niemeyer: in this particular case i felt no need so i ported it 1:1 [11:45] niemeyer: maybe scanning for each func is useful [11:46] niemeyer: wanna talk about DNS name timeouts? [11:47] TheMue: It may be hard in some cases without further context [11:47] TheMue: Reviews help with that too [11:47] rogpeppe: Sure [11:48] niemeyer: definitely [11:48] niemeyer: i don't quite understand this: " [11:48] There's an application running somewhere, we shutdown a [11:48] machine, and then that app hangs for 3 minutes just because it asked for a DNS [11:48] address? [11:48] " [11:48] niemeyer: what's the "application" in this context? [11:48] rogpeppe: A binary [11:48] rogpeppe: Any binary that links against this library of code [11:49] niemeyer: ok. [11:49] TheMue, reviewed https://codereview.appspot.com/5727045/ [11:49] niemeyer: i think there are two scenarios [11:49] niemeyer: one is when you really need the address [11:49] niemeyer: the other you don't care too much [11:49] fwereade: already seen an interesting comment regarding retryTopologyChange() [11:49] niemeyer: for instance, when we ask for the DNS address of the bootstrap machine, we really need it [11:50] niemeyer: but, as you point out, in StateInfo we don't care too much [11:50] niemeyer: i'm wondering about a "wait as long as necessary" bool flag on Environ.DNSName [11:51] niemeyer: i'm trying to resist forcing clients of Environ to do their own polling. [11:52] niemeyer: because i think the strategy might be quite different for different providers. [11:52] niemeyer: (some providers will always have a DNS name instantly available, for example) [11:53] rogpeppe: Hmm [11:53] rogpeppe: I don't think so, to be honest [11:54] rogpeppe: The case where you say "give me a machine" to an IaaS and you have an address immediately may not be so common [11:55] rogpeppe: I'm happy to experiment with a waiting API, but let's please keep an eye on this rather than taking it as a general approach from now on [11:55] rogpeppe: I suggest we introduce WaitDNSName() returning (addr, error) [11:55] niemeyer: immediately, perhaps not. but a 3 minute wait? many DHCP clients give an address in < 1s [11:56] TheMue, I definitely don't think that's something to be addressed in this branch [11:56] rogpeppe: And keep DNSName() returning the already known address only [11:56] niemeyer: i'm wondering if it should be the other way around. [11:56] TheMue, but State "feels" like the right place for it to me [11:56] rogpeppe: The three minute wait is completely unrelated to DHCP [11:56] niemeyer: DNSNameNoWait [11:57] so DNSName always gives you a valid DNS name if it can [11:57] rogpeppe: This is waiting for a machine to be booted [11:57] rogpeppe: Which is why it's wrong to be holding on DNSName specifically [11:57] niemeyer: why can't the DNS name be allocated before the machine boots? [11:57] rogpeppe: The machine is off.. the DNS name isn't special [11:57] niemeyer: doesn't the infrastructure allocate the DNS name? [11:57] rogpeppe: It's not under our control why people do this or not [11:57] niemeyer: not the machine itself? [11:58] rogpeppe: The fact is that the most well known IaaS doesn't do that [11:58] niemeyer: ok. seems a bit weird to me, but i'm sure there's a good reason. [11:58] rogpeppe: Likely because they're still working out where to allocate the machine by the time it's answered [11:58] rogpeppe: But, again, there's no point for us [11:59] fwereade: will comment your review, most of it sounds got. the one with the goto had a problem with a break, but i've got to look again which kind it was [11:59] niemeyer: anyway, i'd prefer the default to be to wait, if that's ok. [11:59] rogpeppe: WaitDNSName please.. this is the special case that will yield misbehaving code if we forget that it can take *several minutes* to return [12:00] rogpeppe: and let's have DNSName() returning (attr, error) too, so that it's clear that we may not have a DNS address at that time [12:00] Erm, (addr, error) [12:00] niemeyer: it does that currently [12:00] rogpeppe: It didn't do before your branch, and I'm suggesting both WaitDNSName and DNSName do that [12:00] rogpeppe: If that's what you had in mind already, great.. :) [12:00] niemeyer: sure, that's unavoidable [12:01] rogpeppe: It's not unavoidable.. what we have in trunk today is not like that [12:01] niemeyer: that's because it doesn't work :-) [12:01] Heh [12:01] TheMue, cool, thanks; https://codereview.appspot.com/5782053/ reviewed as well [12:04] " [12:04] This logic is error prone. When we get ErrMissingInstance, we'll have to [12:04] *always* check len(insts) to see if it's 0 or not before iterating [12:04] " [12:04] niemeyer: the logic was deliberate [12:05] rogpeppe: Cool, let's fix it then [12:05] niemeyer: it means that if you've asked for some instances, you can easily check (len != 0) if at least some instances have been returned [12:05] rogpeppe: That's error prone, as described [12:06] niemeyer: if you're iterating, you don't need to check len(insts) for 0 [12:06] niemeyer: because the iteration will never go anywhere [12:08] insts, err := e.Instances([]ec2.Instance{a, b, c}) [12:09] if err == ec2.ErrMissingInstance && len(insts) != 0 && insts[0] == nil { ... } [12:10] rogpeppe: Please don't force me to remember to do that every time [12:12] niemeyer: most of the time you just check the error, in which case it doesn't matter. the other way around (and probably the more common one) is that if you ask for some instances and get some, but not all of them, you have to scan the list to see if you've got any. [12:12] niemeyer: whereas the way it is currently, you can just check the length - you'll never return a slice with no non-nil instances in. [12:13] niemeyer: i started off always returning a slice, but changed it because it was easier to use this way [12:14] s/you'll never return a slice/you'll never get a slice/ [12:14] rogpeppe: Easy and error prone.. there are two different cases to handle [12:15] rogpeppe: and we have to remember them when using this method to avoid a panic [12:15] rogpeppe: Please, either return the slice at all times, or let's have two different error types [12:15] rogpeppe: No gotchas [12:16] niemeyer: ok, i'll do two error types. [12:18] rogpeppe: Thanks [12:21] niemeyer: [12:21] // Instances returns a slice of instances corresponding to the [12:21] // given instance ids. If no instances were found, but there [12:21] // was no other error, it will return ErrInstanceNotFound. If [12:21] // some but not all the instances were found, the returned slice [12:21] // will have some nil slots, and an ErrInstancesIncomplete error [12:21] // will be returned. [12:22] Instances(ids []string) ([]Instance, error) [12:24] rogpeppe: Looks good, thanks. Just plural for ErrInstancesNotFound too, please [12:24] niemeyer: oh yeah, that was a typo - the actual error was spelled that way in fact. [12:25] rogpeppe: Sweet.. "Partial" might also be a shorter term for Incomplete [12:26] rogpeppe: Up to you, though [12:26] niemeyer: ErrInstancesPartial doesn't sound great, and neither does ErrNotFoundInstances IMHO. [12:26] niemeyer: but ErrInstancesNotFound and ErrPartialInstances seem inconsistent [12:27] rogpeppe: PartialInstances + NoInstances? [12:27] +1 [12:27] Super, thanks [12:36] lunchtime [12:59] niemeyer: i'm slightly concerned about doing this: " [12:59] It should wait, but stop on the first batch that has [12:59] at least one valid DNSName. [12:59] " [12:59] (of StateInfo) [13:00] it means that if we call StateInfo when, say, only one zk instance has been allocated, and that instance later goes down, we won't have the redundancy that we should. [13:01] rogpeppe: I don't understand.. if the only instance that was allocated goes down, there's no redundancy [13:01] niemeyer: sorry, i was ambiguous [13:02] niemeyer: when i said "only one zk instance has been allocated" i meant "the DNS name of only one of several zk instances has been allocated". [13:02] rogpeppe: The scenario is this: we have three intances, one is terminated for whatever reason.. it shouldn't wait for 3 minutes when it knows about other instances. [13:02] niemeyer: i don't think that scenario would make it wait [13:03] niemeyer: the scenario i'm concerned about is: we start 3 instances. the DNS name for only one of them is used, because it boots fractionally faster than the others. [13:05] rogpeppe: I don't see how it would not wait.. you're picking the first entry in the list and calling DNSName on it.. with the logic in the branch, it will wait for as long as it takes for that one machine to have an address, no matter how many machines are there. [13:05] rogpeppe: Is this the DNSName catching you already? :-) [13:06] niemeyer: so we get *one* machine from the three possible zk machines. then that zk machine goes down. if we'd waited for the names of the others, the zk client could redial one of them, but as it is, it can't because it doesn't know about them [13:07] rogpeppe: I don't see what you mean.. [13:07] for i, inst := range insts { [13:07] addr, err := inst.DNSName() [13:07] *BOOM*.. three minutes.. [13:07] That can't happen.. [13:08] niemeyer: ok, so you're suggesting we wait for them all in parallel, presumably, and then return the first one that has a DNS name? [13:08] niemeyer: (assuming none of them have DNS names to start with) [13:08] rogpeppe: I'm saying that the problem above can't happen, so far. [13:08] niemeyer: because we only have one zk server, right? [13:08] rogpeppe: If you understand the problem, we can talk about a solution [13:09] i'm not sure i do understand the problem. is it that we might be launching one zk machine much later than the others? [13:10] so we don't want to wait for that while the others are available anyway? [13:10] niemeyer: we've got to wait for at least one DNS name, right? [13:10] rogpeppe: Yes.. [13:11] rogpeppe: You have N machines.. waiting for several minutes for a random one to be alive == BAD [13:11] niemeyer: so we don't mind if the zk client doesn't know about the other zk servers? [13:11] rogpeppe: I don't know what you're talking about [13:12] rogpeppe: I'm saying that if we know about N machines, waiting for several minutes for a single arbitrary machine == REALLY BAD [13:12] it's not waiting for a single arbitrary machine, it's waiting for all of the zk machines. [13:12] rogpeppe: Yes.. that's equally bad [13:13] rogpeppe: It's pointless to have three machines for redundancy if the application waits for several minutes for all of them to be available [13:13] niemeyer: the problem is that there's no way of telling the zk client when another zk machine *does* become available [13:14] niemeyer: which means that if the only machine that we found does go down, we haven't got any redundancy any more. [13:14] rogpeppe: That's a completely independent problem [13:14] oh? [13:14] rogpeppe: Yep.. dynamic member sets is a different problem [13:15] rogpeppe: We can't hold on forever waiting for everybody to be available or the redundancy is over [13:15] niemeyer: it's not a dynamic member set though - we know we've started 3 zk machines, we just want to wait for them to be up [13:15] rogpeppe: A single machine terminated would kill juju [13:15] rogpeppe: If a single one of them terminates, it will never be up [13:15] niemeyer: we're not waiting for the *machine* to be available, we're waiting for its DNS name. isn't that different? [13:16] niemeyer: the DNS name is still available if a machine is terminated, i think. [13:16] rogpeppe: If a machine is terminated the entire instance record will go away in a bit [13:18] niemeyer: that takes hours. and we can guard against that easily too. [13:18] niemeyer: by only doing a short timeout when calling Instances in WaitDNSName [13:19] rogpeppe: I'm sure there are many workarounds for the problem. I was just describing it, and wishing that we didn't introduce it [13:20] niemeyer: i think we *should* wait for all the zk addresses. but i think we shouldn't do a 3 minute timeout if the instances aren't there. [13:20] rogpeppe: The Instances call above is equally problematic, btw.. it's aborting if any of the instances are not found [13:20] rogpeppe: Uh oh.. :( [13:21] niemeyer: good point. that *is* a bug. [13:21] rogpeppe: Man.. the issue is trivial: if a machine in a set of three never starts, we can't block *all of juju* because of that.. [13:21] rogpeppe: Same thing if it terminates [13:22] rogpeppe: It simply makes no sense to have multiple machines if that's what we're doing [13:22] niemeyer: terminating isn't a problem. [13:22] rogpeppe: The logic in your branch breaks if one terminates. [13:22] rogpeppe: That is a problem. [13:23] rogpeppe: Let's please fix that. [13:23] niemeyer: agreed. but that's a different problem. [13:23] niemeyer: that doesn't mean we shouldn't try to wait for all the DNS names while the instances are still around. [13:24] niemeyer: (and running) [13:24] rogpeppe: The logic in your branch breaks if a machine never gets allocated. [13:24] rogpeppe: This is a bug. Let's fix it. [13:24] niemeyer: yes, i've agreed about that. [13:24] rogpeppe: No, you just said otherwise. [13:24] niemeyer: that doesn't mean we shouldn't try to wait for all the DNS names while the instances are still around. [13:25] niemeyer: if a machine never gets allocated, the instance won't be around [13:25] niemeyer: so we won't wait for its DNS name [13:25] rogpeppe: It will stay in "pending" mode.. [13:26] rogpeppe: What happens then? [13:26] niemeyer: so a machine can stay in pending mode forever? [13:26] rogpeppe: Bad things happen.. machines go from pending to terminated.. stay in pending for a very long time, etc [13:27] niemeyer: if that's so, i agree it's an issue. but... [13:27] niemeyer: if we go the other way, even if we have 3 zk instances, all the initial agents will only ever talk to one of them. [13:27] rogpeppe: The logic you're introducing is trying to handle the unfriendliness of EC2.. we must not go overboard with it. Having an application that hangs for several minutes in edge cases is not nice. [13:27] niemeyer: so if that one goes down, the initial agents are stuffed [13:28] rogpeppe: If there are known machines in a set of zk instances, let's not block waiting forever we *know* about *good working machines* [13:28] niemeyer: ... which means we'll stop when we have exactly *one* machine, right? [13:29] rogpeppe: That's fine! If we have to reconnect, well.. we have to reconnect! [13:29] rogpeppe: Purposefully introducing a resilience bug to fix resilience is.. hmm.. interesting. [13:29] niemeyer: ok, so it's important for the state client to know that it should always re-get the StateInfo when it reconnects, right? [13:30] actually, no this won't work [13:30] rogpeppe: I don't know.. but whatever we do, there's a bug locallly, in that small subworld we're handling. [13:30] because the zk client carries on redialling the set of known machines regardless of whether they're up or down [13:31] rogpeppe: Up to us.. we get the disconnection events, and as far as I understood, our approach was going to be reestablishing the connection. [13:31] niemeyer: we don't get the disconnection events AFAIK [13:32] rogpeppe: ZooKeeper notifies about disconnections. [13:32] ah, maybe it's just the initial connection attempt that goes on forever [13:32] rogpeppe: and our last agreement was that we were going to handle any connection issues as fatal. [13:33] rogpeppe: We might even be smarter at some point, and wait for longer if we knew that we had *just* bootstrapped [13:33] rogpeppe: Having that as a general rule over the lifetime of the environment is not reasonable, though [13:34] rogpeppe: ZooKeeper certainly tries to reestablish the connection.. that's not the same as not having notification of disconnections. [13:34] niemeyer: yeah, given that it makes no difference if we pass 1 or 3 addresses to the zk client, there's no point in waiting for more than one. [13:35] rogpeppe: Arguably, we're doing more work on our side, but as far as I could perceive so far, that sounds like a good idea anyway [13:35] rogpeppe: Trusting on the internals of zk to achieve long term reliability hasn't been fruitful [13:35] niemeyer: yeah. and it makes it easier to move to something else if we want to, perhaps. [13:36] rogpeppe: I guess we do have the instance start time, right? [13:36] * rogpeppe goes to have a look [13:36] rogpeppe: I'd be happy to wait in that loop as you suggest if we take that into consideration [13:38] niemeyer: yeah, there's LaunchTime although it's not in goamz/ec2 yet [13:38] rogpeppe: Maybe let's just keep simple then, and return the first good set of machines we have [13:39] niemeyer: i'll wait in parallel and return the first address we get. that's easiest i think. [13:39] niemeyer: i could wait for a short time after the first one, in case there are several arrive together. [13:39] rogpeppe: I don't think it needs to be parallel [13:39] niemeyer: oh, just poll DNSName on all of them? [13:40] rogpeppe: Put Instances itself in a loop.. once we have a batch with good DNSNames, return all of the ones that have an address assigned [13:40] rogpeppe: Instinctively, I believe there are good chances that we'll get multiple entries at once [13:40] rogpeppe: Since reservations are grouped [13:40] yeah, that's better. i was going to call WaitDNSName in parallel. [13:40] but that way is better [13:40] niemeyer: all our instances are in separate reservations. [13:41] rogpeppe: Hmm, good point.. [13:41] rogpeppe: Even then, there must be a queue in the server side [13:42] niemeyer: who knows? given that we're waiting for a second before polling, we'll get any within that second. [13:42] rogpeppe: Btw, I'm also working a bit on a quick clean up of goamz this morning.. I'll put all the packages in a single branch [13:42] niemeyer: yay! [13:43] niemeyer: (i'm glad you got that fix in before go 1) [13:43] rogpeppe: Yeah, it'd be tricky later [13:43] niemeyer: thanks for the discussion BTW. i found it very useful. [13:43] rogpeppe: I'm also including all the pending crack around mturk, sns, and sdb onto an exp/ subdir [13:44] good plan. [13:44] They're not in a great state, but I want to make them into official branches since I've been doing a poor job reviewing/improving them [13:44] rogpeppe: Yeah, it was instructional for me too, thanks as well [14:03] lunch,bbiab [14:35] niemeyer: all done, i think [14:36] rogpeppe: Cheers [15:05] TheMue: i just added my review to fwereade's. [15:06] rogpeppe: yep, got the notification [15:06] rogpeppe: thx [15:06] TheMue: np [15:09] rogpeppe: maybe rietveld should add a +1 or Like button ;) [15:10] TheMue: +1 :-) [15:28] lol " [15:28] Don't worry.. I can't feel my toes anymore. They're already crushed [15:28] from fixing code with bad error handling. [15:28] " [15:40] fwereade: thx, will change it from map to the value. but do you validate every data you retrieve from a backend (here zk) before returning it? [15:41] TheMue, it just strikes me as sensibly paranoid ;) [15:42] fwereade: :D [15:42] rogpeppe: You may want to delete this branch: https://code.launchpad.net/~rogpeppe/goamz/s3 [15:42] rogpeppe: Has no content [15:42] TheMue, there's certainly a case to be made that it's excessively paranoid ;) [15:43] fwereade, TheMue: personally i treat all data that comes from outside the program itself as suspect. [15:43] niemeyer: done [15:43] rogpeppe, indeed, the additional cost is minimal [15:44] rogpeppe: Cheers [15:44] rogpeppe, fwereade, TheMue: goamz is now a single branch [15:44] niemeyer, cool [15:44] You'll have to rm -rf $GOPATH/launchpad.net/goamz [15:44] niemeyer: cool [15:44] and then [15:44] go get -u won't work, presumably... [15:44] go get launchpad.net/goamz/aws [15:44] that's a pity [15:44] rogpeppe: Yeah, unfortunate but necessary [15:45] hmm, i'll just check i've got no outstanding branches before i rm -r... [15:46] rogpeppe: so you validate all data you read from ZooKeeper too? [15:46] TheMue: definitely. who knows what other dodgy programs have been at work there. [15:46] TheMue: i'd only validate as necessary though. no need to fail if you don't need to. [15:47] rogpeppe: how far goes your validation? how do you take care that the whole topology stored in one node is valid? or the combination of all nodes including their contents we use in state? [15:49] TheMue: depends what i'm doing with it. i'd check the error with it's parsed. and i'd check that any expectations i have of it are true. but i wouldn't check what i don't need to. [15:49] btw, do other applications write into our ZK instance? [15:49] s/with it's/when it's/ [15:59] rogpeppe: There's at least nothing in review [16:02] niemeyer: [16:02] % go get -u launchpad.net/goamz/aws [16:02] package launchpad.net/goamz/aws: directory "/home/rog/src/go/src" is not using a known version control system [16:02] hmm [16:02] TheMue: "other applications" might be just a buggy old version of our own code... [16:03] rogpeppe: Try again please [16:03] niemeyer: same result. but no delay - it seems like it's decided already... [16:03] rogpeppe: Remove your local stuff [16:04] niemeyer: which local stuff? you mean change my GOPATH? [16:05] rogpeppe: rm -rf $GOPATH/launchpad.net/goamz [16:05] niemeyer: i did that [16:05] niemeyer: there's no goamz directory [16:05] niemeyer: but i changed my GOPATH and it works [16:05] rogpeppe: I've just installed it locally, and it works [16:05] rogpeppe: So you probably have left over data [16:06] Lunch time [16:06] biab [16:06] rogpeppe: that surely maybe. so i would like you and fwereade do a walkthrough of the state code and take a look where further verification of informations retrieved out of ZK is needed. [16:07] niemeyer: it's worked now. bizarre. [16:07] TheMue: i've been looking out for it, so you're probably ok. [16:07] rogpeppe: ok, thx [16:09] niemeyer: http://paste.ubuntu.com/876199/ [16:27] rogpeppe: how would you call the type for the Resolved… values? [16:28] * rogpeppe has a look [16:29] TheMue: i can't say i really understand what they're about, but perhaps ResolvedKind? [16:30] rogpeppe: inside the nodes content they are stored as "retry = 1000" or "retry = 1001". so maybe RetryKind is better. [16:31] TheMue: seems ok to me. fwereade should ok it though - he knows what's going on much better than i! [16:32] fwereade: what do you say? [16:32] TheMue, rogpeppe: I guess I'd say RetryKind or maybe RetryMode [16:33] fwereade: out of interest, what do these values mean? [16:33] rogpeppe, just jump to the next state, or try rerunning the hook and go back to error state if it fails [16:34] fwereade: ok thanks [16:36]