[00:30] hazmat: https://launchpadlibrarian.net/89092620/buildlog_ubuntu-precise-i386.juju_0.5%2Bbzr440-1juju2~precise1_FAILEDTOBUILD.txt.gz [00:31] * SpamapS sometimes wonders if the buildds are just too hostile to run juju's test suite inside of [00:33] * SpamapS retries it [00:52] SpamapS: urgh, spurious failures suck [00:53] SpamapS: that last failure looks odd - "dictionary changed size during iteration" while you're already taking a list() of the dictionary items to iterate over [00:55] jelmer: I'd pinpoint it to a precise library problem if I could get the automatic builds to work on oneiric/natty/maverick/lucid ... but the java build-dep causes us to hit the 1G limit about 90% of the time. [00:55] ah, bug 693524 ? [00:55] <_mup_> Bug #693524: Daily builds of Java packages fail: "Could not reserve enough space for object heap" < https://launchpad.net/bugs/693524 > [01:03] jelmer: indeed [01:05] jelmer: most frustrating about that is that because it is seemingly random.. the PPA has 4 different versions of juju in it. [06:03] <_mup_> juju/ssh-known_hosts r467 committed by jim.baker@canonical.com [06:03] <_mup_> Test concurrent update of known_hosts file [06:13] <_mup_> juju/ssh-known_hosts r468 committed by jim.baker@canonical.com [06:13] <_mup_> Cleanup of concurrent process test [08:14] mornin' all [09:48] hi all [10:08] jcastro: ping [10:10] koolhead17: would be surprised if jcastro wa already awake, he is east coast based [10:10] nijaba: sorry, i always get confused with the timezone slaughter :( [11:08] koolhead17: My little friend here is http://www.worldtimebuddy.com/. Here I've stored the locations of the whole team. ;) [11:10] TheMue: cool [12:43] * hazmat yawns [14:32] hazmat: whenever you got your coffee with you, what was the file again where the juju client writes its zookeeper node address? [14:33] lynxman, its the key 'provider-state' in the provider storage [14:34] hazmat: hmm okay, any recommendation in how to alter it through the command line? :) [15:04] lynxman, um.. there isn't one, what's the problem your trying to solve? [15:05] hazmat: just continuing on what we talked, trying to instantiate a machine, setup stunnel and a juju client through cloud-init and then connect back to zookeeper through stunnel [15:15] lynxman, ic, so in this case you just want to get the zk addr? [15:16] hazmat: exactly, just tell to the new instantiated machine "your zookeper is at localhost:37173" for example [15:16] hazmat: which will be the endpoint of the stunnel connection [15:17] lynxman, it really depends on the provider, typically a machine is setup to launch the agents with zk address.. ie the cli for the agent has JUJU_ZOOKEEPERS environment var set to the address, it doesn't poke directly at the provider storage [15:20] hazmat: aaah so it'd be as easy as making sure the variable is setup in the permanent environment of the machine then? [15:20] lynxman, for testing sure [15:21] hazmat: k, the var is a dictionary? "1.2.3.4:1234,2.3.4.5:1234" and such? [15:22] ie. you could just launch the agent process and hand it another address, the place where we give the machine agent process its address is in the providers/common/launch.py via cloud-init.. it (the cli or provisioning agent) will poke at the provider-storage to figure out the extant zk servers to setup in cloud-init [15:22] lynxman, its a comma separate string, of the form you just posted [15:22] hazmat: excellent, many thanks :) [15:23] lynxman, np [15:30] hazmat: is there a team meeting today? [15:50] wrtp, good question, we can do one, but i'm not sure we have quorum [15:52] it looks like gustavo, william and myself are on vacation.. i'm game though [15:53] hazmat: ah, i wondered who was still on holiday. [16:33] wrtp: I've got to miss the meeting, we've got an important parents' evening here. Our younger daughter has a class trip the next week (no, not to Budapest *lol*). [16:33] TheMue: that's fine - i'd assumed it's not happening anyway [16:34] * TheMue too [16:58] wrtp, yeah... let's skip it.. we'll all be around next week in person [16:58] hazmat: k [16:58] * hazmat takes dog to vet [17:05] jcastro: around? [17:06] hazmat, sounds good [17:07] koolhead17: yo [17:09] jcastro: am still waiting for mail sir!! :P [17:09] sorry I've been slammed [17:09] I'll do it now [17:10] jcastro: awesome. [17:23] jcastro: got it!! :P [20:57] * SpamapS works through the juju MIR [21:22] hazmat: have you tried running the txzookeeper test suite? I get quite a few failures on it right now [21:24] SpamapS, checking [21:24] SpamapS, the txzk test suite is a little odd, it requires a running zookeeperd it doesn't manage it the same way that juju does [21:24] hazmat: working on running test suites on all package builds.. but 'trial txzookeeper' is looking pretty gruesome on the precise version [21:24] oh [21:25] SpamapS, basically apt-get install zookeeperd [21:25] so just install zookeeperd package an it will start working? [21:25] yup [21:25] ok I can do that. [21:27] still getting tons of fail [21:27] ew and it creates a statically named temp dir [21:28] hazmat: ugh, there's a bug in zookeeper where it listens on :::2181 and not 0.0.0.0:2181 [21:39] SpamapS, it doesn't listen on all ifaces? [21:39] SpamapS, i put in a bug to switch over the txzk tests to manage their own server [21:41] <_mup_> juju/ssh-known_hosts r469 committed by jim.baker@canonical.com [21:41] <_mup_> Test key update in known_hosts [21:42] hazmat: no it doesn't.. bug 888643 .. [21:42] <_mup_> Bug #888643: Zookeeper listen only to IPv6 interface < https://launchpad.net/bugs/888643 > [21:42] hazmat: or rather, it does, but only all ipv6 interfaces [21:42] there seem to be other problems [21:43] its creating /var/lib/zookeeper wrong as well [21:43] <_mup_> juju/ssh-known_hosts r470 committed by jim.baker@canonical.com [21:43] <_mup_> Test key update in known_hosts [21:43] adduser: Warning: The home directory `/var/lib/zookeeper' does not belong to the user you are currently creating. [21:44] ahh [21:44] they've listed the dir in the package [21:44] * SpamapS fixes [21:44] oops, way too quick on choosing which command to repeat ;) [21:45] jimbaker: restoring from backups is just an opportunity to go get coffee. :) [21:45] SpamapS, ;) [21:46] running our unit tests fully is a perfect amount of time to make some tea, for sure [21:47] thats true [21:56] <_mup_> juju/ssh-known_hosts r471 committed by jim.baker@canonical.com [21:56] <_mup_> Missing file from prev commit [22:00] <_mup_> juju/ssh-known_hosts r472 committed by jim.baker@canonical.com [22:00] <_mup_> Sample keys use a fake user, not my account [22:49] hazmat: would the txzookeeper tests be destructive to an existing zookeeper or does it use some kind of unique namespace so it won't trash whats already there? [22:50] hazmat: ahh, I see now.. its extremely dangerous! [22:51] hazmat: deletes the entire thing. Doh. [22:53] SpamapS, could use chroot for zk [22:54] jimbaker: I'd have to build another chroot, inside my chroot, to install zookeeperd. [22:54] SpamapS, no i mean in the connection descriptor for zk itself [22:54] (also called chroot) [22:54] jimbaker: makes *far* more sense for txzookeeper to spin up its own ephemeral zk and manage it. [22:55] SpamapS, sure. just an option [22:55] jimbaker: I don't understand zk or txzk enough to do that. :P .. just going to mark it as affecting the package so we know why we can't run the test suite on build. :) [22:57] SpamapS, no worries. but it's as simple as changing the connection string to append the desired root for the nodes to be put in [22:57] SpamapS, yeah.. its dangerous, the chroot trick is just a matter of specifying the connection string a little different, but per the bug txzk should just setup the zk instance [22:58] its already got the code todo so, just not been rewired into a an appros test layer. [22:58] hazmat: yeah, medium importance.. we'll get to it at some point but its not uber critical since txzk doesn't change that much. [23:23] hazmat: have you taken a close look at the quality fo the 'epsilon' python module used in txaws ? [23:24] hazmat: its kind of abandonware ... the usage is so thin too.. just some date parsing stuff that I'm sure is doable by something already in main... :p [23:26] actually, wow.. ISO8601 is like, the easiest date format ever to parse. [23:30] aha.. python-dateutil .. author: Gustavo Niemeyer. :) [23:32] looks like https://code.launchpad.net/~nijaba/charm-tools/peer-replay/+merge/86721 is finally ready to be reviewed. it builds and runs nicely too :) [23:32] if anyone got some spare time to review.. [23:35] SpamapS: why do we need charms to work with lucid again? [23:35] nijaba: we don't need the charms themselves to work with lucid, but charm-tools we do. [23:36] nijaba: so we can technically just skip the charm helper test suites on anything before oneiric I suppose. [23:36] SpamapS: can you elaborate? I thought we could only run guests which are oneiric or > [23:37] SpamapS: ah, juju tools, not the helpers need to run on 10.04... makes sense [23:41] * SpamapS patches dateutil in for epsilon and jumps for joy when all tests pass. [23:47] seems like we need to have a txaws release at some point soon.