[00:17] andrewsmedina: Heya [00:17] andrewsmedina: Just delivered a review on your branch [00:18] andrewsmedina: Seems pretty close.. [00:18] andrewsmedina: just trivial stuff [00:20] Achievement unlocked! [00:20] Nothing to review on the Go front! [00:20] Phew [00:45] niemeyer: thanks for review! I will work to resolve the things that you said === davechen1y is now known as davecheney [04:16] anybody here? [05:06] * davecheney waves [05:28] andrewsmedina: are you doing a full port for the local provider to juju/go ? [05:28] that would be awesome [06:31] davecheney: hiya [06:35] aoy [06:56] davecheney: i'm a big fan of sharing-memory-by-communicating in general, but sometimes a mutex gets the job done more cleanly IMHO. http://paste.ubuntu.com/1000362/ [06:57] davecheney: (which also has the advantage that we don't serialise all requests) [07:00] rogpeppe: yup, that will work also [07:01] there is no reason why we couldn't also do [07:01] case cmd := <- p.cmd ; go cmd(p.env) [07:02] i'm not sure gustavo is sold on the idea of a proxy yet [07:02] but I do admit your idea is simpler [07:03] davecheney: invoking go doesn't quite have the same semantics (something may be operating on the environment while it changes) but perhaps that doesn't matter. [07:04] rogpeppe: it's fine to operate on a stale copy [07:04] because that is inevitable [07:04] davecheney: if i'm passing a function into a goroutine just to get mutual exclusion, then i start to think i'm doing something a bit wrong. [07:04] rogpeppe: i was following the way the topology worked [07:05] * rogpeppe obviously hasn't looked too closely at that code :-) [07:07] davecheney: if you don't care whether things can run on the same environment when it changes, then things can be even simpler: http://paste.ubuntu.com/1000370/ [07:08] nice [07:08] i'll take that, thank you [07:08] davecheney: cool, glad to be of help. [07:09] i had some reason why it needed to be the original way [07:09] but I can't remember them now [07:09] so until I do [07:09] lets go for simplicity [07:14] davecheney: one thing: do we really need to block in NewProxyEnviron? can't we just let the first operation block until there's a valid environ? [07:14] nope, no need to block [07:14] davecheney: that would simplify things even more: http://paste.ubuntu.com/1000379/ [07:14] that was a personal chioce [07:14] davecheney: down from 167 lines to 86 :-) [07:14] excellent [07:15] i won't mention that it won't compile anymore [07:15] davecheney: minor details [07:15] :-) [07:15] ahh, that is why we block til a valid environ [07:15] so we don't need to check for nil [07:16] davecheney: ah, that's easy to fix too. [07:16] when NewProxyEnviron returns, there is something that proports to be an envion there [07:16] so no worrying about NPE [07:17] davecheney: something like this, perhaps? http://paste.ubuntu.com/1000381/ [07:17] no thanks [07:17] locked isn't protected by a mutex, and the locks and unlocks are unbalanced [07:18] davecheney: locked doesn't need to be protected by a mutex (it's local). we ensure that the lock is held on entry to loop. but yeah, it's not so pretty. [07:19] davecheney: i had the locked logic wrong BTW: http://paste.ubuntu.com/1000384/ [07:23] davecheney: a slightly less unsavoury option: http://paste.ubuntu.com/1000388/ [07:24] davecheney: but maybe it's best just to do the wait explicitly in NewProxyEnviron as before. [07:24] lets wait for the request that it doesn't block during startup [07:25] i don't see it as a issue, as nothing can act on the Environ til it's valid anyway [07:25] thanks rogpeppe that made the code a lot simpler [07:26] tests still don't pass, but whatever [07:26] the main goal is to convince gustavo why a proxy is a good way of managing the unstable environment [07:26] davecheney: i think that the simpler it is the more likely we are of that [07:28] davecheney: BTW i'm not convinced this deserves its own package. it's quite specific to the provisioning agent, isn't it? [07:28] i hope that it makes it easier to test [07:28] ie, we test we can do all the dummy tests against this Environ [07:28] rather than trying to test it via the provisioning agent [07:29] davecheney: there's nothing stopping us having internal tests for the provisioning agent code [07:29] but your point is well made that in theory the provisinng agent is the only one talking to the Environ [07:29] davecheney: i've done that quite a bit in the ec2 provider [07:29] davecheney: also, as a general mechanism it's not quite there [07:30] davecheney: because if a client keeps a Storage around, that won't work well - you'd have to proxy that too. [07:31] rogpeppe: yup - i saw that, maybe that can be solved via convention [07:31] on error, get a new storage [07:31] davecheney: yeah, but will the provisioning agent actually be writing to storage ever? [07:31] davecheney: i.e. do we really care? [07:31] rogpeppe: that, i do not know [07:32] davecheney: we could have a Storage method that just paniced. [07:33] davecheney: (or returned a Storage that always returned an error, i suppose) [07:34] davecheney: oh, i'm talking bollocks, of course the provisioning agent needs to talk to the storage. [07:34] ok, i'll make a proxy storage [07:35] davecheney: yeah. it could always call the relevant storage method in proxy before invoking its method. [07:46] davecheney: it's slightly easier if you assume that the provisioning agent will never need to *write* to the storage (which i think is the case) http://paste.ubuntu.com/1000412/ [07:46] davecheney: and i'm thinking that it's probably best to have NewProxyEnviron block until the environment is valid, and let the caller deal with that. [07:46] davecheney: rather than putting an error test in every method. [07:49] davecheney: anyway, i should get back to my *own* damn code! [08:08] rogpeppe: thanks for your help [08:08] out [11:18] morning. [11:21] Aram: hiya [12:00] gotta love ec2 request reliability [12:15] rogpeppe: Why? [12:15] rogpeppe: Heya btw. [12:15] TheMue: (hiya too) i've run the environs/ec2 amazon tests four times in a row and they've failed each time for different reasons. [12:16] TheMue: we really need some retry logic at the goamz/ec2 level - that will help a lot. [12:17] TheMue: it's great when a test fails 3/4s of the way through, reading a file that it already read successfully, saying "file not found" [12:17] rogpeppe: Yes, transparent for the user. Only real hard errors we know should raise. [12:17] TheMue: yeah. you can't deal with the eventual consistency stuff automatically sadly. but the "premature EOF" and "handshake failure" errors are entirely possible. [12:18] rogpeppe: Is EC2 in general so unreliable? Or is it only a special part of their API? [12:19] TheMue: i have a feeling it's all that unreliable [12:19] TheMue: but i only have the one data point [12:19] rogpeppe: Uuh, not good. [12:19] TheMue: it applies to S3 too [12:19] TheMue: yay, put in a couple of retry loops and it all works now [12:21] rogpeppe: Are there any hints by Amazon on an optimal retry strategy (how often, which delay between requests, …)? [12:21] TheMue: no. they don't even talk about eventual consistency issues. it all looks hunky-dory in their docs. [12:22] rogpeppe: I've got to admit that I expected this answer. I only had a little hope left. [12:22] TheMue: building on shifting sands... [12:24] rogpeppe: So take a house boat, able to move but tied in place. [12:26] TheMue: right, time for some lunch [12:26] rogpeppe: Enjoy, I just had. [12:39] Hullah! [12:49] niemeyer: Moin. ;) [12:49] TheMue: Heya [12:58] niemeyer: I'm just thinking about the "endpointInfo" in topology.go. It's indeed no beatiful solution and tries to wrap what "get_relation_service" and "get_relations_for_service" return in the Python version. [12:59] niemeyer: Its really very similar to "RelationEndpoint2, only that there are names while "endpointInfo" deals with keys. [13:00] TheMue: Right [13:01] niemeyer: I could add the keys to "RelationEndpoint" as private fields, that would safe us one type [13:01] TheMue: Why do we need the keys there? [13:01] TheMue: See the Python code [13:02] niemeyer: Have to look, one moment. It's taken from the Python code. [13:02] TheMue: I don't think it is [13:02] TheMue: This branch diverges wildly from Python all around [13:05] niemeyer: The information that the two functions using the "endpointInfo" returns is the same like the two Python functions named above. [13:05] niemeyer: But there dynamically lists and dictionaries are taken. [13:05] TheMue: That's not what we were talking about.. [13:05] niemeyer: I could add the keys to "RelationEndpoint" as private fields, that would safe us one type [13:06] TheMue: Why do we need the keys there? [13:06] TheMue: See the Python code [13:09] gorgeous weather out there for a change. [13:10] niemeyer: mornin', BTW [13:10] niemeyer: "get_relations_for_service" stores at least the "relation_id", I don't yet know where it is used. Regarding the "ServiceKey" William and I discussed that it's better than the name, which can be retrieved via "ServiceName(key)". [13:11] niemeyer: thanks a lot for the review last night. you might've seen two tiny branches proposed this morning: https://codereview.appspot.com/6220065/ and https://codereview.appspot.com/6221058/ [13:13] rogpeppe: Morning [13:14] TheMue: Sorry, I don't understand what you mean.. the service key is a service key, the service name is a service name. Neither is better than the other without context. [13:14] rogpeppe: No, haven't run through reviews yet [13:14] niemeyer: that's fine. they're both independent anyway, [13:15] rogpeppe: That's great, thanks [13:17] niemeyer: If I have one of it (service name or key) I can retrieve the other (only that from key to name is a bit faster). For relations I need the key to retrieve the name. [13:18] TheMue: Yes. How does that change the picture in the scenario we were talking about earlier? [13:18] TheMue: You can use RelationEndpoint to work with relations in the same way that Python deos. [13:18] does [13:18] TheMue: You don't need to store any private keys in RelationEndpoint. [13:19] niemeyer: That's only a first observation for me to get a better understanding [13:19] TheMue: RelationEndpoint needs a RelationName [13:19] TheMue: All of that has to be fixed [13:19] TheMue: And all of it are divergences from what Python does [13:19] niemeyer: It has now a name. [13:20] TheMue: Simplifying is cool, but it needs a lot of attention to what is being done if we are to diverge from what is being done in the Python code. I get quite nervous when I see the implementation diverging wildly both in terms of implementation and in terms of *semantics*. [13:21] niemeyer: What I'm looking for is how to optimally return informations that get_relations_for_service and get_relation_service return. [13:21] TheMue: Ok, let me look at that [13:21] niemeyer: There they are e.g. dynamic lists with the interface as first field and service topology as second field. [13:22] TheMue: What is "service topology"? [13:22] niemeyer: For the rest I already adopted your suggestions. [13:24] TheMue: I suppose get_relations_for_service should return []relation? [13:24] niemeyer: Eh, wrong wording, see return (relation_data["interface"], relation_data["services"][service_id]) [13:25] niemeyer: Good idea, would only have to add the key here (currently it doesn't has). [13:26] TheMue: Yeah, that sounds fine.. RelationKey [13:26] Well, not really [13:26] TheMue: relation{ Key: ... } [13:26] niemeyer: It would be persisted. [13:26] TheMue: Not necessarily.. omitempty [13:26] niemeyer: Ah, yes, I remember. [13:27] TheMue: service=services[service_id])) [13:27] TheMue: What is that data in the service key? [13:29] {"role": r, "name": n}, I suppose..? [13:29] niemeyer: The function only looks for one service. So our Services map would contain the role and the key. [13:30] TheMue: Why does it do that? I'm not sure we should mimic it [13:30] niemeyer: Let me look for a consumer of this function, moment. [13:30] TheMue: If we get a relation back, it should be the actual relation, with its actual.. it's not clear to me why we should be stripping it off arbitrarily [13:31] s/its actual/its actual data/ [13:31] TheMue: I was looking at that too.. still not clear.. feels like a poor interface [13:31] niemeyer: So far I don't see any reason too. [13:32] TheMue: Ok.. let's just return a proper relation with its real data then [13:32] TheMue: If we find out why we can talk again [13:32] TheMue: But I suspect this should do quite nicely [13:32] niemeyer: Think so too. [13:32] niemeyer: At least it "feels" better than my current solution. [13:36] rogpeppe: You got a major LGTM, and a major OMG WHAT ARE YOU DOING? [13:36] niemeyer: interesting [13:37] niemeyer: the way to fix that OMG is to implement signed URLs in s3, which i haven't got around to yet. [13:37] niemeyer: if i put in a TODO, would that be ok? [13:38] rogpeppe: No.. we're not making anything public and swiping that under the carpet [13:38] s/anything/everything/ [13:38] rogpeppe: Been there, doesn't end up well [13:38] niemeyer: ok. i'll do the s3 thing first then. [13:39] niemeyer: only problem is, i looked for how to do the signed URL thing before and didn't come up with anything [13:39] rogpeppe: I can do that if necessary [13:39] rogpeppe: Actually, let me do that [13:39] rogpeppe: Are you happy with the former s3 branch? [13:39] niemeyer: just a pointer to some docs would be fine. or, if you wanna do that, that would be lovely too! [13:39] niemeyer: oh shit, forgot about that. one mo. [13:40] rogpeppe: Cheers [13:55] niemeyer: you've got a review [13:58] rogpeppe: "could we give a nicer error here when we panic?" [13:58] rogpeppe: When would it panic? [13:59] niemeyer: if the host in the headers didn't have two dots in it? [13:59] rogpeppe: This code can't execute if that's the case [14:00] niemeyer: ah yes. [14:00] rogpeppe: Will fix the rest [14:00] rogpeppe: Thanks for the review [14:00] niemeyer: doh, sorry for that [14:01] rogpeppe: np [14:01] rogpeppe: I'll add the "" on a line on its own.. it's not using field names purposefully in this case [14:02] niemeyer: that's fine [14:02] rogpeppe: It should fail if we add a field and forget to update one of the structs [14:02] niemeyer: sure. [14:06] rogpeppe: ${bucket} would probably be a more sensible replacement var [14:07] niemeyer: yeah, that would be fine. although if there's ambiguity between $name and the rest, there's gonna be ambiguity between the bucket name and the rest... [14:07] rogpeppe: Hm? [14:07] niemeyer: isn't that why you're preferring ${bucket} ? [14:08] niemeyer: because it's unambiguously replaceable? [14:08] i suppose the host name might have a $ in. [14:08] if that's allowed [14:08] rogpeppe: $namesis shouldn't get replaced [14:10] niemeyer: yeah, true. it's a URL really and URLs can contain $s [14:10] niemeyer: ${bucket} is just fine. [14:10] niemeyer: lots better than %s :-) [14:12] rogpeppe: Indeed [14:15] "@ylastic #AWS #EC2 API calls returning intermittent errors "Unavailable: Unable to process request, please retry shortly"" [14:15] Things are getting more and more "eventual" [14:18] rogpeppe: Branch re-proposed [14:19] niemeyer: it's wonderful. i tried the amazon test 4 times in a row this morning and it failed each time with a different error. we need to get that retry logic in! [14:22] niemeyer: LGTM [14:23] rogpeppe: Thanks [14:23] rogpeppe, niemeyer morning :D [14:23] andrewsmedina: hiya! [14:24] rogpeppe, niemeyer thanks for review [14:24] andrewsmedina: np. thanks for bearing with us! [14:24] rogpeppe: when you have a time, I wanted to talk with you about the reivew [14:25] andrewsmedina: i've got a meeting in 5 minutes, but in an hour or so, no problem. [14:32] rogpeppe: ok [14:50] andrewsmedina: ping [14:57] rogpeppe: pong [14:57] rogpeppe: about the %d [14:58] andrewsmedina: about the %d [14:58] rogpeppe: virsh use the %d to create a autoincrement number for the net/bridge name [14:59] rogpeppe: the juju python version uses it [14:59] andrewsmedina: is that needed, given that the name needs to unique anyway? [14:59] s/to /to be / [15:00] andrewsmedina: fair enough. *is* it actually documented anywhere, or is it just a bit of black magic known to those who've read the source? [15:01] rogpeppe: http://bazaar.launchpad.net/~juju/juju/trunk/view/head:/juju/providers/local/network.py#L13 [15:02] rogpeppe: I dont know if this is a oficial feature =/ [15:02] andrewsmedina: ok. i see that, thanks. but i'd like to know why we're doing that. or at any rate write a comment saying what it's there for. [15:03] niemeyer, hazmat: do you know, by any chance, why we need an autoincrement number in the lxc network bridge name? [15:03] rogpeppe: I will do a comment about it [15:03] andrewsmedina: thanks a lot [15:03] rogpeppe: about the split [15:03] rogpeppe, we do? we just use the default libvirt name [15:04] s/name/network [15:04] rogpeppe: virsh always returns the same string pattern [15:04] hazmat: see link above [15:04] I need to check anyway? [15:04] hazmat: http://bazaar.launchpad.net/~juju/juju/trunk/view/head:/juju/providers/local/network.py#L13 [15:05] andrewsmedina: yes, but virsh isn't part of the juju program. if someone changes the virsh output, we want a "unexpected virsh output" error or similar, rather than an array bounds panic. [15:05] andrewsmedina, we don't specify that value [15:05] andrewsmedina, its escaped because libvirt uses it [15:05] %%d [15:05] hazmat: why do we need it? [15:06] rogpeppe, we don't.. libvirt does [15:06] hazmat: isn't the bridge name unique enough, given that it includes the network name? [15:06] i'd suggest not being slavish about copying that aspect.. i've got a separate branch local-cloud-img that gets rid of libvirt entirely [15:07] launch time :( [15:07] sorry [15:07] rogpeppe, its not [15:07] hazmat: ok. [15:07] hazmat: when you say "getting rid of libvirt", you mean "not using virsh" ? [15:08] hazmat: i haven't looked too deeply into how all the lxc stuff is set up. i should! [15:08] rogpeppe, no i mean getting rid of libvirt [15:08] rogpeppe, the name comes out virbr [15:08] again this has nothing to do with juju [15:08] this is libvirt's configuration [15:09] and it needs that string insertion for its templates %d [15:10] hazmat: i didn't see any mention of the %d in the libvirt docs. but i'm probably looking in the wrong place. [15:10] hazmat: (i looked in [15:10] http://libvirt.org/formatnetwork.html and [15:10] http://libvirt.org/sources/virshcmdref/html/sect-net-define.html [15:10] ) [15:11] hazmat: so your branch eschews the portability layer and talks to lxc directly? [15:11] rogpeppe, what portability layer? [15:12] rogpeppe, i think your misunderstanding something fundamental here [15:12] hazmat: libvirt looks like a portability layer to me, but i may be misinterpreting [15:12] hazmat: almost certainly! [15:12] rogpeppe, we don't use libvirt outside of setting up the network [15:12] rogpeppe, its a rather broken portability layer when it comes to lxc [15:12] rogpeppe, it has many additional functionalities that have no meaning on the context of lxc [15:12] hazmat: sure. but that is the role it's trying to play, no? or i'm i fundamentally misunderstanding? [15:12] It's lunch time [15:12] rogpeppe, we're just piggybacking on its packinging of a default network [15:13] in the lxc in precise, this is also in the lxc package [15:13] moreover local provider doesn't use cloud-init or cloud images at the moment, the branch i mentioned local-cloud-img, rips out libvirt, uses cloud images for local provider, and uses cloud-init to configure [15:14] rogpeppe, yes libvirt is an abstraction layer over different virt providers [15:14] hazmat: ok, cool. i'm not too far off then! [15:14] rogpeppe, but its not particularly good for several of them [15:15] hazmat: that's in the nature of portability layers i guess. lowest common denominator. [15:15] rogpeppe, for example openstack uses libvirt to address several different tech, but there are also standalone providers for some of the same ones that libvirt provides an abstraction for [15:15] within openstack [15:15] rogpeppe, its actually quite rich as a common api, but in the context of lxc specifically its typically out-of-date, and overkill [15:16] rogpeppe, we had a discussion about trying to use libvirt directly a while ago instead of lxc directly [15:16] hazmat: given that we're directly reliant on lxc in other aspects, i'd be inclined to agree, although i haven't looked at how hard it is to configure networks in lxc directly. [15:16] hazmat: that's the other possibility of course [15:17] rogpeppe, its pretty trivial, just needs the packaging effort around creating the bridge, etc [15:17] trivial to configure that is [15:17] * hazmat preps for his next meeting [15:17] andrewsmedina: anyway, with a comment, i'm happy with that code. [15:49] TheMue: i see sporadic test failures testing state: http://paste.ubuntu.com/1001083/ [15:51] TheMue: I've done no changes at watcher for a longer time, but I've just merged the trunk into my branch and get a watcher failure too. [16:02] TheMue: i don't *think* it's my fault :-) [16:10] * niemeyer waves [16:10] TheMue: Perhaps a race? [16:17] niemeyer, TheMue: i suspect a race, or an inadequate timeout. [16:17] niemeyer: BTW if i take out that PublicRead change, does that "make amazon tests work" branch LGTY? [16:17] rogpeppe: I've stopped checking it out there [16:18] So, back, had to do an emergency repair here (jalousie broke down). [16:18] niemeyer: ok. 'cos i need that branch in an upcoming branch that already has a dependency... [16:27] rogpeppe: Ok, what's the plan? [16:28] niemeyer: i've pushed that branch without that change. the amazon tests no longer pass of course, so i'm changing it temporarily locally so i can test. but the other changes are less trivial and also necessary. [16:28] niemeyer: so when s3 implements signed URLs we'll use them and the amazon tests will pass [16:29] rogpeppe: Ok, I mean what's the plan as far as the branch goes [16:29] niemeyer: the "fix amazon tests" branch? [16:29] rogpeppe: Whatever branch you mean.. yous said you need that branch.. what's your plan [16:30] rogpeppe: I few moments ago I had your watcher error too, but now everything runs. Will investigate it later. [16:30] niemeyer: i'll hold off proposing again until the "fix amazon tests" branch is in. [16:31] rogpeppe: Ok.. so I'm' not sure about what you meant [16:31] niemeyer: BTW if i take out that PublicRead change, does that "make amazon tests work" branch LGTY? [16:31] niemeyer: ok. 'cos i need that branch in an upcoming branch that already has a dependency... [16:31] niemeyer: it would be nice to have a review of the "fix tests" branch so i can propose that upcoming branch [16:31] rogpeppe: You already have a review.. there's a change that can't go in [16:31] niemeyer: it no longer has that PublicRead change [16:32] niemeyer: i've re-proposed it [16:32] rogpeppe: Ok.. so you've reproposed and you want another review? [16:32] niemeyer: yes please [16:32] niemeyer: you should have got a mail saying "please take a look" :-) [16:32] rogpeppe: Heh [16:33] rogpeppe: That's a pretty difficult way to ask for a review [16:33] rogpeppe: Will have a look [16:33] niemeyer: isn't that implied? if not, what's the point of the mail? [16:34] rogpeppe: You see the history above? [16:34] rogpeppe: "Please have a look at http://... again" is fine [16:34] niemeyer: fair enough [16:35] niemeyer: (but i thought that was the point of the "Please take a look" email!) [16:35] rogpeppe: Nevermind! [16:35] yay! go tools now working on the server again... [16:41] niemeyer: BTW while (if?) you're on little reviews, this is trivial, assuming you agree with the premise. https://codereview.appspot.com/6188068/ [16:50] rogpeppe: What's the point of these loops? [16:50] for i := 0; i < 5; i++ { [16:50] ? [16:50] niemeyer: ping [16:50] andrewsmedina: hi [16:50] niemeyer: thanks for your review [16:50] andrewsmedina: np [16:50] niemeyer: I think it is okay [16:50] now [16:50] niemeyer: same as for other eventual consistency issues [16:51] niemeyer: i copied the retry code from elsewhere. we could use a different retry time or count [16:51] rogpeppe: Ok, can you please reduce the delay on each retry then, to maybe 1e8, increase the limit to 30 or so, and add a comment explaining? [16:51] niemeyer: ok, will do, and in the other place too. [16:51] rogpeppe: No need to be too extensive in the comment, just a reminder [16:52] niemeyer: I will work on local provider interface now: p [16:52] rogpeppe: Thanks [16:53] rogpeppe: "LGTM assuming reduced timeouts and increased N as discussed online." [16:53] niemeyer: thanks a lot [16:56] rogpeppe: No problem.. that was easy :) [16:56] rogpeppe: Hopefully we can get a fix to the signature issue in very soon [16:56] rogpeppe: I'll try to address that today still [16:57] *splash* [16:57] (the sound of a branch landing) [16:58] niemeyer: It needed something more to my proposal be accepted? [17:00] right, gotta go. have fun all. see you tomorrow. [17:13] rogpeppe: See ya [17:13] andrewsmedina: I haven't re-reviewed your branch yet [17:13] andrewsmedina: have you addressed the latest comments by rog/ [17:13] ? [17:19] aujuju: What is the best way to use the mysql charm in Juju with dynamic database credientials? [17:50] niemeyer: yes, about %d rog said it is ok [17:50] niemeyer: about split, virsh always returns the same pattern [17:50] andrewsmedina: Cool, need to step out for a doc appointment.. back soon, though [17:50] niemeyer: I'm using the same strategy used in juju python code [17:51] niemeyer: ok [17:55] Multiple IPs!! [17:56] * SpamapS does a dance [17:56] niemeyer: great news! [17:56] the multiple IPs, not the doc appointment ;) [18:08] SpamapS: :-p [19:25] SpamapS: Indeed!! [20:48] Ouch.. that's the sleepiest time of the day [20:54] Alright, not working.. I'll do it Windows style and take a short nap to reboot [20:54] sleep is when the garbage collector runs. [22:00] davecheney: Morning! [22:00] Aram: Indeed [22:02] mornign! [22:02] niemeyer: lets talk about the proxy environ [22:02] davecheney: Yeah, was planning on that too [22:03] davecheney: Good we're overlapping today [22:03] how can I convince you of it's utility [22:03] davecheney: Hehe :-) [22:03] niemeyer: yes, sorry about that, i had to go intot he city to finish some of the employment paper work that was dropped when veronika moved on [22:03] davecheney: Ah, no worries at all [22:04] davecheney: The concept of having such a wrapper feels pretty icky to me [22:04] niemeyer: ok, maybe the name is a problem [22:04]