[00:30] <SpamapS> 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] <jelmer> SpamapS: urgh, spurious failures suck
[00:53] <jelmer> 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] <SpamapS> 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] <jelmer> ah, bug 693524 ?
[00:55] <_mup_> Bug #693524: Daily builds of Java packages fail: "Could not reserve enough space for object heap" <recipe> <Launchpad Auto Build System:Triaged> < https://launchpad.net/bugs/693524 >
[01:03] <SpamapS> jelmer: indeed
[01:05] <SpamapS> 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] <wrtp> mornin' all
[09:48] <koolhead17> hi all
[10:08] <koolhead17> jcastro: ping
[10:10] <nijaba> koolhead17: would be surprised if jcastro wa already awake, he is east coast based
[10:10] <koolhead17> nijaba: sorry, i always get confused with the timezone slaughter :(
[11:08] <TheMue> koolhead17: My little friend here is http://www.worldtimebuddy.com/. Here I've stored the locations of the whole team. ;)
[11:10] <koolhead17> TheMue: cool
[12:43]  * hazmat yawns
[14:32] <lynxman> hazmat: whenever you got your coffee with you, what was the file again where the juju client writes its zookeeper node address?
[14:33] <hazmat> lynxman, its the key 'provider-state'  in the provider storage
[14:34] <lynxman> hazmat: hmm okay, any recommendation in how to alter it through the command line? :)
[15:04] <hazmat> lynxman, um.. there isn't one, what's the problem your trying to solve?
[15:05] <lynxman> 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] <hazmat> lynxman, ic, so in this case you just want to get the zk addr?
[15:16] <lynxman> hazmat: exactly, just tell to the new instantiated machine "your zookeper is at localhost:37173" for example
[15:16] <lynxman> hazmat: which will be the endpoint of the stunnel connection
[15:17] <hazmat> 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] <lynxman> 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] <hazmat> lynxman, for testing sure
[15:21] <lynxman> hazmat: k, the var is a dictionary? "1.2.3.4:1234,2.3.4.5:1234" and such?
[15:22] <hazmat> 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] <hazmat> lynxman, its a comma separate string, of the form you just posted
[15:22] <lynxman> hazmat: excellent, many thanks :)
[15:23] <hazmat> lynxman, np
[15:30] <wrtp> hazmat: is there a team meeting today?
[15:50] <hazmat> wrtp, good question, we can do one, but i'm not sure we have quorum
[15:52] <hazmat> it looks like gustavo, william and myself are on vacation.. i'm game though
[15:53] <wrtp> hazmat: ah, i wondered who was still on holiday.
[16:33] <TheMue> 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] <wrtp> TheMue: that's fine - i'd assumed it's not happening anyway
[16:34]  * TheMue too
[16:58] <hazmat> wrtp, yeah... let's skip it.. we'll all be around next week in person
[16:58] <wrtp> hazmat: k
[16:58]  * hazmat takes dog to vet
[17:05] <koolhead17> jcastro: around?
[17:06] <jimbaker> hazmat, sounds good
[17:07] <jcastro> koolhead17: yo
[17:09] <koolhead17> jcastro: am still waiting for mail sir!! :P
[17:09] <jcastro> sorry I've been slammed
[17:09] <jcastro> I'll do it now
[17:10] <koolhead17> jcastro: awesome.
[17:23] <koolhead17> jcastro: got it!! :P
[20:57]  * SpamapS works through the juju MIR
[21:22] <SpamapS> hazmat: have you tried running the txzookeeper test suite? I get quite a few failures on it right now
[21:24] <hazmat> SpamapS, checking
[21:24] <hazmat> 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] <SpamapS> hazmat: working on running test suites on all package builds.. but 'trial txzookeeper' is looking pretty gruesome on the precise version
[21:24] <SpamapS> oh
[21:25] <hazmat> SpamapS, basically apt-get install zookeeperd
[21:25] <SpamapS> so just install zookeeperd package an it will start working?
[21:25] <hazmat> yup
[21:25] <SpamapS> ok I can do that.
[21:27] <SpamapS> still getting tons of fail
[21:27] <SpamapS> ew and it creates a statically named temp dir
[21:28] <SpamapS> hazmat: ugh, there's a bug in zookeeper where it listens on :::2181 and not 0.0.0.0:2181
[21:39] <hazmat> SpamapS, it doesn't listen on all ifaces?
[21:39] <hazmat> 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] <SpamapS> hazmat: no it doesn't.. bug 888643 ..
[21:42] <_mup_> Bug #888643: Zookeeper listen only to IPv6 interface <zookeeper (Ubuntu):Confirmed> < https://launchpad.net/bugs/888643 >
[21:42] <SpamapS> hazmat: or rather, it does, but only all ipv6 interfaces
[21:42] <SpamapS> there seem to be other problems
[21:43] <SpamapS> 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] <SpamapS> adduser: Warning: The home directory `/var/lib/zookeeper' does not belong to the user you are currently creating.
[21:44] <SpamapS> ahh
[21:44] <SpamapS> they've listed the dir in the package
[21:44]  * SpamapS fixes
[21:44] <jimbaker> oops, way too quick on choosing which command to repeat ;)
[21:45] <SpamapS> jimbaker: restoring from backups is just an opportunity to go get coffee. :)
[21:45] <jimbaker> SpamapS, ;)
[21:46] <jimbaker> running our unit tests fully is a perfect amount of time to make some tea, for sure
[21:47] <SpamapS> 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] <SpamapS> 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] <SpamapS> hazmat: ahh, I see now.. its extremely dangerous!
[22:51] <SpamapS> hazmat: deletes the entire thing. Doh.
[22:53] <jimbaker>  SpamapS, could use chroot for zk
[22:54] <SpamapS> jimbaker: I'd have to build another chroot, inside my chroot, to install zookeeperd.
[22:54] <jimbaker> SpamapS, no i mean in the connection descriptor for zk itself
[22:54] <jimbaker> (also called chroot)
[22:54] <SpamapS> jimbaker: makes *far* more sense for txzookeeper to spin up its own ephemeral zk and manage it.
[22:55] <jimbaker> SpamapS, sure. just an option
[22:55] <SpamapS> 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] <jimbaker> 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] <hazmat> 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] <hazmat> its already got the code todo so, just not been rewired into a an appros test layer.
[22:58] <SpamapS> 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] <SpamapS> hazmat: have you taken a close look at the quality fo the 'epsilon' python module used in txaws ?
[23:24] <SpamapS> 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] <SpamapS> actually, wow.. ISO8601 is like, the easiest date format ever to parse.
[23:30] <SpamapS> aha.. python-dateutil .. author: Gustavo Niemeyer. :)
[23:32] <nijaba> 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] <nijaba> if anyone got some spare time to review..
[23:35] <nijaba> SpamapS: why do we need charms to work with lucid again?
[23:35] <SpamapS> nijaba: we don't need the charms themselves to work with lucid, but charm-tools we do.
[23:36] <SpamapS> nijaba: so we can technically just skip the charm helper test suites on anything before oneiric I suppose.
[23:36] <nijaba> SpamapS: can you elaborate?  I thought we could only run guests which are oneiric or >
[23:37] <nijaba> 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] <SpamapS> seems like we need to have a txaws release at some point soon.