[02:02] <shang> jimbaker: yes we did :)
[14:32] <_mup_> ensemble/security-acl r291 committed by kapil.thangavelu@canonical.com
[14:32] <_mup_> an acl abstraction allowing grants/removals by principal name on nodes
[17:14] <SpamapS> shhhhhhhhhhhhhhhhhhhhhhh
[17:20] <jimbaker> SpamapS, yes quiet. heads down all around i guess
[17:24] <SpamapS> thats a very good thing. :)
[18:11] <Aram> hi.
[18:13] <Aram> happen to know where niemeyer or robbiew are? :-).
[18:16] <jimbaker> Aram, robbiew is on vacation; niemeyer is at a conf
[18:17] <Aram> thanks.
[18:23] <adam_g> jimbaker: is there a PPA somewhere that contains your hookProtocol fix?
[18:24] <jimbaker> adam_g, no, i could push the branch however. still needs some more testing btw
[18:24] <jimbaker> adam_g, then you can just use environments.yaml to use that branch, using the ensemble-branch option
[18:25] <adam_g> jimbaker: that sounds doable. where is the branch?
[18:26] <jimbaker> adam_g, just pushed it to lp:~jimbaker/ensemble/robust-hook-exit
[18:26] <jimbaker> adam_g, hope that works for you!
[18:27] <adam_g> jimbaker: great, thanks ill give it a shot later
[18:27] <jimbaker> adam_g, cool
[19:49] <adam_g> well, openstack via ensemble is coming together quite nicely: http://paste.ubuntu.com/650191/
[19:49] <adam_g> you have anyway of turning that into a graph, SpamapS ?
[20:07] <SpamapS> adam_g: yes!
[20:07] <SpamapS> adam_g: ensemble status --format=svg --output=file.svg will produce something..
[20:08] <SpamapS> adam_g: if you use the branch I made yesterday you can try out a few different layouts (fdp seems the most consistently useful)
[20:08] <adam_g> neat
[20:11] <SpamapS> adam_g: lp:~clint-fewbar/ensemble/dot-raw-output
[20:11] <SpamapS> if you use tha tone you can do ensemble status --format=dot | fdp -Tsvg > file.svg 
[20:11] <SpamapS> adam_g: and btw, w00t.
[21:26] <RoAkSoAx> any ensemble core dev around?
[22:09] <SpamapS> hmm.. new analogy for what Ensemble is..
[22:09] <SpamapS> Ensemble is to config management as Home Depot is to your toolbox at home.
[22:13] <adam_g> SpamapS: when you get into town?
[22:24] <SpamapS> adam_g: Thursday morning
[22:24] <SpamapS> adam_g: I unfortunately have 3 other family obligations M,T, and Wed.. :-/
[22:24] <SpamapS> adam_g: and Fri night.. so leaving around 6pm Friday. :-P
[22:41] <fwereade> hi all
[22:42] <fwereade> I need a quick second opinion about test coverage
[22:43] <fwereade> you may or may not be aware that there's a problem in trunk, with certain tests that fail or timeout depending on the absence or flakiness of the network
[22:43] <fwereade> it emerges that there was a commented-out line in the mocking setup, and that reinstating it (with a minor tweak) fixes the issue
[22:45] <fwereade> however, doing this leaves the coverage only *slightly* improved
[22:45] <fwereade> please confirm that the appropriate response is to write the necessary battery of additional tests
[22:46] <fwereade> and that just reinstating the tweaked line is a pitiful and weaksauce dodge of the real issue, that I should be ashamed of myself for considering
[22:58] <SpamapS> fwereade: tests that work w/o the network are critical.. eventually we want the Ubuntu buildd's to run the test suite .. and they have no network connectivity.
[22:59] <fwereade> SpamapS: agreed
[22:59] <fwereade> SpamapS: the question is, do I reinstate weak tests that work without a network or do I write a bunch more that also work without the network, and give us better coverage?
[22:59] <SpamapS> fwereade: so I'd say that if you have the time to do the additional testing.. it is a noble and high cloud that awaits you in programmer heaven. But if you are pressed for time.. making the tests run w/o the network would get the tests run more often, which may be more important.
[23:00] <fwereade> SpamapS: cheers, I won't spend too much time on it
[23:00] <SpamapS> Do we graph test coverage anywhere?
[23:00] <fwereade> SpamapS: but I'll have a go at least ;)
[23:00] <fwereade> SpamapS: not that I'm aware of, but that would be interesting
[23:01] <SpamapS> My last employer had a graph over time of test coverage. Bonuses were attached to significant increases.
[23:01] <SpamapS> Which did very little for the graph going up.. because programming isn't motivated by the carrot and stick.
[23:02] <SpamapS> Still, the graph was quite interesting when drilling down into a specific subsystem.. you knew how risky the change was..
[23:22] <fwereade> SpamapS: that's a shame
[23:23] <fwereade> SpamapS: even if the carrot itself wouldn't work, perhaps they hoped that being seen to care about such things might be a sort of, er, motivational meta-carrot
[23:23] <fwereade> SpamapS: ...as it were
[23:34] <SpamapS> fwereade: well certainly, new stuff got more tests because you didn't want the percentage to go *down*
[23:42] <bcsaller> there is a `make coverage` target which will generate a table 
[23:48] <SpamapS> So in theory, we could run back through all the commits and run it for each one, and graph that, and then do that on an ongoing basis?
[23:54] <SpamapS> bcsaller: did I see service config settings land this week?
[23:54] <bcsaller> SpamapS: yeah, there is still an approved branch I have to merge for `deploy` but the `set` version of things work. I expect the other will go in today and it will be ready