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