=== flaviamissi_ is now known as flaviamissi [03:13] * hazmat wonders if he needs to send a mother may i email to the list [10:52] rog, hopefully trivial: https://codereview.appspot.com/5786051 [10:53] rog, and, blast, I just realised you've got that gozk review still up (right?) [10:53] rog, I checked for *juju* reviews and completely forgot the rest :/ [10:53] fwereade: yeah, i've been waiting for almost 2 weeks now. sigh. [10:54] rog, I know the feeling [10:54] rog, I think I've passed some sort of milestone now, though: I have more go branches stacked up than I do python ones [10:54] fwereade: :-) [10:55] fwereade: i wonder if instead of a new package, whether we might expand the jujutest package a bit to add testing code. [10:56] fwereade: it could be moved out of environs, and maybe just renamed "test", perhaps. [10:57] rog, doesn't sound like a bad idea, I could follow up with a branch that does that perhaps? [10:58] rog, for some reason I expect things called "test" to contain actual tests [10:58] rog, but I'm not seriously opposed to that name [10:58] fwereade: given that testutil is new, why not add ZkSetUpEnvironment to jujutest now? [10:58] fwereade: we could call it "testing" [10:59] fwereade: i know it matches the name of the std testing package, but i don't think that's a problem [10:59] import "launchpad.net/juju/go/testing" sounds reasonable to me [11:02] fwereade: it's a pity that zookeeper won't work unless it makes its own directory. then ZkSetUpEnvironment could just return a zk.Server. [11:02] rog: +1 [11:03] TheMue: nothing we can do about that though... [11:04] rog: the testing package or the directory part? [11:04] TheMue: the directory part. were you referring to the testing package? [11:04] rog, so we'd do `import jtesting "launchpad.net/juju/go/testing"` or something? [11:05] rog: yep [11:05] fwereade: yeah, but the identifier would only be necessary if you were already importing "testing". (probably true most of the time in the zk scenarion) [11:05] i quite like "scenarion" [11:06] rog, fwereade : as long as our functions in the package have a clean naming it also could be imported with _. [11:07] TheMue: huh? surely we can't if we want to use it... [11:07] ? [11:08] rog: eh, i meant . like with gocheck [11:09] TheMue: no no no! no more import "."s! gocheck is one too many as it is! [11:09] rog: what troubles do you have with it? [11:09] TheMue: namespace pollution [11:10] TheMue: why don't we import many things with "."? [11:10] TheMue: answer: because it's nice to see a name and know where it comes from. [11:11] TheMue: import "." is only there because of it was conventional to write tests as if they were part of the same package as they're testing. [11:11] TheMue: and sometimes there's a cyclic dependency [11:11] rog: definitely, but then we need a different package naming then testing. otherwise aliases also can difer over different sources and you get a bad maintenance aspect [11:11] TheMue: but IMHO it should never be used [11:11] TheMue: i don't think that's a problem. [11:12] TheMue: the compiler knows and will tell you very quickly [11:12] TheMue: we already have two packages with the identifier "ec2" for example [11:12] TheMue: and it's not a problem. [11:12] rog: i don't talk about the compiler, i talk about people who maintain different sources where the same testing package is imported with different aliases [11:13] rog: and i our tests we would need to import both, so one always has to be aliased [11:13] TheMue: it's not uncommon to rename a package with a different alias when you import it [11:13] TheMue: if we have a standard alias in that case, i don't think there's a problem [11:14] TheMue: for example, when i import "launchpad.net/goamz/ec2" and "launchpad.net/juju/go/environs/ec2", i name the former "amzec2". [11:14] TheMue: similarly we can import "juju/go/testing" as jujutesting when there's a clash. [11:14] rog: and i talk about this "standard". i've seen enough projects where standards changed with the changing team members. while we are few and fresh there's no prob, but in longer terms [11:15] TheMue: it doesn't matter too much. it's a variable name - we have preferences but not strict rules. [11:16] rog: that's one of the problems [11:16] rog: it will differ over time [11:17] TheMue: the package identifier? [11:17] rog: and new code maintainers will stumble about it [11:17] rog:the aliases for the same package in different tests [11:18] TheMue: i don't think it'll cause more than a moment's pause. [11:18] TheMue: most of our packages don't use the standard "testing" package. [11:19] rog: the tests do, and they often will import both, the standard and our testiing package [11:19] TheMue: and it can't give rise to any more problems than a failed compile AFAICS [11:20] rog: the problem is not the compiler run, the problem are the 70% maintenance part of software costs when new people in a few years sit in front of the software and try to understand it [11:20] TheMue: i don't see that as a problem in this case - a quick glance at the top of the file will immediately resolve any queries [11:21] rog: this look here, that look there, another look at a different time - that sums [11:23] rog: just again, 70% of software costs are maintenance costs [11:23] TheMue: also, which one you're using will be obvious from the context. [11:23] TheMue: remember, you were suggesting importing as ".". that's much worse! [11:24] rog: yep, i've got to admit that this has been a bad idea. a reason why i wonna look for a better one [11:25] TheMue: if i see "testing.Something" i know that it's got to be one of only two packages with that identifier. and the Something will be something juju-related or not. [11:26] TheMue: all that said, have you got another suggestion for a name? [11:26] rog: not yet, im trying to find one. [11:29] rog: hmm, opposit to testing or gocheck it doesn't provide a testing itself [11:29] TheMue: no, but it's about testing juju, and that seems ok to me [11:29] rog: it's more that it will contain tools for testing juju [11:29] TheMue: the other suggestion was "test", which might be ok too [11:30] TheMue: as it does contain some tests as well as utils [11:30] rog: my ideas are testtools or testenv so far [11:31] TheMue: it's more than just tools - it has tests. and it's more than testing the environment. [11:32] rog: shall it DO tests or only SUPPORT tests? and i didn't meant to test the environment but to provide an environment for juju testing [11:33] TheMue: currently it *does* tests. i'm suggesting that it be a catch-all package for common stuff to do with testing juju, including tests and test tools [11:34] rog: how does it relate to the tests inside the packages? [11:34] rog: i would like a package providing the environment and tools but to keep the individual tests inside the packages [11:34] TheMue: it currently implements provider-independent tests to test an Environ [11:35] TheMue: the whole point is that those tests are independent of a particular provider, so they can't live in a single package. [11:36] fwereade: i've just discovered that the current zk behaviour (can't create a server on an existing directory) is entirely my fault. if i fix that, then we don't need a TearDownEnvironment, just srv.Destroy. [11:37] rog: don't the provider packages have a superior pckage for those tests? [11:37] TheMue: sorry, i don't understand. [11:38] rog, ah, cool [11:38] rog: a package one level above. [11:39] TheMue: do you mean launchpad.net/juju/go/environs ? [11:39] rog: yes [11:40] TheMue: i don't want to pollute its exported namespace with testing code [11:40] rog: won't that testing package be exported too? [11:40] TheMue: hence i use a different package (currently launchpad.net/juju/go/environs/jujutest) [11:40] TheMue: yes, but that testing package is *just* about testing. [11:41] TheMue: i don't want to mix testing code and production code - it'll just confuse people. [11:42] rog: yep, that's right [11:42] rog: so far in my case the testing stuff is invisible [11:43] TheMue: so i was proposing to fwereade that the jujutest package becomes launchpad.net/juju/go/testing [11:44] TheMue: because i'm not sure we need a proliferation of packages to do with juju testing. [11:44] rog: the movement makes sense, still i've got a naming problem [11:44] TheMue: ok, well perhaps we'll keep the existing name ("jujutest") for the time being, pending discussion. [11:45] rog:it's that the standard "testing" is a test framework/library while our "testing" would be tests [11:45] rog: "juju" would be redundant there, how simply "tests" [11:46] i kind of agree with fwereade's earlier comment: [11:46] [10:58] rog, for some reason I expect things called "test" to contain actual tests [11:46] TheMue: i don't mind that we're not implementing a testing framework. it's still all about testing, and that's the main thing IMHO. [11:47] rog, the thing is I do see the proposal as creating the very rudimentary beginnings of a testing framework [11:47] fwereade: +1 [11:48] fwereade: in this case we should not put this framework and the tests themself into one package [11:49] rog, ok, running a zookeeper server isn't much, but I also expect that we'll want to make it easy to get access to a temporary charm repo we can write to without messing with source control for example [11:50] rog, my perspective is that the proposal moves a small step in a good direction that I can then use to start testing hook contexts [11:59] TheMue: i don't mind too much if they're in the same package. it's not going to be a large package, and it has reasonable conceptual integrity IMHO [12:09] fwereade: i'm not entirely sure about the ZkTestingT etc functions. i think we can go simpler without sacrificing much convenience. how about this? http://paste.ubuntu.com/874476/ [12:09] fwereade: i'm assuming a couple of changes to the zk package [12:09] fwereade: 1) that the server type gets an Addr function that can be used to find out an address for the server [12:10] fwereade: 2) that the server can be created on an existing directory, as long as it's empty [12:11] fwereade: then we can potentially combine other similar utils, rather than relying on a single thing to call TestingT for us with the right resources. [12:13] fwereade: here's another idea, that saves us the error checking each time: http://paste.ubuntu.com/874481/ [12:13] fwereade: (TestingT is implemented both by *testing.T and *gocheck.C) [12:50] * hazmat yawns [13:14] rog,sorry, Iwasat lunch, give me a sec to catch up [13:15] rog, tbh I'm entirely unattached to any specific interface [13:16] rog, what I suggested I suggested purely because it looked like it'd work both for state and for my needs [13:21] fwereade: cool. what do you think of, say, my last suggestion? [13:22] wrtp, that looks fine to me [13:22] wrtp, I like the idea of having Addr on Server too [13:23] fwereade: good. [13:23] wrtp, btw, re the zk locking: [13:23] wrtp, I'm comfortable with tests that can theoretically fail under enough load [13:24] wrtp, but that's kinda hard to quantify [13:24] fwereade: yeah, i kind of am too, but it's that creeping "i'm adding just that little bit more flakiness" feeling that concerns me [13:24] wrtp, for example, how low does the tiemout have to be on your machine before you start to see semi-regular failures? [13:25] fwereade: i don't know. wait until we're running the tests on ARM :-) [13:25] wrtp, heh [13:25] niemeyer: yo! [13:26] wrtp, ok, what if you run them 100 times now? [13:26] Good morning jujuers! [13:26] niemeyer, heyhey [13:26] wrtp: Heya [13:26] fwereade: Alow [13:26] wrtp, what would be the expected failure count? [13:26] fwereade: i'll have a try. am just writing a test for CreateServer currently. [13:27] niemeyer: after discussion this morning, i'm changing zookeeper.CreateServer so that it will succeed if the server directory exists and is empty. [13:27] niemeyer: which means that Server.Destroy is sufficient to delete the tmp directory. [13:27] wrtp: Hmm.. why is it necessary? [13:28] (awww... charmstore build broke in the PPA) [13:28] niemeyer: darn. hope you get good logs... [13:28] niemeyer: because fwereade proposed this: https://codereview.appspot.com/5786051/diff/1/testutil/zk.go [13:28] niemeyer: and i thought the complexity is unecessary [13:29] niemeyer: it seems silly that you can create a temp directory and run a zookeeper server in it. [13:29] s/can/can't/ [13:29] niemeyer: so this was my counter-suggestion: http://paste.ubuntu.com/874481/ [13:30] niemeyer: assuming also an Addr method on Server. [13:30] wrtp: Looks good. Don't we have Addr? [13:31] niemeyer: nope, i don't think so. [13:31] niemeyer: it would just return 127.0.0.1:port [13:32] wrtp: Yeah, it sounds fine.. how do we even connect to the test server nowadays then/ [13:32] ? [13:32] niemeyer: we just assume localhost [13:32] niemeyer: and we specify the port, so we know the address. [13:32] wrtp: Ah, gotcha [13:32] wrtp: Yep, +1 on Addr too [13:32] niemeyer: there was also a discussion about where to put this kind of helper function. [13:33] niemeyer: i wondered if it might make sense to make environs/jujutest more general. [13:33] niemeyer: and perhaps rename it to launchpad.net/juju/go/testing [13:33] niemeyer: TheMue wasn't so happy about that name though, because of the clash with the standard testing package [13:35] niemeyer, http://wtf.labix.org has been mia for a few weeks. [13:36] niemeyer, also the enhanced relation support spec is ready for a review (its been revised and scoped appropriately) [13:36] niemeyer, and g'morning [13:36] hazmat: Morning :-) [13:36] hazmat: Will check it out [13:36] s/it/them [13:37] wrtp: Hmm [13:38] wrtp: jujutest doesn't feel entirely generic [13:38] niemeyer: the name or the stuff in it? [13:39] wrtp: The stuff in it [13:40] niemeyer: it's only two types. if renamed EnvironTests and EnvironLiveTests, i think they'd live quite happily alongside other more generic testing-related functions [13:42] wrtp, I guess the question is, how many other packages will be using them? [13:42] fwereade: all the environs implementations. that's it, probably. [13:42] wrtp, that does suggest to me that it might live more happily under environs tbh [13:43] wrtp: Maybe rename go/environs/jujutest as go/environs/envtest, and create a new go/jujutest/? [13:45] niemeyer: yeah, that would work, although i quite like go/testing as a name [13:45] wrtp: envtesting and testing then? [13:45] niemeyer: sounds good [13:45] wrtp: I don't mind "testing".. we don't use the stock testing package except for hooking gocheck in anyway [13:46] niemeyer: i agree. [13:47] niemeyer: although, to play devil's advocate, the function to create a new zk server will be used in a context where both "testing" packages are imported. [13:48] niemeyer: i'm happy to import "launchpad.net/juju/go/testing" as gotesting, or "testing" as stdtesting though. [13:48] wrtp: The latter, please [13:48] niemeyer: yeah. internal gets preference. [13:49] wrtp: Yeah [13:50] fwereade: do you want to mutate your CL accordingly while i'll make the changes to zk. [13:50] s/\./?/ [13:51] fwereade: (assuming it sounds good to you, of course) [13:51] wrtp, sure, sounds great [13:55] wrtp, except, sorry, I'm slow [13:55] wrtp, we surely don't actually want to leave the temp dir hanging around, do we? [13:56] fwereade: srv.Destroy removes the zk directory and its contents. [13:56] wrtp, doh sorry [13:56] np [14:30] OMG.. [14:30] The charmstore package is biult [14:30] built [14:34] Woohay! [14:34] "You can now launch 64-bit operating systems on the m1.small and c1.medium instances." [14:48] niemeyer: congrats! [14:49] wrtp: 8) [14:49] wrtp: Thanks [14:49] niemeyer, respectively: cool!; grar, constraints change [14:50] fwereade: i was going to make the zk.CreateServer changes independent of the safe-close branch, but the safe-close branch also did all the changes for the gocheck changes, so i think i'll have to wait until that's ready. [14:50] fwereade: sorry. [14:50] wrtp, no worries, I'll just duplicate the setup stuff for now, it's not too much to carry for a limited time [14:51] fwereade: sounds good [14:51] wrtp, although one note I decided not to bother with was "shouldn't the gocheck changes be independent?" [14:51] fwereade: yes, they should. [14:51] Getting no-deps binaries out of "dpkg -L " never gets old [14:52] fwereade: but it takes so long to turn around one branch, i thought it better to do them in the same one. bitten! [14:52] wrtp, yeah, it's a self-reinforcing problem [14:52] robbiew: ping [14:52] niemeyer: i don't understand one bit of that remark :-) [14:52] wrtp, slow turnaround -> bigger diffs -> yet slower turnaround [14:53] wrtp: This command lists the files in a package [14:53] fwereade: yeah. well, the diffs were fairly small for the gocheck changes, hence my merging. [14:54] wrtp, indeed, not an irrational response [14:55] niemeyer: still in the dark "Getting no-deps binaries"? you don't need to explain, BTW :-) [14:55] wrtp: binaries without dependencies [14:57] ah, i understand now. no dynamic library dependencies... [14:59] wrtp: No additional package dependencies, at least.. it does link against some dynamic libraries [15:00] niemeyer: can you tell that from the output of dpkg -L ? [15:01] * wrtp is not versed in the lore of dpkg and friends :-) [15:03] niemeyer: pong [15:06] robbiew: Heya [15:06] robbiew: I could use that RT push :) [15:06] :) [15:06] niemeyer: ticket #? [15:06] wrtp: I can tell there are only two binaries [15:07] robbiew: 51351.. a pretty number! [15:07] lol [15:07] ack [15:07] robbiew: I've contacted #is first, but given the silence filed this RT yesterday with the IRC questioning [15:07] robbiew: and then enhanced to include more details such as the PPA, package name, etc [15:08] robbiew: It'd be great if we managed to find someone in IS that would be indeed interested on mongodb [15:09] robbiew: But I suspect it won't be easy, given previous conversations with James [15:09] heh...my powers of influence only expand but so far [15:11] robbiew: Yeah, not a matter of power in this case.. I was only expressing a desire to find someone there that would be interested, which of course can't be forced in any way [15:11] right [15:12] * robbiew will begin his Jedi mind trick training next week :P [15:13] robbiew: LOL [15:43] and that's lunch time [16:09] So, agent with watcher is ready for review: https://codereview.appspot.com/5782053 [16:38] TheMue: WOOHAY [16:39] I'm now actually blocked on the store since I depend on IS, so I'm moving back onto reviewing mode [16:40] TheMue: i'm having a look now [16:40] niemeyer: any chance you could start with the oldest ones? :-) [16:42] wrtp: Sounds like a plan ;) [16:43] wrtp: Do you have a preference of ordering to make better use of your remaining time today? [16:43] wrtp: *lol* [16:43] niemeyer: jeeze. let me think. [16:43] niemeyer: go-ec2-robustness is the major one that i'd love to see [16:45] fwereade_: Btw, can you help me out a bit by providing a map for your branches? [16:46] fwereade_: I'd prefer to review the tip and then ask you to repropose the ones that have pre-req once the pre-req is merged, so that we have a clean diff to work on [16:46] niemeyer, go-add-cmd-context and go-add-hook-package are the independent ones [16:47] fwereade_: Ok.. would you mind to put the rest of them as Work In Progress at https://code.launchpad.net/juju/+activereviews until their diff in Rietveld is clean for review? [16:47] niemeyer, and kinda go-testutil, but that depends on gozk changes which themselves depend on other gozk changes I think [16:47] niemeyer, sounds good [16:47] fwereade_: That's fine.. go-testutil can stay since, even though it has dependencies, they are not polluting the diff itself, right? [16:48] niemeyer, they're not polluting the diff but they are preventing it fromcompiling, I think it's better to WIP that as well [16:48] fwereade_: It's fine to keep it in review then, IMO.. but please just don't merge while the pre-req isn't there [16:48] niemeyer, ok,sounds good :) [16:51] fwereade_: heads up: the zk.Server.Addr method returns (string, error) not just string. just so you know. [16:51] wrtp, cool, thanks [16:55] TheMue, btw, I'm a bit concerned that the agent state branch overlaps uncomfortably with the presence-nodes work I was doing a couple of weeks ago [16:55] fwereade_: in which way? [16:56] TheMue, AIUI the intent was to move away from using ephemeral nodes to signal presence and use presence nodes instead [16:57] fwereade_: didn't know that, sorry. so far i'm doing an almost 1:1 port of the py code. [16:58] TheMue, I haven't looked too closely at everything in that branch yet so I'mnot sure how widespread the impact will be [16:58] TheMue, hopefully it will at least make your code a bit smaller [16:58] TheMue, but I think we've hit a bit of a communications snafu [16:58] niemeyer, ^^ [16:58] fwereade_: do you have something written about it, to help me understanding your idea? [16:59] TheMue, the CL is here: https://codereview.appspot.com/5672067/ [17:00] TheMue, the description is a little terse but a quick scan of the inline docs should be helpful [17:00] fwereade_: will take a look [17:00] TheMue, cheers [17:02] TheMue, fwereade_: i think you're right. it seems it was an unfortunate place to start... :-) [17:02] fwereade_, TheMue: Agreed [17:02] TheMue: Please check out the IRC logs [17:02] niemeyer: are there any logs of this channel? [17:03] wrtp, TheMue: http://irclogs.ubuntu.com/2012/03/08/%23juju-dev.html [17:04] niemeyer: cool. which user is doing the logging? [17:04] we've got a meeting now, right? [17:04] wrtp: ubuntulog2 sounds suspect [17:05] lol [17:06] niemeyer: thx, will do so, but scanning a lot of fluent and overlapping discussions is sometimes painful. don't we have a better way to discuss larger technical changes in a threaded way? [17:06] ah, logs have only been for the last two weeks [17:07] niemeyer, btw, wrtp's gozk locking change is a bit of a heavyweight blocker: rog has one stacked behind it, I have one stacked behind each of those, and TheMue's agent work will likely want to change based on one of *those* [17:07] TheMue: Sorry, but that's how the discussion took place.. fwereade_, rog and myself have been punching that idea for several days here in this channel [17:08] niemeyer: yes, it can't be changed for the past, no pro. but i'm looking for an idea for the future. [17:08] TheMue: your best bet is to look at fwereade_'s current proposal, i think [17:08] wrtp: as i already wrote i'll do this [17:08] niemeyer, TheMue: I think we're at the point where we're only going to have more conflicts if we're not aware of exactly what we're working on [17:09] TheMue: Even in the future, this channel will continue to be the best place to discuss ideas like that live [17:09] TheMue, for example, I had some vague idea you were working on relation state [17:09] TheMue: and the comments on that proposal are moderately coherent, i think [17:09] TheMue: Major features will have associated specs and whatnot [17:10] TheMue: But this one, specifically, was developed very organically.. [17:10] niemeyer: for a quick discussion irc is ok, but i'm missing a proper way to gather the conclusions out of thos multiple discussions in different time zones [17:10] fwereade_: i've got to wait with relations. we'll discuss it then. [17:10] TheMue: Even better than gathering conclusions, in such an area that affects you directly, is paying attention to the channel and participating in it so that you're part of the team solidifying the idea [17:12] TheMue: The conclusion, though, is available. fwereade_ has a branch, with a short and nice implementation of everything that was debated. [17:12] TheMue: Please let us know what you think about it. [17:12] niemeyer: yep [17:14] hazmat, niemeyer, jimbaker, bcsaller, TheMue, fwereade_, niemeyer: are we doing a meeting, or defer it for a week? [17:15] wrtp: I'm listening to the charm school webcast still [17:15] wrtp, i'm good either way [17:15] wrtp: I'm game to defer it, if no one has important needs to be discussed [17:15] I'd rather focus on reviews.. [17:16] niemeyer: sounds good to me :-) [17:16] wrtp: thx for review [17:17] TheMue: np [17:21] fwereade_: I'll review the gozk locking now, then [17:23] I wish Rietveld had a handy "Diff since my last comment" button [17:24] wrtp: LGTM on safe-close [17:24] fwereade_: ^ [17:24] niemeyer, sweet [17:24] niemeyer: i usually click on the comment, then adjust the view manually to show that revision and the latest one. [17:24] niemeyer: cool, thanks. [17:24] wrtp: That's what I do as well.. still boring, though [17:25] wrtp: Certainly better than anything else I used to do, OTOH [17:25] niemeyer: i was happy when i discovered that using the keyboard shortcuts keeps the revisions intact. [17:25] niemeyer: IMHO clicking "next" and "prev" should do too. [17:25] wrtp: It does for me.. ? [17:28] niemeyer: hmm, it does for me too now. maybe it didn't work before. or more likely it's that crack again. [17:30] :-) [17:31] * wrtp got the tool to wire the RJ45 jacks today... goodbye flaky wireless connection! [17:32] (assuming i actually manage to use it properly.) [17:32] wrtp: :-( [17:33] wrtp: Welcome to my reality too.. [17:33] wrtp: I think the "attempt" stuff is obscuring the actual logic going on in these functions, for little practical benefit [17:34] wrtp: I'd be curious to see a "for" versions that used a couple of constants.. I suspect it might be shorter, or of the same length at most [17:34] wrtp: and will be a lot more readable [17:36] wrtp: In the end, all of the logic around attempt is an abstraction for a for loop with a sleep, which somewhat of a trivial construct [17:37] niemeyer: i appreciate that point of view [17:38] niemeyer: but that logic in attempt.do is actually a little more complex than that (it's two for loops) and it's nice to have the policy centralised (for instance we might do exponential backoff or random delays) [17:38] wrtp: We might make it more complex, but we might also not, if the simpler version tends to work. [17:39] wrtp: [17:39] 72 » err := longAttempt.do( [17:39] 73 » » func(err error) bool { [17:39] 74 » » » return err == noDNS || err == environs.ErrMissingInstanc [17:39] e [17:39] 75 » » }, [17:39] 76 » » func() error { [17:39] wrtp: This is completely unreadable by itself [17:40] wrtp: I suspect the for version of this same function would be trivial [17:41] niemeyer: obviously i'm biased, but if it you read it as "while transient() {body}" then i think it's ok to read [17:41] wrtp: Let me write the for version then.. [17:41] niemeyer: that is the most complex example, of course. [17:43] The Unity in precise right now is disturbingly broken.. :( [17:46] niemeyer: if we only need one loop then you're probably right. the two loop thing (one fast, for eventual consistency) and one slow (for other stuff) came out of discussion on this channel. [17:46] goodnight all, see you tomorrow :) [17:47] fwereade_: Have a good one! [17:47] fwereade_: nighty night [17:47] niemeyer: here's one example as a loop: http://paste.ubuntu.com/874880/ [17:47] fwereade_: bye [17:48] niemeyer: or, a slightly alternative phrasing: http://paste.ubuntu.com/874882/ [17:49] niemeyer: but both of those would make it hard to move to a less naive way of timing out. [17:51] actually, i have another idea [17:51] wrtp: http://paste.ubuntu.com/874887/ [17:52] niemeyer: there are two retrySleep constants, of course. [17:52] wrtp: Why? [17:52] niemeyer: short and long. [17:52] wrtp: Why? [17:52] niemeyer: short for pure eventual consistency issues [17:53] niemeyer: long for stuff that takes ages [17:53] wrtp: Why do we need two constants, still? [17:53] niemeyer: the DNS stuff can take 2 or 3 minutes. [17:53] niemeyer: other stuff is good within 5 seconds [17:53] wrtp: and it may also not.. [17:54] wrtp: I'd say let's have a single constant that feels enough a delay to not burn CPU/network to a noticeable level, and use it in both circumstances [17:54] niemeyer: well, neither might the DNS name be ready in 3 minutes. we've got to choose a limit somewhere [17:54] niemeyer: hi [17:54] andrewsmedina: Hi [17:54] niemeyer: the problem is sometimes we *expect* an error. and we don't want to time out the whole three minutes when 5 seconds is enough. [17:55] wrtp: Sure, let's use 5 seconds for both then [17:55] wrtp: In computational time, 5 seconds is an eternity [17:55] niemeyer: we can't. then users of the ec2 environ need to know about the constants themselves. [17:56] [17:53] niemeyer: the DNS stuff can take 2 or 3 minutes. [17:56] wrtp: Huh? [17:56] wrtp: and it may also not.. [17:56] wrtp: I'd say let's have a single constant that feels enough a delay to not burn CPU/network to a noticeable level, and use it in both circumstances [17:56] niemeyer: yeah, but it *always* takes more than a minute [17:57] wrtp: Not necessarily.. [17:57] niemeyer: whereas the other stuff *always* takes less than 5 seconds [17:57] wrtp: Please complete the sentence: "Using 5 seconds for both will be *really* bad because ..." [17:58] niemeyer: ... because we'll always return an error for the DNS name when booting up and trying to connect. [17:58] wrtp: Why? [17:58] niemeyer: because the DNS name takes longer than 5 seconds to be set. [17:59] wrtp: This is the *sleep*, not the limit [17:59] niemeyer: i'm sure i discussed this with you before. [17:59] niemeyer: oh, sorry, i was talking about the limit [17:59]