[02:02] jimbaker: yes we did :) === daker_ is now known as daker [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] shhhhhhhhhhhhhhhhhhhhhhh [17:20] SpamapS, yes quiet. heads down all around i guess [17:24] thats a very good thing. :) [18:11] hi. [18:13] happen to know where niemeyer or robbiew are? :-). [18:16] Aram, robbiew is on vacation; niemeyer is at a conf [18:17] thanks. [18:23] jimbaker: is there a PPA somewhere that contains your hookProtocol fix? [18:24] adam_g, no, i could push the branch however. still needs some more testing btw [18:24] adam_g, then you can just use environments.yaml to use that branch, using the ensemble-branch option [18:25] jimbaker: that sounds doable. where is the branch? [18:26] adam_g, just pushed it to lp:~jimbaker/ensemble/robust-hook-exit [18:26] adam_g, hope that works for you! [18:27] jimbaker: great, thanks ill give it a shot later [18:27] adam_g, cool === daker is now known as daker_ [19:49] well, openstack via ensemble is coming together quite nicely: http://paste.ubuntu.com/650191/ [19:49] you have anyway of turning that into a graph, SpamapS ? === franciscosouza_ is now known as franciscosouza [20:07] adam_g: yes! [20:07] adam_g: ensemble status --format=svg --output=file.svg will produce something.. [20:08] 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] neat [20:11] adam_g: lp:~clint-fewbar/ensemble/dot-raw-output [20:11] if you use tha tone you can do ensemble status --format=dot | fdp -Tsvg > file.svg [20:11] adam_g: and btw, w00t. [21:26] any ensemble core dev around? [22:09] hmm.. new analogy for what Ensemble is.. [22:09] Ensemble is to config management as Home Depot is to your toolbox at home. [22:13] SpamapS: when you get into town? [22:24] adam_g: Thursday morning [22:24] adam_g: I unfortunately have 3 other family obligations M,T, and Wed.. :-/ [22:24] adam_g: and Fri night.. so leaving around 6pm Friday. :-P [22:41] hi all [22:42] I need a quick second opinion about test coverage [22:43] 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] 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] however, doing this leaves the coverage only *slightly* improved [22:45] please confirm that the appropriate response is to write the necessary battery of additional tests [22:46] 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] 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] SpamapS: agreed [22:59] 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] 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] SpamapS: cheers, I won't spend too much time on it [23:00] Do we graph test coverage anywhere? [23:00] SpamapS: but I'll have a go at least ;) [23:00] SpamapS: not that I'm aware of, but that would be interesting [23:01] My last employer had a graph over time of test coverage. Bonuses were attached to significant increases. [23:01] Which did very little for the graph going up.. because programming isn't motivated by the carrot and stick. [23:02] Still, the graph was quite interesting when drilling down into a specific subsystem.. you knew how risky the change was.. [23:22] SpamapS: that's a shame [23:23] 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] SpamapS: ...as it were [23:34] fwereade: well certainly, new stuff got more tests because you didn't want the percentage to go *down* [23:42] there is a `make coverage` target which will generate a table [23:48] 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] bcsaller: did I see service config settings land this week? [23:54] 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