[00:04] SpamapS, any chance you haven't uploaded already? [00:04] SpamapS, we where just debating the whole value of using an ip address.. [00:04] versus just using a domain name, and letting dns updates figure it out.. [00:09] hazmat: I am delaying uploading [00:10] I think the IP should be fine as long as there is only one place to change it [00:13] SpamapS, niemeyer if we use the IP we will need to SRU, but the IP will work till then [00:13] SpamapS, yeah.. i centralized all the refs to it, one line change now [00:14] SpamapS:Yeah, hazmat is right.. with a temporary domain, we'll still have to SRU to fix the domain soonish, but we can also switch the A record at the same time to the real store [00:14] SpamapS: Which means we can stop the temporary store as soon as the new one is live [00:14] (and the domain cache expires) [00:15] I'd be much happier with a single line change SRU to re-point things than a non-working distro version.. :) [00:15] Would be nice if users could work around archive sync issues with an environment variable tho [00:17] SpamapS: Hmm.. there's no reason for the distro version to be non-working.. that's actually another argument in favor of the domain name [00:17] SpamapS: Much better than a variable too, because it actually works without any environment changes [00:18] I guess my point is, if you can get a version out now that works with the store, but introduces a potential need to re-point things later.. I'd prefer that over no store functionality. [00:22] SpamapS: We're on the same page [00:22] SpamapS: Let's point the code to juju-store.labix.org [00:22] SpamapS: I'll make that work over the next couple of days [00:22] SpamapS: If we need to SRU later, it'll be just to have it pointing to something more official. That domain can continue working for as long as necessary. [00:23] hmm [00:23] I'm just looking here.. [00:23] how does the charm store protect against MITM? [00:24] I see no security in there [00:25] * SpamapS fights the urge to facepalm [00:26] SpamapS: There's none anymore.. that was https, and will be back one day once we manage to make devops a reality. [00:26] Ok, so, in that case, I'd rather not have a charm store. :) [00:26] SpamapS: Please don't facepalm.. I've been doing that and it's starting to hurt.. [00:27] at least with bzr branches from launchpad, you have ssh closed loop with users uploading [00:27] SpamapS: OKAY.. maybe I should just shutdown the computer and get a beer. :) [00:27] niemeyer: maybe we should invent a special glove with soft palms for doing code review. :) [00:28] SpamapS: It's not even about code reviews.. it's really about the store [00:28] niemeyer: I have some thoughts on how we can have our charm store cake and eat it too .. we'll need to embed a CA cert in juju but its better than nothing. [00:29] SpamapS: I just want this thing live.. we can very easily improve things, move back and forth and so on [00:29] OR we can all chip in $20 and get a real cert ;) [00:29] SpamapS: We'd not even have to pay.. there are free certs in some providers [00:29] true [00:30] as long as none of them involve a rectal exam I'll volunteer to investigate [00:30] SpamapS: I've registered one before with a registrar that I can't remember right now, but I have an SSL I can check [00:31] StartSSL.com I believe might work [00:31] SpamapS: If you feel strong about it, just put https://juju-store.labix.org in there, and we'll sort it out [00:31] not sure if their CA is in the ubuntu ca certs.. but we can add one in the packaging [00:31] SpamapS: The ones in that registrar I'm sure i tis [00:31] SpamapS: In the one I don't recall right now [00:31] niemeyer: I'm worried about the fact that charms run as root is all.. [00:32] SpamapS: I know.. there's a reason why it was https://store.juju.ubuntu.com [00:32] niemeyer: indeed [00:32] SpamapS: I've just been conceding on issue after issue [00:33] niemeyer: I don't think we're going to solve this today... sounds like its been a long, weird day today for everybody [00:34] I vote we have it at the original https://store.juju.ubuntu.com [00:34] it will get sorted out when it gets sorted out then [00:34] hazmat: Heh [00:34] in the end that's where its supposed to be [00:34] hazmat: In the end that's where it will be [00:35] hazmat: Not today, not tomorrow [00:35] niemeyer, but before the release i assume [00:35] hazmat: I don't know.. [00:35] hazmat: I don't have control over it [00:35] and it might be solved next week... and its still fine... or even two months from now and its less fine.. but we can have env var for it.. [00:36] hazmat: It's up to you to decide, though.. if you update to that store and it's put live elsewhere, you'll have to deal with the change later. [00:36] its certainly not going to be at an ip address, which is what it is now [00:36] hazmat: I'm happy with whatever, really [00:36] i'd rather pick the final destination, and the rest of it will take care itself... whenever it does [00:37] hazmat: I'll be working to put that store live somewhere [00:37] oddly enough.. the IP is a lot harder to MITM than the hostname [00:37] still not "secure enough" [00:37] one evil wifi is all it would take [00:37] SpamapS: This is a test phase [00:37] but yeah.. I have no answers for you guys.. :-P [00:38] But I don't care, really.. I've been facing way too many walls for that stuff.. I'll just make it work and people can decide. [00:38] i'd like to go ahead and change it back to https://store.charms.ubuntu.com [00:38] If left at store.juju.ubuntu.com ... [00:38] with https... [00:39] could we come up with ways to help people install a ca cert that we provide, for testing, and a /etc/hosts entry? [00:39] I know thats *super* yuck [00:39] just trying to flesh out the options [00:39] SpamapS: IS won't provide me with the SSL for that domain, and they're not happy with it pointing to something I manage either [00:40] Right, but we could use our own CA [00:40] and put that CA in a "juju-testing-ca" package [00:40] niemeyer, are you sure about the store env var.. [00:40] SpamapS: Heh.. using another domain name is a *lot* simpler [00:40] aye [00:40] hazmat: Absolutely [00:40] it is [00:40] ok, I think I'll go see what beer is on sale at whole foods now :) [00:41] I'd love some company for a beer right now, to be honest [00:41] * hazmat too [00:41] St. Paulie Girl is nice company :) [00:41] she always smiles at my jokes [00:41] * SpamapS disappears [00:43] hazmat: The machine is stopped at [00:43] Unpacking python-txzookeeper (from .../python-txzookeeper_0.8.0-0ubuntu1_all.deb) ... [00:43] Setting up python-txzookeeper (0.8.0-0ubuntu1) ... [00:43] You have not informed bzr of your Launchpad ID, and you must do this to [00:43] write to Launchpad or access private data. See "bzr help launchpad-login". [00:44] hazmat: It's also booting Oneiric.. have we not switched to Precise yet? [00:45] hmm.. i've been using default-series [00:45] niemeyer, what do you have specified in your environments.yaml for default-series? [00:46] niemeyer, can you pastebin console output [00:46] hazmat: Nothing [00:46] that bzr message is pretty standard [00:46] hazmat: I mean, I don't have anything special in default-series [00:46] its a one time thing [00:46] niemeyer, do you have 'precise' there? [00:47] hazmat: I don't have the setting at all [00:47] hazmat: Using juju from trunk on 486 [00:47] hazmat: Hmmm.. still using juju-branch, though.. this is bogus [00:48] hazmat: It's juju origin now, isn't it [00:48] juju-origin [00:48] hazmat: Do I need to set the series for it to pick precise? [00:48] lp:juju [00:48] yes [00:48] hazmat: Hmmm.. shouldn't it pick it automatically, given that it's the expected value for 12.04? [00:49] niemeyer, yeah.. i was just digging into why that is [00:49] so the environment doesn't actually require default-series, so its None, but the get ami method has a default release value of oneiric [00:49] hazmat: Alright, using default-series for the moment, switched to juju-origin, and restarting [00:50] i use ec2 on a regular basis [00:51] niemeyer, have you checked gozk for mem leaks? [00:51] hazmat: Hmm.. not that I recall.. why? [00:52] niemeyer, someone handed me a txzk example on #twisted that showed some leakage [00:52] i was about to convert it to another library to isolate where the problem lies [00:52] hazmat: Not entirely surprising.. I've fixed a few leaks early on in python-zookeeper [00:52] yeah.. i suspect the python bindings indeed [00:52] hazmat: and it was entirely "by chance", realizing while looking at the code [00:52] hazmat: I wouldn't be surprised if there's more of the same [00:53] hazmat: Go is mark & sweep, so it's harder to get that kind of leak [00:54] i was going through some of the stdlib yesterday, its quite readable [00:54] hazmat: Okay, kicking another run [00:54] of the wtf [00:55] hazmat: Yeah, they're pretty diligent about it [00:55] hazmat: There was also a serious push for Go 1 [00:55] hazmat: So it's better in quite a few ways than it was 4 months ago [01:13] hazmat: Still no go :( [01:13] hazmat: juju status is blocked again.. [01:13] Will log onto the machine to see what's up [01:13] niemeyer, can you strace it? [01:18] hazmat: Setting up the env [01:20] hazmat: "2012-03-22 21:20:13,919 DEBUG Environment still initializing. Will wait." [01:20] hazmat: Seems to have reached the server [01:22] hazmat: Agents are running.. [01:23] hazmat: zk is empty.. initialization never run indeed [01:25] hazmat: Have you been using juju-origin? [01:25] hazmat: To run with a branch, that is [01:34] hazmat: http://paste.ubuntu.com/895896/ [01:34] hazmat: That's probably it.. [01:42] SpamapS: So, wtf is stopped because deployment is broken for real [01:55] odd [01:57] that's the new setuptools bit for pypi mac installs [02:20] Time for some sleep [02:20] Night all [02:28] its fixed in trunk [02:29] sleep sounds good [09:36] rogpeppe: moin [09:36] TheMue: hiya [09:37] rogpeppe: same beautiful weather like here? yesterday i worked for some hour on our veranda, watching our bunnies on the lawn [09:37] TheMue: it was beautiful yesterday, but today it's misty. [09:38] TheMue: went for a longish bike ride this morning and should have had lovely views but didn't [09:38] rogpeppe: *sigh* hope it will get better today [09:39] rogpeppe: oh, carmen called, should help her with a flower in the garden, brb [09:48] TheMue: who's carmen? [09:49] rogpeppe: my wife, she's doing spring preparations [09:49] TheMue: funny, my wife is also called Carmen! [09:49] rogpeppe: yep, we already talked about it. *lol* [09:50] i'd totally forgotten! [09:50] rogpeppe: hehe [09:50] rogpeppe: allready started uds preparation? [09:50] TheMue: no, am going to book tickets today [09:51] rogpeppe: i've got my flights booked and now doing the ESTA form [09:54] rogpeppe: i would like you or william as room mates, same or almost the same time zones ;) [09:54] TheMue: my time zone is always weird at events like that! [09:55] rogpeppe: hehe [10:24] TheMue: flights sorted [10:25] rogpeppe: fine. i'll arrive sunday arround 12:30 at SFO [10:25] rogpeppe: so enough time to travel to the hotel, look around a bit and go to bed early [10:26] TheMue: i arrive 1420 SFO [10:26] rogpeppe: ah, also not too late [10:26] TheMue: and leave 1855 on the following saturday [10:27] rogpeppe: arrival is 1220, leaving is 1250 [10:57] fwereade_: ping [11:08] rogpeppe: i'm in since 7:31 (your time) and havn't seen him yet [11:08] rogpeppe: maybe he's biking like you [11:08] rogpeppe, pong [11:08] ha! [11:08] TheMue, I'm around, I'm just quiet :p [11:08] fwereade_: hehe, ok [11:09] fwereade_: just wanted to chat about testing strategy [11:09] fwereade_: when you've got a mo [11:09] rogpeppe, 10 mins? want to get a propose in and get a mnemonic test failure in another branch [11:10] fwereade_: np [11:10] fwereade_: any time [11:10] fwereade_: ping me [11:19] i discovered yesterday evening that my ex-lorry-driver neighbour, in his 80s, has installed ubuntu. i'm impressed. [11:20] rogpeppe: maybe he has seen that video of the daddy trying win, os x and ubuntu [11:21] TheMue: i don't think so. apparently a relation of his is using it, so he gave it a go. he says he gets a bit lost when he has to use the command-line... [11:21] TheMue: but otherwise he finds it pretty good. [11:21] TheMue: he's considerably older than the guy in that video [11:22] TheMue: they've been living in this street for 60 years [11:22] rogpeppe: wow [11:23] TheMue: he came across last night because he'd seen my wi-fi network and wanted to warn me that i should secure it properly! [11:23] rogpeppe, golly :) [11:23] rogpeppe: i don't think i'll reach this number here. we have a quite large house, and we plan to move to a smaller one when we get older and the kids have left the house [11:23] rogpeppe, I may have to wait a little longer, cath needs my help a mo [11:23] rogpeppe: he is really fit [11:23] fwereade_: np [11:25] rogpeppe: i've changed my wifi to wpa2. now my sister-in-law who is living in our house too has troubles. she's using xp, and by default it doesn't support wpa2. [11:26] TheMue: oh dear. [11:26] rogpeppe: maybe she should give ubuntu a try too [11:27] TheMue: depends how much she's dependant on windows stuff. some people, particularly those that are somewhat more tech-savvy, find it hard, because the microsoft-compatible apps don't work too well [11:28] rogpeppe: she mostly is doing web and mail and only private usage of office apps from time to time. so it could work. [11:29] TheMue: if she's an Outlook user, it could be hard [11:29] rogpeppe: no, only web mail (thankfully) [11:30] TheMue: she could also install WPA2 support, presumably. [11:30] rogpeppe: i had to use outlook the last 8 years, argh [11:31] rogpeppe: yep, i've dl'ed two fixes. maybe it's working then [11:45] rogpeppe, so, testing [11:45] rogpeppe, I saw your collected random failures which did indeed look a little alarming [11:46] fwereade_: i'm thinking of testing commands [11:46] rogpeppe, ah, ok [11:46] fwereade_: so... i want to try to avoid testing the same stuff many times [11:47] fwereade_: so i'm wondering what you think about putting a dummy environs interface underneath the command stuff [11:47] fwereade_: which sends on a channel when a given operation is executed, but doesn't actually do anything [11:47] fwereade_: although it may start a zookeeper for the state [11:48] rogpeppe, yeah; I think having an *actual* dummy environ type, like we do in pyjuju, and working against a real zookeeper, is probably sensible [11:48] fwereade_: yeah. for the moment i'm putting it in cmd/juju/environ_test.go, but it might be useful elsewhere in future [11:49] rogpeppe, sounds good [11:49] fwereade_: i'm exporting the Environ within juju.Conn [11:49] fwereade_: that way there's a way in [11:50] rogpeppe, cool [11:50] fwereade_: ok, great. just making sure you were ok with the general thrust. [11:50] rogpeppe, definitely sounds sensible to me [11:50] fwereade_: as cmd/juju is "yours" :-) [11:51] rogpeppe, kinda, I guess :p [11:51] fwereade_: you touched it last anyway. i think that gives you some veto rights :-) [11:52] fwereade_: i'm tearing it apart anyway :-) [11:52] rogpeppe, haha, that does sound a little alarming :p [11:52] rogpeppe, what's it conspicuously lacking for your purposes? [11:52] fwereade_: don't worry too much. it's all with due respect, i hope [11:53] fwereade_: it's mostly just refactoring shared stuff between commands, now that there's more than one [11:53] fwereade_: the basic structure remains [11:54] rogpeppe, cool, I fully expect bootstrap to take a justified kicking; I would worry a little if you were planning to gut SuperCommand [11:54] fwereade_: oh no! i wouldn't dream of it. [11:54] fwereade_: currently i'm strictly within cmd/juju [11:55] rogpeppe, ah, cool, that's great then ;p [11:55] rogpeppe, and ofc if cmd itself needs work that's fine as well, the only reason I'd be nervous of that is because a new client is on the way [11:56] fwereade_: a new client? [11:56] rogpeppe, cmd/jujuc/server will also use it, it fits too nicely to go duplicating stuff like command selection IMO [11:57] fwereade_: i thought it already did. [11:57] rogpeppe, not in trunk [11:57] rogpeppe, yet [11:57] fwereade_: ah, i didn't know if it'd been merged yet [11:58] rogpeppe, that specific branch is currently not even proposed, I want to lose a bit of the backlog first before I make it work with the final versions of the stuff currently in review [11:58] fwereade_: ah, i lose track [11:59] rogpeppe, tell me about it ;) [12:37] lunchtime [12:55] morning folks [12:55] * hazmat tracks down a memory leak [12:58] hazmat: morning [13:17] lunch [13:27] back on the veranda [13:30] Good morning everybody [13:33] niemeyer: yo! [13:43] niemeyer: morning [13:49] back [13:58] g'morning niemeyer [13:59] niemeyer, if I was stupid and set the wrong -for in lbox propose, how do I do a new MP for that branch? [14:00] Hey all [14:00] fwereade_: Just delete the previous one [14:00] niemeyer, d'oh :) [14:00] fwereade_: ;) [14:06] hazmat, when you have a moment: [14:06] hazmat, https://codereview.appspot.com/5882056/ [14:06] hazmat, https://codereview.appspot.com/5876070/ [14:07] hazmat, https://codereview.appspot.com/5874064/ [14:07] hazmat, in that order [14:16] fwereade_: Please note that there's a minor detail rogpeppe pointed out in terms of pre-req that still must be fixed [14:17] niemeyer, oh, bother, missed that [14:17] niemeyer, what's the problem? [14:17] fwereade_: If you merge the pre-req, and then merge trunk onto the follow up branch, the next propose will still be diffing against the pre-req [14:17] fwereade_: It's not such a big deal [14:17] fwereade_: pre-req is still useful even with that [14:18] it confused me quite effectively though! [14:18] fwereade_: You'll just a wrong diff in the specific case where you merge trunk on the follow up [14:18] (not that it takes much :-]) [14:18] (and not in the pre-req) [14:18] niemeyer, ah ok, so it really just introduces more noise as it remains unreviewed? [14:18] niemeyer, that's *almost* a feature :p [14:18] fwereade_: yeah, if you merge trunk on the pre-req too, it fixes the problem [14:18] niemeyer, cool [14:18] fwereade_: Yeah ;) [14:19] fwereade_: I have to fix lbox so that it checks the merge state of hte pre-req before deciding what to diff against [14:19] niemeyer, sounds good [14:20] hazmat: What do we do with the wtf? [14:20] * rogpeppe feels all virtuous every time he writes "package testing_test" [14:32] niemeyer, i fixed that bug in trunk [14:37] hazmat: Awesome, so I guess we'll have to jump over a few revisions [14:37] hazmat: Will do that in a bit [14:37] rogpeppe: :-) [14:38] rogpeppe: pls take a look athttp://paste.ubuntu.com/896502/. it realizes a Watcher as util type where own behaviors with three methods (and those individually needed) can be plugged in [14:39] niemeyer, yeah.. it needs to skip 486-494 [14:39] 494 is good [14:39] TheMue: what about watchers that watch children of a node? [14:41] TheMue: or watchers that watch the contents of a node, come to that [14:41] rogpeppe: would have to check it. i've only choosen ExistsW because it doesn'd do much i/o. [14:41] TheMue: how many different watchers will there be? [14:41] rogpeppe: it works with content, see my last proposal [14:41] TheMue: link? [14:42] rogpeppe: https://codereview.appspot.com/5885059/ [14:42] rogpeppe: but here still without behavior [14:43] rogpeppe: it's an idea to discuss. when the watch fires for every event regarding a node (content, creation, deletion, children) then it would work fine with one Watcher as type [14:44] TheMue: i don't think that's a good idea, as it means more network traffic than necessary. [14:45] rogpeppe: why? [14:46] TheMue: i *think* that registering a watcher for a node sends a message to zookeeper (if that watcher type isn't already registered for that node) [14:46] rogpeppe: afaik watches allways fire all kinds of events [14:46] TheMue: no, it would be nice if they did, but they don't [14:47] TheMue: GetW doesn't fire when children change, for example [14:47] rogpeppe: so my "exists watch" fires content changes and deletions by accident (monitored that) [14:48] TheMue: the set of events depends on the call. existsW does give changed events, yes. [14:48] but not children events [14:48] i think i documented it once [14:48] rogpeppe: do we have an i/o problem regarding watches or is this a kind of premature optimization? [14:49] TheMue: it makes the implementation more complex too - you have to fire off a new goroutine each time you do a watch. [14:49] rogpeppe: ok, so i would change the Watcher to be configurable. e.g. Init() of the behavior could return where it is interested in. [14:50] rogpeppe: like in http://paste.ubuntu.com/895188/, yes [14:50] looks like my updated zk docs didn't make it in [14:51] rogpeppe: one Watcher, one goroutine, that's no problem, that's what go is made for [14:52] TheMue: not quite - you need a new goroutine each time through the loop, or at least that's how i did it last time. [14:52] rogpeppe: so, if needed a fine control of what exactly should be watches should be only a small task [14:52] rogpeppe: not in my approach [14:53] rogpeppe: tested it in my proposal, multiple changes received fine [14:53] TheMue: with children and content changes? [14:53] rogpeppe: with content changes [14:54] rogpeppe: could easily extend it to alternatively watch children [14:54] TheMue: that's easy. but you're proposing watching content at the same time as children, no? [14:55] rogpeppe: currently not. my proposal right now is only interested in content. but as i said, i don't think it's difficult to make this configurable. [14:56] rogpeppe: so when creating the watcher instance you can say what you're interested in [14:56] TheMue: if it's configurable, the types become awkward because you can receive new children ([]string) or new content ([]byte) [14:57] TheMue: how about two kinds of watcher - one for children and one for content, both with appropriate types. [14:57] TheMue: the children watcher could generate events on a channel corresponding to which children are deleted or created. [14:57] rogpeppe: the behaviors Update() is called if there is a change. it then retrieves what it is interested in. and additional methods allow to grab this data after the change notification via the channel [14:57] TheMue: (i.e. deltas) [14:58] TheMue: that really is inefficient, because it incurs an extra round trip for each change. [14:59] rogpeppe: do we have i/o probems? [14:59] TheMue: no need to increase network traffic more than we need to. [14:59] TheMue: in some places it may be billed [14:59] rogpeppe: so it's premature optimization? [15:00] TheMue: no, it's appropriate design :-) [15:00] TheMue: it's easy to do this in a more efficient way [15:00] rogpeppe: last time you had trouble with code duplication, this time it shall be duplicated for each watch? [15:01] TheMue: no, each kind of watch - children or contents. are there any examples where a watcher needs to watch both of these at once? [15:01] rogpeppe: so far i didn't found any [15:02] TheMue: here's a sketch: http://paste.ubuntu.com/896534/ [15:03] TheMue: that's the API [15:03] TheMue: well, a possible API :-) [15:04] rogpeppe: what is ChildChange.New? [15:04] niemeyer: do you know if charmd will place nice with start-stop-daemon's --background, or if there's another way of daemonising the process? [15:04] TheMue: it says whether the names have been added or removed [15:04] rogpeppe: and ContentWatcher in my case has to return a ConfigNode [15:04] TheMue: it could be a type with Add and Del constants [15:04] TheMue: why's that? [15:05] TheMue: these are the types that the config node watcher (and all other watchers) would build on [15:05] rogpeppe: because it watches data in the config node [15:06] one way to find out, I guess [15:07] TheMue: you could implement the config node watcher something like this: http://paste.ubuntu.com/896539/ [15:08] TheMue: obviously there would have to be error checking and a tomb there too. [15:08] rogpeppe: that's what i wonna provide with the Watcher type [15:08] TheMue: or perhaps it could share a tomb with the ContentsWatcher, i'm not sure [15:09] rogpeppe: i will tink about a mix of your and my ideas [15:09] TheMue: think about a nice strongly typed, pipeline [15:09] oops [15:10] TheMue: think about a nice strongly typed pipeline of events being processed [15:10] TheMue: channels work really well that way [15:10] rogpeppe: yep [15:11] mthaddon: It doesn't do anything about daemonization.. [15:11] mthaddon: So --background should be fine [15:11] k, will give it a try - thx [15:11] mthaddon: As I said, though, if you need something else I can look into it [15:12] niemeyer: k, will let you know - have got it saying "2012/03/23 15:02:06 JUJU Store opened. Connecting to: 127.0.0.1:27017" in the logs so far [15:12] mthaddon: What's the status quo, btw? I'll be working on the charms today as I managed to find out what was happening yesterday [15:12] mthaddon: Cool, that's all that should be necessary [15:12] mthaddon: It means it's happily serving requests [15:13] mthaddon: Hook charmload in the other end via crond, and you should have a fully working setup [15:13] niemeyer: I think I'm getting pretty close - just need to open up some firewall rules, get DNS entries in place, and land the last few bits of the config that I've been testing with then we should be done [15:13] mthaddon: Ok.. are we charming up.. are we loading that and moving on without charms.. ? [15:14] mthaddon: Sorry, I'm complete uncertain of the situation given Elmo's email, sabdfl requests, etc [15:14] niemeyer: we're working on both in parallel so it gives us options (by which I mean I'm continuing to work on the DC stuff while you get started on the charm stuff) [15:15] mthaddon: Sounds great then.. thanks for that. I'll just put the store online and we can delegate for someone else to decide which one goes live. [15:15] mthaddon: I'm happy either way, as long as we have something serving it. [15:15] gents, popping out for a walk and a think, bbiab [15:15] fwereade_: Enjoy [15:15] I'm heading to lunch too [15:15] biab [15:21] niemeyer, fwereade_: enjoy [15:57] fwereade_, cheers [15:57] SpamapS, it looks like we'll need a patch for python-zookeeper [15:57] SpamapS, there appear to memory leaks in all the async apis :-( [15:57] testing the patch now [16:01] mthaddon: I don't know why --background is failing for you [16:01] mthaddon: I've run it locally, and it works [16:01] niemeyer: really, cos I've run it locally and it fails for me too - can you show me what you're doing locally? [16:01] (i.e. outside of the production env) [16:01] mthaddon: [16:01] [niemeyer@gopher ..go/store/charmd]% start-stop-daemon --background --start --exec $PWD/charmd -- 1.2.3.4:5 6.7.8.9:1 [16:01] [niemeyer@gopher ..go/store/charmd]% ps auxw | grep charmd [16:01] niemeyer 28212 0.5 0.0 62292 3452 ? Sl 12:46 0:00 /home/niemeyer/src/launchpad.net/juju/go/store/charmd/charmd 1.2.3.4:5 6.7.8.9:1 [16:01] niemeyer 28216 0.0 0.0 9368 912 pts/7 S+ 12:46 0:00 grep charmd [16:02] ok, so you're not really testing the same options as we have in the initscript - in any case, I'll try and reproduce that locally [16:03]