[00:10] wallyworld__: ping? [00:43] Oh fab, CI thinks trunk is bzr because the first 8 chars of the hash are numbers [00:48] lol [00:48] :-( [00:50] wallyworld: do you have time for a quick chat about gridfs? [01:01] hahaha [01:03] someone have time to hangout, I need an ear to bend about the approach of this refactoring fwereade has suggested to me. [02:05] thumper-afk: meeting? when you get back? [02:06] axw: you had any breakthroughs on the session closed errors etc? [02:07] wallyworld__: nope [02:08] it will probably be something simple once the cause is found [02:09] axw: so you checking that precise cloud init supports the new apt feature? [02:09] wallyworld__: I have checked it works with cloud-init, I'm just checking the sshinit bit works on precise too [02:09] no reason for it not to, but I should be thorough [02:10] great, thank you [02:10] just checking you aren't stuck for stuff to do [02:10] the address change stuff still wip i assume [02:11] wallyworld__: well, not actually working on that atm. I want to get some more agreement first. I did finish the unit config-change bit [02:11] np, do you need me to poke william? [02:12] wallyworld__: need some more discussion with hazmat I think [02:13] ok. the next largish chunk of work is to replace http storage. but i'd like to see if we can get the tests sorted first [02:13] okey dokey [02:14] worth spending some time on the tests as it will have a big affect on team velocity plus we will learn lessons that can be shared and used [02:14] wallyworld__: I think you said perrito666 was working on separating StateInfo from storage? [02:15] I think that will be a prereq to get it to work [02:15] sure [02:15] yeah, there's supposed to be a new api or some such - that's what william told me [02:15] so we can do the http stuff and also replace cloud storage [02:15] for tools, charms [02:16] but i also have to move the storage stuff to a separate repo [02:16] but i want martin to get the lander sorted out first [02:16] i'll check the StateInfo progress also [02:18] wallyworld__: unit tests pass; doing empirical testing now, and should have a pull request contingent on that [02:18] wallyworld__: axwI am not working on such feature [02:18] katco: great :-D [02:18] wallyworld__: axw not that I can remember [02:19] perrito666: ah ok. maybe someone else [02:19] perrito666: william indicated there would be an api to allow state server addresses to be found without having to reply on a file stored in environment storage [02:19] katco: hello! you're working rather late aren't you? [02:19] maybe it wasn't you? i thought i was but i could be wrong [02:20] axw: i am :p but i'm interested. i want to get this change in so i have a clean plate tomorrow. i won't make a habit of it ;) [02:21] i also got distracted by my stupid addiction to food. [02:21] axw: do you have an example of an error path releasing resources? I know you and davecheney have been working on it recently. What's the correct and incorrect way now? [02:21] wallyworld__: mm, I am about to sleep now but if you could email me that It would be greatly appreciated we might be only having misscomunication due to the fact that should be sleeping [02:21] ok :-) [02:21] good night [02:21] wallyworld__: tx [02:21] today in "Dave waits for the build bot": listening to podcasts and filing bugs :( [02:22] waigani: I just meant make sure files and such are closed when a function exits [02:22] ah right [02:22] "defer f.Close()" usually [02:22] sure [02:22] github.com/juju/juju/juju/testing/conn.go [02:22] my god, who thought that was a good idea [02:22] * katco pulls up a seat next to davecheney. ah, bootstrapping juju machine agent. a fascinating show. [02:23] katco: well, you'll have 2 clean plates - one the food was on the the other your todo list :-) [02:23] * davecheney ages visibly waiting for juju bootstrap [02:23] davecheney: you should disable apt-get upgrade... oh wait.. :) [02:24] * davecheney grins, morbidly [02:24] it's like a magic spell - you have write say 'juju' at least three times for it to work ;) [02:24] wallyworld__: bootstrapping precise works with eatmydata [02:24] hmm, https://bugs.launchpad.net/juju-core/+bug/1337038 [02:24] <_mup_> Bug #1337038: cmd/juju: map ordering test failure [02:24] axw: \o/ [02:24] i wonder how this happened [02:25] wallyworld__: or rather, it works despite eatmydata not being installed [02:25] by default [02:25] http://img3.wikia.nocookie.net/__cb20140108021302/villains/images/2/27/Beetlejuice.jpg [02:25] wallyworld__: i suppose i should assign this bug to myself on launchpad? [02:26] katco: yes, sorry i should have mentioned that [02:26] I'm tempted to write a program to transform the tests so that it randomise everything that isn't guaranteed to be deterministic [02:26] wallyworld__: no worries... i just wasn't sure what the workflow was [02:26] katco: and before we moved to github, it would be marked as fix commited automatically after the branch merged but now we need to do it manually [02:27] axw: or upgrade Go to use the new map implementation :-) [02:27] wallyworld__: ew bummer. maybe we can do a jenkins or github trigger to update it. i assume launchpad has an api? [02:27] katco: yeah, it's on the "do this to make things nicer once the core stuff works" list [02:27] wallyworld__: should i flag this fix for a milestone? or is that someone elses purview? [02:28] wallyworld__: gotcha. i think i have a slide in my presentation that says something along the lines of, "your iteration is the only thing that will happen again and again. making it better has multiplicative returns" [02:28] katco: normally the bug would be assigned a milestone, usually "next-stable-release", and then moved to the correct actual milestone one the release number milestone gtes created [02:29] wallyworld__: ok, i'll do that [02:30] katco: someone would normally do that, but i got distracted as I just picked out some simple bugs for you that were not on the radar so to speak [02:30] wallyworld__: oh ok. np. thanks for the bugs :) [02:30] anytime, i have *lots* more :-) [02:30] gee, sorry. i only fix 1 bug per team. (cough) [02:31] ;) [02:34] wallyworld__: I think we should remove the second "go test" from the lander now [02:34] it's just holding up the queue now [02:34] axw: i'm inclined to agree, but i think we can (and do) still get spurious failures on full parallelisation? [02:35] wallyworld__: I've seen it once since I made my change [02:35] wallyworld__: I think that's low enough rate to get people to resubmit [02:36] true, and if there's a real failure, it will report quicker [02:36] right [02:37] makes it harder to now if we've fixed the race too :-) [02:37] know [02:37] heh. I'll see if I can reproduce the bugs in a VM with slower I/O [02:38] axw: martin should be calling the bog standard script from the release tools repo - but i think he still needs to switch over. i'll get him to turn off retry when he does that today/tonight [02:38] cool [02:40] katco: the logging stuff - loggo comes with a default stderr writer registered. the various agents are configured to run via upstart, and have their stdout/err directed to a log file - see juju/upstart/service.go [02:40] so that's how the log calls get stuff to a log file [02:41] aha! [02:41] wallyworld__: thank you! [02:41] katco: so, next step is to figure out how to tell upstart how to create the file with different permissions [02:41] wallyworld__, If I read this run correctly, only 2 tests fail in lxc with -p 2 [02:41] that i do not know off hand [02:42] sinzui: which run? [02:43] wallyworld__, looks like 1.20 at f325c87bd1dc92ac58bdc347568a6d901b607172 [02:43] sinzui: with andrew's change to use tmpfs, tests are now very reliable. so more may fail in lxc due to slower i/o as it seems slow i/o has a repeatable negative impact on the tests [02:45] sinzui: you mean that the above revision looks like it is good for release as 1.20? [02:45] davecheney, menn0: thanks for your input :) [02:46] wallyworld__, that log claims to be the 1.20 we were testing all day [02:46] waigani: no problems. that list might well help me. [02:46] nice! [02:46] wallyworld__, I see a new round of tests started with master. I can run the lxc version of the test with this run [02:46] sinzui: can you point me at the log toy refer to? [02:47] ok [02:47] wallyworld__: ok, i think i've submitted a pull request. what would i paste here to get a review? [02:47] so I have a package in environs that contains a bunch of interfaces and struct all related to exposing parts of the environ to state. Right now I have that package named "hackage" .. obviously that won't work, looking for suggestions. [02:47] katco: you can reasonably expect the on call reviewer to pick it up. but you can also paste the pull request url here and beg offer $$$$ for a review. i only accept $100 bills [02:48] rofl [02:48] well here it is: https://github.com/juju/juju/pull/232 [02:48] * menn0 thinks wallyworld__ hates him ... :) [02:48] i expect that i have done something wrong [02:48] so let me know :p [02:48] wallyworld__, This the log I was reading: http://juju-ci.vapour.ws:8080/job/walk-unit-tests-trusty-amd64/1115/consoleText [02:48] katco: you for getting something..... ? [02:48] oh right [02:48] menn0: why? [02:48] * katco hands wallyworld__ a $100 bill and a wet trout [02:48] I've been ping and PMing you all day [02:49] wallyworld__: ^^ [02:49] wallyworld__: but no response [02:49] * menn0 puts on big sad puppy dog eyes [02:49] menn0: sorry, i often miss private pings because i don't hear the notification and your nic is off my screen, and also my connecton for irc has been flakey :-( [02:49] sorry :-( [02:49] oh wow davecheney is all over that. thanks :) [02:50] menn0: also you didn't give me money like katco just did [02:50] wallyworld__: so that's what it takes these days... [02:50] psst, menn0, it was monopoly money. he doesn't notice! [02:51] katco: thanks for the tip. I wonder if he takes dogecoin? [02:51] LOL [02:51] menn0: also, he told me he hates you [02:51] :P [02:52] wwitzel3: I KNEW it! [02:52] menn0: hey wanna help me name something? :) [02:52] wwitzel3: ummm sure [02:52] * menn0 wonders if this is a trap [02:52] wwitzel3: i hate you too :-) [02:53] menn0: see about comment .. I have a package currently called hackage in environs that contains interfaces and a struct that is used to represent information needed about an environ to state. [02:53] s/about/above [02:53] sinzui: that's not a bad test run for being inside lxc - only a few things to fix :-) [02:53] ok so now i've commented with $$merge$$, and jenkins will pick that up and perform a build and then merge if it's clean? [02:53] katco: yep [02:53] wallyworld__: haha, well at least I know you feel something! :P [02:53] nice! which build am i interested in? [02:54] wwitzel3: there's a line there but this is a family channel [02:54] wallyworld__: hah [02:54] katco: http://juju-ci.vapour.ws:8080/job/github-merge-juju/ [02:54] * menn0 thinks [02:55] katco: but the queue is full of other jobs right now [02:55] wallyworld__: ty. how long does it usually take the worker to pick that up? assuming workers are free [02:55] katco: we are moving the landing job to it's own slave soon [02:55] cool [02:55] katco: you will see an email within a minute [02:55] katco: you need to make your juju membership public on github [02:55] if the queue is not blocked [02:55] otherwise the bot ignores your comment [02:55] oh yeah, that too [02:55] katco: https://github.com/orgs/juju/members [02:56] wallyworld__: whatever happened to cake being the official offering? [02:56] rick_h__: cake can't buy love [02:56] $$$$ can [02:56] wallyworld__: thought back in the LP days cake was the offering for things, sad to see that sell out and go all $$ [02:56] wwitzel3: what kind of stuff about environs is being exposed to state? [02:57] rick_h__: indeed. but these here are crazy time. new world order. survival of the fittest [02:57] hah [02:57] axw: ok thanks, i've done that [02:57] menn0: ConfigValidator, PrecheckerInstance, EnvironCapability, and InstananceDistributor .. state combines them all under a Policy interface to represent a given environ. [02:57] katco: your job is now pending [02:59] wwitzel3: environ_policy or environ_state_policy? [02:59] wwitzel3: environ_state? [02:59] wwitzel3: not that great I realise... [03:00] menn0: yeah, was thinking something along those lines, environs already has a statepolicy which does some of the marshalling of the data, so I was thinking of creating an environ_state and moving that under along with the current "hackage" stuff. [03:00] menn0: but then, I hate to use state again anywhere, lol [03:00] wwitzel3: are there new bits in hackage, or are you just moving existing things? [03:01] wwitzel3: yeah - it sounds reasonable (based on my limited understanding on what you're doing) [03:01] axw: just moving things so that environs no long depends on state [03:01] ok [03:01] environs/policy? [03:01] axw: I was running in to some import cycle issues when implementing the EnvironmentAPI and fwereade pointed out this would be good chance to sever that dep which really isn't needed. [03:01] wallyworld__: so say this fails for some reason, what is the workflow? [03:02] katco: you fix the failure, push, and type $$merge$$ again [03:02] axw: hrmm, yeah that actually makes sense since it is the environ policy and the whole point is that is doesn't care about state. [03:02] katco: if it's a suprious failure in the bot, just type $$merge$$ [03:02] axw: I guess I thinking about it too much [03:02] wwitzel3: yup. it's just a way for things to hook into environment behaviour [03:02] wallyworld__: dont' you all have to remove the 'merge request accepted' comment in github? [03:03] wallyworld__: so i should be very interested in the results of this job, as it's on me to fix the merge? is the merge gated? will it still merge if the build fails? [03:03] rick_h__: we don't / haven't been [03:03] wallyworld__: and the extra $$merge$$ should do nothing. :/ [03:03] menn0, axw: thanks, I will go with environs/policy and people can suggest alternatives during review if they so desire :) [03:03] katco: merge is gated, yes [03:03] great [03:03] ummm, ok. That's interesting [03:03] katco: won't merge untl the tests pass [03:03] rick_h__: why? [03:03] wwitzel3: sounds ok to me [03:04] i was interested that the tests take so long. is it b/c it's tied into mongo? [03:04] wallyworld__: because that's the way I wrote it to work. Extra $$merge$$ aren't supposed to do anything [03:04] wow, you guys are crazy, 35 running pull requests [03:04] wwitzel3: SGTM. I *think* you just want to move the interfaces in there, and leave the statepolicy.go (impl) stuff where it is [03:04] wwitzel3: does that sound right? [03:04] rick_h__: seems to work for us :-) [03:04] wallyworld__: yea interesting. Trying to figure out why. lol [03:05] wwitzel3: just so the state and environs packages have a common interface to reference [03:05] without depending on one another [03:06] wallyworld__: heh so it works by accident fyi. The idea was that the bot checks if there's 'merge request accepted' comment and if so, it doesn't rerun the merge job. https://github.com/juju/juju/pull/224 [03:06] axw: yeah, I realized that looking at it, you're right. [03:06] wallyworld__: so the way to rerun is supposed to be to remove that 'merge request accepted' comment. [03:06] rick_h__: lol ok [03:06] wallyworld__: glad it's working for you, I'll have to make sure not to fix that 'bug' :) [03:07] rick_h__: it's now a feature :-) [03:07] hah, extra added feature [03:08] curious why my job doesn't have any text on it [03:09] https://github.com/juju/juju/pull/233 [03:16] axw: thanks for the review [03:16] the rabbit hole just keeps going [03:16] davecheney: nps [03:16] yay i landed my first change :) [03:17] thank you for the help everyone! [03:17] katco: and you didn't break the build [03:17] nor did you delete the whole CI infrastructure [03:17] (long story) [03:17] there's still time! i can make another change! [03:17] so, thumbs up! [03:17] give me a chance! [03:18] davecheney: lol [03:19] We can put CI back in a couple hours, all that ci machines can be deploy with juju [03:20] This is the 3rd ci because canonistack lost the first 2 [03:21] sinzui: yea, we have some sublte steps. The lander, system deps, etc are manual still [03:21] sinzui: though we're going to work on automating it more. [03:21] sinzui: but we had a new team member wipe out CI on his frist day on accident [03:22] sinzui: so it's the nice story going around [03:22] rick_h__, :) === thumper-afk is now known as thumper [03:23] wallyworld: sorry, have been having a sick day and away [03:23] thought I might have come back after lunch [03:23] but still not feeling so shit hot [03:24] so I'm going to sign off [03:24] and see how I am tomorrow [03:24] wallyworld: perhaps we can chat tomorrow? [03:24] rick_h__, there are 14 machines in ci 3's env, but the machine count is 53. I have lost 40 machines in the last 3 months [03:24] sinzui: ouch [03:24] sinzui: we're up to 4 in one env now, but only because of the ec2/co-locating limitation now [03:25] thumper: sure np. i'm off tomorrow. the main thing was the resources stuff. but you can reply to the email and we have a tentative meeting next week with rick_h__ and friends [03:25] bwuhahaha, how can I ruin more of thumper's days? [03:26] katco: sorry, was on another call [03:26] katco: you can click the console output link to see the job text [03:26] wallyworld: np. it landed [03:26] davecheney, Maybe you want to look into this issue soon, or at least advise someone about how to fix it https://bugs.launchpad.net/juju-core/+bug/1337063 [03:26] yeah i had stood up jenkins at my last shop :) [03:26] katco: \o/ yay, you are now *officially* a juju-core team member :-P [03:26] woohoo! [03:27] lol congrats katco [03:27] now to grok more so i can contribute more difficult changes [03:27] rick_h__: or should that be commisserations :-) [03:27] haha [03:27] wallyworld: not sure what kind of crappy medal you all hand out to the new folks :P [03:27] nah we will do great things together. [03:27] ah, the newbies are always so optimistic :-) [03:27] katco: what TZ are you? [03:28] alexisb told me i get $100 for each commit? is that right? [03:28] rick_h__: GMT-6 [03:28] sinzui: we have two options [03:28] 1. roll back that change [03:28] katco: yep, here you go .... $100 [03:28] katco: oh get out of here [03:28] woo! [03:28] 2. fork the ssh/terminal package [03:28] katco: don't be like wallyworld and I working at night. [03:28] yuck for 2 [03:28] rick_h__: it's not my night yet :-) [03:28] rick_h__: haha, was just going to say, I know what TZ you're in :P [03:28] lol, i just wanted to get that 1st change in while wallyworld was on [03:28] wallyworld: yea, but I'll see you in my morning your night and we know it :P [03:29] lol [03:29] wwitzel3: some of us don't know any better any more, but katco has time yet to get on the right path [03:29] last night i had a night off :-) drinking with friends :-) [03:29] wallyworld: woot! I'm going into the woods for the holiday. No cell coverage [03:29] wallyworld: only a 'clubhouse' with 500kbs wifi connection to the world [03:29] rick_h__: enjoy that. fireworks in the forrest not so good tough [03:30] wallyworld: there's a lake they set them off over [03:30] rick_h__: 500kbps. party likes it's 2001 :-) [03:30] hoping to get some nice pics with my new camera gear [03:30] rick_h__: nice, I'm going to shoot toxic powdered metal in to the sky after lighting it on fire. [03:30] * wallyworld loves photography [03:30] wwitzel3: woot! [03:30] rick_h__: what gear you got? [03:30] wallyworld: yea, my new hobby, having fun [03:30] wallyworld: pany gx7 micro 4/3 with a suite of lenses, mefoto tripid, etc [03:30] he uses iPhone + Instagram [03:31] lol [03:31] https://www.flickr.com/photos/7508761@N03/ [03:31] lol [03:31] no apple allowed! [03:31] rick_h__: nice. i got a nikkon D7000 with nice wide angle, a 70-300 tele, and 35mm prime [03:32] rick_h__: those portraits are nice [03:32] I have Sony aSomething or other with 3 lenes .. and I use my phone for all my pictures :/ [03:32] wwitzel3: rotrl [03:32] wallyworld: yea, learning and practicing [03:33] wwitzel3: heh, that's why I went with micro 4/3. It's smaller and closer to something I can carry around [03:33] rick_h__: just no naked selfies, PLEASE [03:33] though with my 100-300 lens (200-600 effective) it's a bit big [03:33] rick_h__: yeah, I like that form factor, will probably sell my full size and try it out. [03:33] https://www.flickr.com/photos/7508761@N03/14497325923/ the boy with a 45mm oly prime I got. I just focused on the wrong eye for this pic :/ [03:34] rick_h__, wallyworld: the only thing I really use it for is doing portraits, I have a fixed focal length lense. [03:34] "How do you zoom out?" .. "With your feet" [03:34] https://www.flickr.com/photos/7508761@N03/14423103076/ [03:34] wwitzel3: yep, i here you. i use my 35mm prime as my main lens [03:34] hear [03:35] heh, ok I need to close up shop and go to bed at some point, have fun all. [03:35] rick_h__: see ya [03:35] rick_h__: ttyl [03:35] wallyworld: thanks for the notes/docs, and so forth. Will look forward to causing each other work soon :) [03:35] rick_h__: yeah, right back at ya [03:35] rick_h__: i really want to porgess this stuff :-) [03:35] progress [03:48] axw: if we want to see lots of spurious failures, look at the output of the job to run tests inside lxc that sinzui set up eg http://juju-ci.vapour.ws:8080/job/walk-unit-tests-trusty-amd64/1116/console [03:48] and 1115 before that etc [03:48] wallyworld, yeah [03:49] I was just pondering a --safe-retry switch to just run tests with -p2, and do it twice [03:49] if we make makes that job happy, our test suite will indeed rock [03:49] wallyworld: ok [03:49] looking... [03:49] yuck :( [03:50] sinzui: not a bad idea. we are considering turning off retry option for landing tests now that they seem a lot more reliable running with tmpfs [03:50] axw: yeah, shows how far we've got to go [03:50] because we do have ambitions of running the tests isolated in lxc [03:51] wallyworld, I don't know what your considering. I try tests 4 times with all procs. I was thinking of trying 2 times with only 2 procs. It might be faster on average === vladk|offline is now known as vladk [03:52] sinzui: for the landing tests to gate commits to trunk, we have been running once and then again with -p 2 if the first run failed. now the tests are more reliable, we are looking to turn off the retry option and just fail the run [03:53] wallyworld, My samples of those tests shows that -p 2 was making them pass most of the time, just run with -p 2 [03:53] wallyworld, axw: https://github.com/juju/juju/pull/234 .. I'm off for the night, but any feedback would be great. [03:53] well, I will set that up in some parallel testing to get so better data [03:54] wallyworld: the Environment API implmentation is "done", but I'll want to get #234 in first, since I've re-worked it branched off that. [03:54] sinzui: that's a fair bit slower, and since axw switched to tmpfs, we have had maybe 1 spurious falure out of several runs [03:54] wwitzel3: no worries, will take a look a bit later. [03:54] That would be nice wallyworld [03:54] wwitzel3: looking, thank you [03:54] wallyworld: so once I get #234 merged, I'll get the EnvironCapability API stuff up for review. [03:54] great :-) [03:55] sinzui: the tmpfs change shows how fragile our tests are and that we have work to do [03:55] but for now, it has helped the landing tests be more reliable [04:07] wallyworld: axw nice one [04:07] the bot is landing changes in 10 minutes [04:07] well, it runs the tests in 10 minutes [04:07] setup is still a few minutes [04:07] but it is significantly better than a few days ago [04:07] davecheney: set up will disappear "soon" also [04:08] davecheney: and using tmpfs marks our poor tests/race conditions, but gives us scope to fix without holding people up [04:08] masks [04:11] wallyworld: i always mount /tmp with a ramfr [04:11] wallyworld: i always mount /tmp with a ramfs [04:11] i don't think it's an invalid setup [04:12] davecheney: slow i/o should not cause tests to fail in a racey way [04:12] the setup is valid but the tests ares till broken [04:12] s/broken/suboptimal [04:12] davecheney: and there's lots of failures running the tests inside an lxc container [04:13] due to the same/similar root causes [04:16] axw: nice doc [04:17] wallyworld: thanks [04:17] is that addition of supported providers ok? [04:17] for automatic spread [04:21] axw: yep, +1. thanks === vladk is now known as vladk|offline [05:26] PTAL https://github.com/juju/juju/pull/216 === urulama-away is now known as urulama === vladk|offline is now known as vladk [06:23] ha, i've just seen this: https://godoc.org/github.com/dropbox/godropbox/errors#Wrap === vladk is now known as vladk|offline === vladk|offline is now known as vladk === vladk is now known as vladk|offline === vladk|offline is now known as vladk === vladk is now known as vladk|offline === vladk|offline is now known as vladk [07:13] jam1: so we currently use a mechanism at bootstrap time to save the inst id of the bootstrap machine of cloud storage ie bootstrap.SaveState bootstrap.LoadState etc. Do we still need that with all the api and login etc changes since that was all done? [07:15] s/of cloud storage/in cloud storage [07:18] axw: agree existing tests are shitty. sadly i think if we truly want to fix all the races we'll need to touch a lot more of them [07:18] s/touch/rethink [07:18] yeah :/ [07:18] I cna't see a way to do it without major changes [07:19] understood :-( [07:19] might be a chance to blaze th trail [07:19] morning [07:20] Guten Morgen [07:20] wallyworld__: we *could* get rid of the provider-state file from storage (with some minor updates to bootstrap?), but if the addresses change and the client does not have any valid addresses it has no way to get back in [07:20] wallyworld__: hehe, yes o/ [07:21] axw: agreed. i had heard mention though we were working around that somehow [07:21] that's what i'm not sure about the status of [07:21] ok [07:21] i'm not sure how though as if we don't know the address, how do we discover the new one [07:22] will be impossible t get rid of cloud storage without figuring this out [07:25] wallyworld__: for the CLI, there's options, but I don't know about agents [07:25] wallyworld__: for the CLI we could tag instances and query via the provider interface [07:26] axw: yeah, that did occur to me also. not sure how portable it would be [07:26] wallyworld__: for agents, we could do something horrible like push the addresses to each of the agents via SSH [07:26] (from the state server) [07:27] juju run new-addresses :-) [07:27] yeah that'd work I guess [07:27] i was not really serious :-) [07:28] but it could be something at the correct level of abstraction [07:29] axw: EUREKA! [07:29] i've caught mgo doing something stupic [07:29] davecheney: ?! [07:29] stupid [07:29] ooh [07:29] http://paste.ubuntu.com/7740699/ [07:30] buh [07:30] the mgo pinger, v2/mgo/server.go [07:30] has a loop [07:30]