[00:06] niemeyer, any preferences in terms of python tools for writing html? cheetah? [00:09] jimbaker: I would prefer something very simple [00:09] niemeyer, exactly. so please tell me what you prefer, and i will use it :) [00:09] jimbaker: If possible a single Python file we can embed in the project itself [00:10] jimbaker: Since our needs are pretty trivial.. just iterating over a list building a table with OK/FAILED + links [00:11] jimbaker: Do you know anything like that? [00:12] I'll get some food, biab [00:12] niemeyer, i don't know of an ultra simplistic tool. typically when it's framed like that, it tends to be done with just direct writes [00:16] OK/FAILED links? isn't that what jenkins does? [00:16] niemeyer, but in my experience that rarely works well. best to use a tool chain that ensures compliant output. i haven't used cheetah, but i know it's used by other people on the ubuntu server team [00:16] SpamapS, correct, we are re-implementing what jenkins does [00:16] SpamapS, regardless this is the task i have [00:16] eh? [00:17] for our functional testing [00:19] Right, subunit doesn't have something ? [00:19] I mean, jenkins is like, the industry standard. [00:19] And we have a.. really kick ass jenkins formula. :) [00:19] SpamapS, agreed that jenkins is the industry standard [00:20] https://wiki.jenkins-ci.org/display/JENKINS/NUnit+Plugin [00:20] I was kind of hoping we'd get to a point where we were graphing all that lovely test coverage [00:21] SpamapS, yes, output to standard nunitxml is pretty trivial. subunit supports this, through subunit2junitxml. however, the functional testing will not be done w/ trial [00:22] aww snap [00:22] SpamapS, this is actually a good thing. trial is pretty wretched for long running functional tests [00:22] SpamapS, niemeyer has written a new test runner that will execute shell scripts (this is the churn we discussed earlier on this channel) [00:23] Awright. Well, I don't really see us matching jenkins for frontend capabilities.. probably worth your time to produce nunint/junit xml and then just chug through it on jenkins. [00:23] SpamapS, however, it might make sense to output junitxml instead. perhaps that could be considered at a later time. [00:23] A new test runner that runs shell scripts? [00:23] Thats also what jenkins does. :) [00:24] Tho its not much of a tool for developers to run in an iterative sense.. [00:24] I didn't think the functional tests would be somethign you'd do in that manner. [00:24] Figured you'd just set jenkins jobs up to point at in progress branches and trunk and run tests on commit [00:25] SpamapS, that makes a lot of sense to do. again the test runner could readily output junitxml [00:26] SpamapS, the more important thing is that we want functional tests directly exercising ensemble commands [00:27] Hey, me too. :) [00:27] On all supported configurations [00:28] (that last bit is integration testing.. but .. details.. ;) [00:28] SpamapS, cool. so consider this as an intermediate step [00:28] trust me, it will be very easy to have this integrated into jenkins in some subsequent step [00:29] Alright, well yeah, I'd think the time spent outputting HTML would be better spent outputting junitxml that jenkins can read and digest. [00:29] On the tests.. [00:29] I wrote a few silly bash scripts that deploy/relate/query the formulas.. and james page came up with a cool way to have formulas embed tests ... [00:29] we should have a pow-wow once you've got the test runner doing some stuff. [00:32] SpamapS, sounds like a plan. i definitely want to hear more about james' ideas [00:34] SpamapS, we could readily add your bash scripts [00:35] jimbaker: I need to distill them down to smaller nuggets that can be encapsulated and run wherever.. one challenge is setting up the env w/ an environments.yaml and ssh key and such [00:36] SpamapS, yeah, that's a much more interesting problem. one thing that we can do w/ building out environments.yamls is do things like running several envs in parallel [00:37] SpamapS, i do have a variant of sshclient that ignores possible man-in-the-middle, but it would be much better if we managed this properly [00:39] SpamapS, another thing i did play with was making sshclient much more robust for extremely long waits. at the very least, we might want to have something like a wait-for-ensemble ENVIRONMENT which successively looks at the milestones in an env coming up [00:40] (it might also be a useful ensemble subcommand in the future, don't know) [00:43] Not sure what you mean [00:43] I wrote a wait4state perl script that just runs status [00:43] jimbaker: This looks nice: https://github.com/defunkt/pystache [00:45] but /win 10 [00:45] doh [00:45] niemeyer, looks good to me, thanks! [00:46] SpamapS, but /win... ? [00:46] irssi [00:46] hey quick python question [00:46] do lists keep an internal length? [00:46] jimbaker: It's an incarnation of this: http://mustache.github.com/ [00:47] I'm profiling something that does len(giant_list) a lit and it seems to me that removing these calls makes it a lot faster (and just keeping track of the length in a different variable) [00:47] SpamapS: They do [00:47] SpamapS: Are you doing tons of those calls? [00:47] yes [00:48] SpamapS: function calls in Python are expensive in general.. you may just be seeing that cost [00:48] niemeyer, yeah, mustache is a fine approach [00:48] 5 for every line of a 500,000 line file.... [00:48] So I'm not crazy.. its not a massive expense per call.. but it adds up [00:48] SpamapS, doesn't seem to be so much even for cpython [00:48] SpamapS: Yeah, definitely.. you'd notice 2.5M Python function calls for sure [00:49] http://paste.ubuntu.com/680217/ [00:49] so there, we have two contrasting viewpoints [00:49] now to find out where the other 8.8s are spent. :-P [00:50] jimbaker: You mean you don't find them expensive? [00:51] niemeyer, i just don't think it's that bad if it's just 2.5M [00:52] jimbaker: [00:52] niemeyer, functional call overhead in cpython is obviously quite expensive, for a variety of reasons [00:52] def f(): pass [00:52] start = time() [00:52] for i in range(2500000): f() [00:52] print time()-start [00:52] jimbaker: This takes 1 second in my machine [00:52] jimbaker: Doing absolutely nothing [00:52] jimbaker: There's more than a function call there, but gives an idea [00:52] niemeyer, i'm sure that's the case :) [00:53] jimbaker: That's what I meant by "you'd notice" [00:53] it's just that 0.5s as the case w/ SpamapS's perf or 1s for your case is still a relatively small number compared to what i have seen in the past, that's all ;) [00:54] but if run in a command, or in the direct path for rendering a page, sure, it's extremely noticeable [00:54] That, and things like .append, .sort, etc, are the only function calls.. [00:54] this script lags the same algorithm in perl by about 15% [00:54] I was wrong btw, it doesn't do 5 for every line [00:54] just 1 len for every line [00:55] but yeah, 500,000 is 0.504s [00:55] SpamapS, did you try it w/ pypy? that would be an interesting exercise [00:55] jimbaker: I wanted to but didn't know how to even get pypy ;) [00:55] functional call overhead w/ pypy is extremely reduced [00:55] Yeah, should kick ass [00:56] lol.. lucid, karmic, and jaunty.. :-P [00:56] http://pypy.org/download.html - just give it a try, i don't know where they are on latency [00:56] Takes 16ms in Go.. [00:56] The 2.5 [00:57] niemeyer, that might be close to pypy for the empty case, factoring out startup. which may or may not be applicable, given the domain [00:58] (i too should give it a try ;) ) [00:58] Maybe.. haven't tried that kind of thing there yet.. would be curious, though [00:58] Given their latest work it must be pretty amazing [01:01] bbl [01:01] pretty hard to find pypy binaries.. :-P [01:54] <_mup_> Bug #838568 was filed: push-review must be tested again < https://launchpad.net/bugs/838568 > === daker_ is now known as daker [13:57] Alow! [14:16] jimbaker`, jinja2 is pretty nice re templating engines [14:24] <_mup_> ensemble/local-provider r353 committed by kapil.thangavelu@canonical.com [14:24] <_mup_> remove utility wait_for_node, just make the nesc. method public on zookeeperconnect, allow get open port to take a host option. [15:00] hazmat, jinja2 is fine. but let's go with mustache [15:01] jimbaker`, wasn't clear that mustache has any advantage over say.. string.Template [15:05] er.. actually string formatters [15:06] mustache looks fine though [15:08] hazmat, mustache does one very important thing, which is that it performs html encoding [15:09] when compared to string.Template. obviously the mustache {{}} itself is familiar in both templating systems [15:10] jimbaker`: and loops, I guess [15:53] Lunch time.. biab! [16:14] niemeyer: can we get push-review from a PPA or something? [16:14] niemeyer: I *really* like the automation it promises. :) [16:21] <_mup_> Bug #839695 was filed: ensemble.formula.tests.test_bundle.BundleTest.test_executable_extraction fails on empty home dir < https://launchpad.net/bugs/839695 > [16:27] hazmat: re the bug linked above.. [16:28] hazmat: its checking for 493 as the stat.. but.. in my bzr co of ensemble, its 509 .. I believe this is because umask has changed on ubuntu.. [16:28] but I could be wrong [16:29] indeed.. its just a matter of how you checked out the branch [16:33] I think the appropriate check is that the stat *matches* the sample.. not that it is exactly 509.. basically we want to make sure exec was preserved [16:41] SpamapS, sounds good [16:45] hazmat: http://pastebin.com/DaaJ1Mp0 [16:46] that is currently building in my PPA.. if it passes all tests, I'll change debian/rules to fail the build on test fail and submit a FFe for revision 336 to upload to Ubuntu. [16:47] (with the 3 patches I've submitted for review applied.. ;) [16:55] SpamapS: Absolutely! Working on that already.. should be apt-gettable today [18:16] hey m_3 [18:16] http://blog.carbonfive.com/2011/09/01/deploying-node-js-on-amazon-ec2/ [18:17] <_mup_> Bug #839794 was filed: Final test for the tool! < https://launchpad.net/bugs/839794 > [18:17] would now be a good time to ask how the node standalone formula is coming along? [18:45] jcastro, i like how that blog post begins: "After nearly a month of beating my head against the wall that is hosted node.js stacks — with their fake beta invites and non-existent support..." [18:46] jcastro: hey [18:47] jcastro: yeah, the node formula was part of a talk I gave on IRC a few weeks ago [18:47] jcastro: I'll brush it off, promote it to principia, and blog about it [18:47] m_3: do you have time to post a response to the guy? [18:47] it reads to me like he needs ensemble hard core [18:49] jcastro: yeah, I'll do it during a boring talk this afternoon [18:49] oh sorry, forgot you were travelling [18:50] jcastro: conf wraps up today, so I'll be able to put time on it over the weekend === niemeyer_ is now known as niemeyer === daker is now known as daker_ [19:51] jcastro: ping [19:55] negronjl: pong [19:56] jcastro: in a meeting right now.. I'll ping you later [19:56] * jcastro nods [19:56] <_mup_> ensemble/local-unit-deploy r354 committed by kapil.thangavelu@canonical.com [19:56] <_mup_> factor out unit environment retrieval into separate method. [20:14] <_mup_> ensemble/local-unit-deploy r355 committed by kapil.thangavelu@canonical.com [20:14] <_mup_> user/environment qualified lxc container name, tweak upstart job [20:28] <_mup_> ensemble/local-unit-deploy r356 committed by kapil.thangavelu@canonical.com [20:28] <_mup_> additional test for qualified container name [21:01] SpamapS, does upstart do env expansion on the exec stanza? [21:11] hazmat: yes [21:24] Okay.. lpad is out, lbox is out.. back to reviews and porting formulas [21:25] But I'll step out for now.. may do some extra time tomorrow for helping on the queue [21:26] * niemeyer bbl [21:33] <_mup_> ensemble/local-unit-deploy r357 committed by kapil.thangavelu@canonical.com [21:33] <_mup_> have upstart respawn and run the container in the foreground, doc strings for all container deployment methods. [21:36] * robbiew needs a drink [21:44] excellent idea [21:49] hazmat: upstart for containers, but not for the agents?! [21:51] SpamapS, for the agent [21:51] unit agent only [21:51] inside a container [21:52] its not truly restartable.. probably shouldnt' be respawn auto [21:52] * hazmat returns with a bloody mary [21:53] SpamapS, one nice fallout of the local dev stuff, it should be pretty easy to use this for arm servers, with an external zk address. [21:53] task tsk.. we need our idempotency. :) [21:53] :) [21:53] * hazmat reruns tests to ascertain potency [21:56] oh I thought you were saying that its not re-startable because of some problem with idempotency [22:09] SpamapS, the real issue is loss of events while the agent was down, in practice its probably not an issue, except when it is [22:10] err.. events? [22:10] no good reason not to go ahead with it i suppose [22:10] I thought we just watched to see what the state was [22:10] if we miss 4 changes, who cares, just make the new state true. [22:10] SpamapS, if the agent is down, watches won't be delivered [22:11] and extant watches need to be restablished as new watches potentially [22:11] if we need that, we need a queue, not a data store [22:11] But I see what you're saying [22:12] we're delivering a queue/event interface to formulas, but disconnections mean establishing a delta between state on reconnect to inform the formula of the events between the watch restablishment [22:12] what we need is to keep track of what state the agent thinks it is in, so when it comes back up it can do the appropriate transitions. [22:12] Thats not a queue.. thats a watched data store. [22:12] yup [22:12] Convenient, yes, but not a queue. :) [22:12] its really a sync between a remote and local data store [22:12] to compute the delta [22:13] I see the problem.. very interesting [22:13] in truth its probably a very rare issue in practice for a respawn [22:13] for a net split its more significant [22:13] or any long running outage [22:13] yeah, so at the moment, ensemble is not partition tolerant. ;) [22:16] * SpamapS disappears [22:16] SpamapS, have a good weekend [22:55] how do i push a branch that's a branch of lp:~ensemble/ensemble/ftests ? i tried this, but it's not right: bzr push --stacked-on lp:~ensemble/ensemble/ftests --remember lp:~jimbaker/ensemble/ftests/generate-html [23:02] niemeyer, ^^^ ? [23:09] <_mup_> ensemble/local-unit-deploy r358 committed by kapil.thangavelu@canonical.com [23:09] <_mup_> use ensemble home instead of units directory for all unit deployments [23:09] jimbaker`, i think you just push to ~jimbaker/ensemble/generate-html [23:10] its on the merge side you pick the series branch afaik [23:10] * hazmat checks [23:10] hazmat, ok, i was wondering why it was wanting to use the wrong series [23:10] yup [23:11] jimbaker`, so on merge the target branch is ensemble/ftests [23:11] there all branches of the same project for the user project namespace [23:11] s/their [23:15] <_mup_> Bug #839969 was filed: Checkout Ensemble branch, run bash ftests, and generate summary in HTML < https://launchpad.net/bugs/839969 > [23:18] jimbaker`, is the ftest stuff using jenkins for test running? [23:18] hazmat, no [23:18] just wondering if we could submit tests for branches in dev [23:18] via an api [23:19] w/ the security integration tests get about 30% slower out of the box on average... [23:19] tests will get merged as normal i would think. at some point, we will have jenkins integration, it would be simple/trivial to do [23:19] jimbaker`, i guess i'm confused what's running the tests? your not using jenkins or buildbot? [23:21] i'm using two new tools: butler.py, which i just wrote; and niemeyer's churn, which executes bash scripts [23:21] a butler used to manage the buttery, which might store the results of the churning... [23:22] and of course jenkins is presumably a butler. whatever ;) [23:22] not sure i understand why.. but okay [23:22] hazmat, at some point jenkins is presumed. twisted trial however is definitely not going to be used [23:23] the reason is that we need something that is focused on running ensemble commands [23:23] jimbaker`, i assume the test runner would be doing normal tests and ftests [23:23] is that not accurate? [23:23] that's not accurate [23:23] it's only running ftests, which are to be only be written using bash [23:24] that's niemeyer's decision, and it makes sense [23:24] from a purpose of ease of test dev for users probably [23:24] such test scripts could potentially use resources that are written in python, eg to validate results or to wait for resources [23:25] still i seems like conflating issues, an ftest suite and test suite, and the test bot [23:26] hazmat, perhaps, but it's hopefully what was requested by niemeyer. again i think it's pretty simple, and it will integrate well w/ jenkins eventually, just need to emit junitxml instead of the summary html file [23:26] jimbaker`, fair enough.. we need a test runner for the ftests that does reports [23:27] and that's the merge proposal :) [23:32] bcsaller, do you have a moment to catch up? [23:33] hazmat: sure do [23:47] bcsaller, ~hazmat/ensemble/local-unit-deploy is the latest in the pipeline [23:47] hazmat: thanks [23:59] jimbaker`: lbox propose --for lp:ensemble/ftests [23:59] Sorry, single dash [23:59] jimbaker`: lbox propose -for lp:ensemble/ftests