[01:50] <hazmat> jimbaker, hmm.. i might have modified that when i was doing the ec2 testing
[01:53] <hazmat> yeah.. its the test needs a trivial fix
[03:17] <jimbaker> hazmat, yeah, it looks pretty trivial for sure
[15:54]  * hazmat continues to try his luck with debs
[16:01] <SpamapS> hazmat: heh, want some help? :)
[16:02] <SpamapS> hazmat: I've found 'mk-sbuild' to be super helpful. :) its part of 'ubuntu-dev-tools'
[16:03] <SpamapS> hazmat: sbuild will take a debian source package and build it in a clean environment, much like your ec2 build, but on the local machine.
[16:03] <hazmat> SpamapS, cool, is it based on pbuilder?
[16:03] <hazmat> or i perhaps the other way around
[16:03] <hazmat> SpamapS, i dug through some more of the ubuntu packaging docs last night, some good material
[16:04] <hazmat> i think i was making due with debian new maintainer's guide and UTSL on source-packages last time around
[16:07] <SpamapS> hazmat: pbuilder is, honestly, kind of a pain in the ass
[16:08] <SpamapS> hazmat: sbuild builds you a chroot that you can jump into when there are build problems..
[16:08] <SpamapS> I think pbuilder can do that too..
[16:08] <SpamapS> but I've just had tons more success w/ sbuild than I used to w/ pbuilder
[16:09] <SpamapS> hazmat: so what are you stuck on?
[16:14] <hazmat> SpamapS, at the moment just trying to close the loop on getting new images built with the existing packaging stuff
[16:14] <hazmat> on natty
[16:14] <niemeyer> Hey guys!
[16:14]  * niemeyer heads to lunch
[16:15] <hazmat> using the ec2-build stuff.. i figure after ensemble works, after starting in on packages the 'proper' way
[16:26] <jimbaker> niemeyer_lunch, have a good lunch too :)
[17:11] <niemeyer> jimbaker: Thanks
[17:11] <niemeyer> jimbaker: Was good indeed
[17:12] <jimbaker> niemeyer, i do remember how well we ate in brazil. my wife still talks about the breakfast at our hotel in recife
[17:13] <jimbaker> (she loves fruit, every kind)
[17:21] <_mup_> Bug #771348 was filed: status barfs when checking newly deployed service units (no state) <Ensemble:New> < https://launchpad.net/bugs/771348 >
[17:21] <hazmat> what's the next milestone after budapest? i'd like to start triaging some bugs over to the next release?
[17:22] <jimbaker> is that the lxc sprint?
[17:22] <hazmat> jimbaker, well its roughly corresponding to ubuntu releases, perhaps we should cycle over and use oneiric next
[17:23] <bcsaller> or just call it .next till we have a place-name to use for it
[17:23] <bcsaller> assuming you can rename a milestone
[17:23] <hazmat> although we need to get most of the  dev release done by th end of the oneiric dev cycle not the official release afaicr
[17:23] <hazmat> bcsaller, +1
[17:24] <niemeyer> We could set a milestone to the next sprint after UDS
[17:27] <hazmat> just created next and later milestones, to be renamed/dates as needed
[17:39] <_mup_> ensemble/unit-agent-resolved r252 committed by kapil.thangavelu@canonical.com
[17:39] <_mup_> parameterize unit lifecycle method with fire_hooks boolean, default true
[17:49] <niemeyer> hazmat: Hmm, that may be a rabbit hole
[17:49] <niemeyer> hazmat: Let's decide on that
[17:50] <niemeyer> hazmat: Assigning features to a point in time we don't know quickly becomes a black hole
[17:51] <niemeyer> hazmat: There's no way to say "No, let's not schedule for that timing"
[17:51] <hazmat> niemeyer, both the next, later have dates targeted towards the end of the ubuntu release cycle
[17:51] <hazmat> er. release dev cycle
[17:51] <hazmat> for the next two releases
[17:52] <niemeyer> hazmat: We need shorter milestones
[17:52] <hazmat> niemeyer, two month cycles?
[17:52] <niemeyer> hazmat: Yeah, something around that sounds better
[17:52] <hazmat> continous release ;-)
[17:53] <niemeyer> hazmat: Yeah, what are we doing next month in our continuous release? ;-)
[17:54] <_mup_> ensemble/ec2-deb-build r211 committed by kapil.thangavelu@canonical.com
[17:54] <_mup_> switch ec2-build over to natty
[17:56] <_mup_> ensemble/ec2-deb-build r212 committed by kapil.thangavelu@canonical.com
[17:56] <_mup_> additional zk deb dep, installed by hand since using dpkg to install custom binary debs atm.
[17:59]  * hazmat lunches
[17:59] <niemeyer> hazmat: Enjoy
[18:35] <hazmat> hmm.. still not working
[18:54] <_mup_> ensemble/unit-agent-resolved r253 committed by kapil.thangavelu@canonical.com
[18:54] <_mup_> rename state variables to transition variables, pass transition variables to transition
[18:55] <jimbaker> hazmat, re status barfing, my reading of the logic should be that the relation_status dict should never get into a bad state that yaml or json cannot serialize
[18:55] <jimbaker> but obviously something did happen
[18:55] <jimbaker> i wonder if it were based on another exception than the one that's being caught?
[18:55] <hazmat> jimbaker, i had tracked it down last week and modified it locally 
[18:56] <hazmat> i don't recall the exact detail though atm.. it was being caught
[18:56] <jimbaker> hazmat, weird, because that codepath is definitely being exercised
[18:56]  * hazmat looks for the diff
[18:57] <koolhead17> hi all
[18:57] <jimbaker> if we remove the logic, then test_misconfigured_provider will cause problems in the status collection
[18:57] <hazmat> hmm.. blew it away
[18:58] <hazmat> jimbaker, misconfigured provider is testing something different
[18:59] <hazmat> maybe not.. rather hard to tell what is testing actually
[19:02] <hazmat> jimbaker, yeah.. that test is testing that machine id is known to the provider
[19:02] <hazmat> nothing to do with the unit relation state
[19:03] <jimbaker> hazmat, probably want to add a test to directly test this case
[19:13] <jimbaker> hazmat, i reverified that test_misconfigured_provider will do this. maybe it really needs to be split into a separate test to show this more directly with respect to a unit state without the corresponding unit relation state
[19:13] <hazmat> jimbaker, yeah.. a docstring describing what the test is testing would be helpful
[19:23] <niemeyer> hazmat: set_resolved_relation({"db": Retry})
[19:23] <niemeyer> hazmat: set_resolved_relation({"db": DontRetry})
[19:37] <jimbaker> bcsaller, here's the pastie for my test run of refactor-to-yamlstate: http://paste.ubuntu.com/599439/
[19:38] <bcsaller> thanks, I'll look into it
[19:39] <jimbaker> bcsaller, this is to r198
[19:45] <hazmat> its interesting watching both plone and openstack go through the 'choice' of settling in github
[19:45] <hazmat> simulatenously
[20:12] <niemeyer> hazmat: What was the branch you said should hold on reviews?
[20:12] <niemeyer> hazmat: ensemble-alternate-regions?
[20:13] <jimbaker> niemeyer, that's correct
[20:13] <niemeyer> jimbaker, hazmat: Ok, I'm moving it to WIP then
[20:14] <hazmat> niemeyer, thanks.
[20:14] <niemeyer> hazmat: No problem
[20:28] <_mup_> ensemble/ec2-deb-build r213 committed by kapil.thangavelu@canonical.com
[20:28] <_mup_> try a new image
[20:39] <hazmat> woot! ensemble works again
[20:44] <jimbaker> hazmat, good to hear. let me try it out too
[20:48] <hazmat> jimbaker, if you use ec2-deb-build and spec it as your ensemble-branch is what's needed at the moment, only us-east-1
[20:48] <hazmat> i'm remastering images in other regions atm
[20:48] <jimbaker> hazmat, that's what i figured, thanks
[20:57] <hazmat> SpamapS, do you use mk-sbuild with lvm or btrfs?
[20:58] <jimbaker> hazmat, looking good: http://ec2-50-16-177-41.compute-1.amazonaws.com/
[20:59] <hazmat> jimbaker, good stuff
[21:00] <hazmat> SpamapS, so with mk-sbuild i take that it reuses a snapshot as a pristine image for subsequent builds
[21:50] <_mup_> ensemble/ec2-deb-build r214 committed by kapil.thangavelu@canonical.com
[21:50] <_mup_> ensemble natty images w/ updated zk in all five aws regions
[22:00] <SpamapS> hazmat: I use it as aufs
[22:00] <SpamapS> s/as/with/
[22:00] <SpamapS> hazmat: which is its default
[22:00] <SpamapS> hazmat: no extra setup required. :)
[22:00] <hazmat> cool
[22:25] <SpamapS> hazmat: granted, lvm and btrfs will be faster, and not have a filename length limit so short as aufs.