[21:23] thumper: hiya [21:23] morning rogpeppe [21:23] working sunday night? [21:24] carmen's away... [21:24] managed to do a bit of slightly off-piste hacking on saturday [21:24] heh [21:25] result is this CL; review appreciated: https://codereview.appspot.com/13249054/ [21:25] there are some cool things that it makes possible [21:36] for instance it's easy to use it to generate API client-side code automatically. [21:38] or to allow API clients to find out what calls are available [21:59] i also think it makes sense just from the p.o.v. of the structuring of the rpc package too, BTW - it becomes less monolithic, and that part (which is a significant part of the rpc package logic) can be more easily tested independently. [21:59] thumper: but YMMV of course [22:03] I'll take a look, but this is somewhat outside my current experience messing with go/juju [22:16] thumper: that's ok, i actually just want you to marvel at this, which took only an hour to write this afternoon, after i thought of it: http://paste.ubuntu.com/6143236/ :-) [22:17] thumper: it generates API client code for our entire API. [22:18] thumper: output looks like this: http://paste.ubuntu.com/6143244/ [22:18] thumper: it actually compiles, but i haven't tried using it [22:19] heh [22:19] interesting [22:20] thumper: the text/template package is actually surprisingly powerful [22:21] I don't see why the whole docker thread is on three different mailing lists I'm on [22:21] I get every email three times FFS [22:22] thumper: that's because they're so anxious that you read the mailing lists that they subscribed you three times :-) [22:23] no, I'm on all three lists [22:23] and the email is sent to three different lists [22:23] rogpeppe: are you not getting them three times? [22:23] juju-dev, cdo and cloud? [22:24] to: Canonical Clouds , [22:24] cdo@lists.canonical.com, [22:24] canonical-juju [22:24] thumper: i'm not sure [22:25] thumper: my inbox is a mess currentyl [22:25] thumper: well, both my inboxes [22:25] there are two cross list conversations atm [22:31] thumper: i hadn't actually read any of the thread. interesting. [22:31] davecheney: yo! [22:35] rogpeppe: hey [23:00] wallyworld_: thanks for finishing off that logging branch [23:00] np at all [23:01] was good to get it landed [23:30] * thumper got sidetracked starting kvm work fixing lxc tests [23:31] how's the kvm stuff going? [23:33] wallyworld_: https://codereview.appspot.com/13828043 [23:34] wallyworld_: just starting really [23:34] looking [23:34] wallyworld_: I have been focusing primarily on helping you and axw get your things in [23:34] and doing kvm on the side [23:34] thank you :-) [23:34] as it isn't going to make 1.16 [23:34] hoping to have it available shortly after [23:34] definitely prior to SFO [23:34] * thumper crosses fingers [23:35] mass folks will be happy [23:35] maas [23:35] but I want to make sure that the simplestream tools things and null provider stuff gets in [23:45] thumper: why does the PatchEnvironment call followup with a call to cleanup but not the SetPatch calls? [23:45] wallyworld_: it is in setup suite [23:46] the PatchEnvironment in the test is a test cleanup [23:46] not a suite cleanup [23:46] I'm yet to decide on wording for the PatchEnvironmentForSuite name [23:46] or PatchValueForSuite [23:46] perhaps those are good enough [23:49] "the PatchEnvironment in the test is a test cleanup" --- isn't the patch env called from setup suite. i don't quite get what you are saying that it is a test clean up [23:51] with this call "s.PatchValue(&lxcObjectFactory, s.Factory)" is SetupTest, i can't see how the old value is ever restored??? since no cleanup is added [23:51] s/is/in [23:55] ah, the PatchValue is a call on the test [23:55] which automatically adds the cleanup [23:55] see testbase.CleanupSuite [23:56] * thumper -> gym === thumper is now known as thumper-gym