[00:06] <jimbaker> niemeyer, any preferences in terms of python tools for writing html? cheetah?
[00:09] <niemeyer> jimbaker: I would prefer something very simple
[00:09] <jimbaker> niemeyer, exactly. so please tell me what you prefer, and i will use it :)
[00:09] <niemeyer> jimbaker: If possible a single Python file we can embed in the project itself
[00:10] <niemeyer> jimbaker: Since our needs are pretty trivial.. just iterating over a list building a table with OK/FAILED + links
[00:11] <niemeyer> jimbaker: Do you know anything like that?
[00:12] <niemeyer> I'll get some food, biab
[00:12] <jimbaker> 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] <SpamapS> OK/FAILED links? isn't that what jenkins does?
[00:16] <jimbaker> 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] <jimbaker> SpamapS, correct, we are re-implementing what jenkins does
[00:16] <jimbaker> SpamapS, regardless this is the task i have
[00:16] <SpamapS> eh?
[00:17] <jimbaker> for our functional testing
[00:19] <SpamapS> Right, subunit doesn't have something ?
[00:19] <SpamapS> I mean, jenkins is like, the industry standard.
[00:19] <SpamapS> And we have a.. really kick ass jenkins formula. :)
[00:19] <jimbaker> SpamapS, agreed that jenkins is the industry standard
[00:20] <SpamapS> https://wiki.jenkins-ci.org/display/JENKINS/NUnit+Plugin
[00:20] <SpamapS> I was kind of hoping we'd get to a point where we were graphing all that lovely test coverage
[00:21] <jimbaker> 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] <SpamapS> aww snap
[00:22] <jimbaker> SpamapS, this is actually a good thing. trial is pretty wretched for long running functional tests
[00:22] <jimbaker> 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] <SpamapS> 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] <jimbaker> SpamapS, however, it might make sense to output junitxml instead. perhaps that could be considered at a later time.
[00:23] <SpamapS> A new test runner that runs shell scripts?
[00:23] <SpamapS> Thats also what jenkins does. :)
[00:24] <SpamapS> Tho its not much of a tool for developers to run in an iterative sense..
[00:24] <SpamapS> I didn't think the functional tests would be somethign you'd do in that manner.
[00:24] <SpamapS> Figured you'd just set jenkins jobs up to point at in progress branches and trunk and run tests on commit
[00:25] <jimbaker> SpamapS, that makes a lot of sense to do. again the test runner could readily output junitxml
[00:26] <jimbaker> SpamapS, the more important thing is that we want functional tests directly exercising ensemble commands
[00:27] <SpamapS> Hey, me too. :)
[00:27] <SpamapS> On all supported configurations
[00:28] <SpamapS> (that last bit is integration testing.. but .. details.. ;)
[00:28] <jimbaker> SpamapS, cool. so consider this as an intermediate step
[00:28] <jimbaker> trust me, it will be very easy to have this integrated into jenkins in some subsequent step
[00:29] <SpamapS> 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] <SpamapS> On the tests..
[00:29] <SpamapS> 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] <SpamapS> we should have a pow-wow once you've got the test runner doing some stuff.
[00:32] <jimbaker> SpamapS, sounds like a plan. i definitely want to hear more about james' ideas
[00:34] <jimbaker> SpamapS, we could readily add your bash scripts
[00:35] <SpamapS> 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] <jimbaker> 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] <jimbaker> 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] <jimbaker> 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] <jimbaker> (it might also be a useful ensemble subcommand in the future, don't know)
[00:43] <SpamapS> Not sure what you mean
[00:43] <SpamapS> I wrote a wait4state perl script that just runs status
[00:43] <niemeyer> jimbaker: This looks nice: https://github.com/defunkt/pystache
[00:45] <SpamapS> but /win 10
[00:45] <SpamapS> doh
[00:45] <jimbaker> niemeyer, looks good to me, thanks!
[00:46] <jimbaker> SpamapS, but /win...  ?
[00:46] <SpamapS> irssi
[00:46] <SpamapS> hey quick python question
[00:46] <SpamapS> do lists keep an internal length?
[00:46] <niemeyer> jimbaker: It's an incarnation of this: http://mustache.github.com/
[00:47] <SpamapS> 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] <niemeyer> SpamapS: They do
[00:47] <niemeyer> SpamapS: Are you doing tons of those calls?
[00:47] <SpamapS> yes
[00:48] <niemeyer> SpamapS: function calls in Python are expensive in general.. you may just be seeing that cost
[00:48] <jimbaker> niemeyer, yeah, mustache is a fine approach
[00:48] <SpamapS> 5 for every line of a 500,000 line file....
[00:48] <SpamapS> So I'm not crazy.. its not a massive expense per call.. but it adds up
[00:48] <jimbaker> SpamapS, doesn't seem to be so much even for cpython
[00:48] <niemeyer> SpamapS: Yeah, definitely.. you'd notice 2.5M Python function calls for sure
[00:49] <SpamapS> http://paste.ubuntu.com/680217/
[00:49] <jimbaker> so there, we have two contrasting viewpoints
[00:49] <SpamapS> now to find out where the other 8.8s are spent. :-P
[00:50] <niemeyer> jimbaker: You mean you don't find them expensive?
[00:51] <jimbaker> niemeyer, i just don't think it's that bad if it's just 2.5M
[00:52] <niemeyer> jimbaker:
[00:52] <jimbaker> niemeyer, functional call overhead in cpython is obviously quite expensive, for a variety of reasons
[00:52] <niemeyer> def f(): pass
[00:52] <niemeyer> start = time()
[00:52] <niemeyer> for i in range(2500000): f()
[00:52] <niemeyer> print time()-start
[00:52] <niemeyer> jimbaker: This takes 1 second in my machine
[00:52] <niemeyer> jimbaker: Doing absolutely nothing
[00:52] <niemeyer> jimbaker: There's more than a function call there, but gives an idea
[00:52] <jimbaker> niemeyer, i'm sure that's the case :)
[00:53] <niemeyer> jimbaker: That's what I meant by "you'd notice"
[00:53] <jimbaker> 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] <jimbaker> but if run in a command, or in the direct path for rendering a page, sure, it's extremely noticeable
[00:54] <SpamapS> That, and things like .append, .sort, etc, are the only function calls..
[00:54] <SpamapS> this script lags the same algorithm in perl by about 15%
[00:54] <SpamapS> I was wrong btw, it doesn't do 5 for every line
[00:54] <SpamapS> just 1 len for every line
[00:55] <SpamapS> but yeah, 500,000 is 0.504s
[00:55] <jimbaker> SpamapS, did you try it w/ pypy? that would be an interesting exercise
[00:55] <SpamapS> jimbaker: I wanted to but didn't know how to even get pypy ;)
[00:55] <jimbaker> functional call overhead w/ pypy is extremely reduced
[00:55] <niemeyer> Yeah, should kick ass
[00:56] <SpamapS> lol.. lucid, karmic, and jaunty.. :-P
[00:56] <jimbaker> http://pypy.org/download.html - just give it a try, i don't know where they are on latency
[00:56] <niemeyer> Takes 16ms in Go..
[00:56] <niemeyer> The 2.5
[00:57] <jimbaker> 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] <jimbaker> (i too should give it a try ;) )
[00:58] <niemeyer> Maybe.. haven't tried that kind of thing there yet.. would be curious, though
[00:58] <niemeyer> Given their latest work it must be pretty amazing
[01:01] <jimbaker> bbl
[01:01] <SpamapS> pretty hard to find pypy binaries.. :-P
[01:54] <_mup_> Bug #838568 was filed: push-review must be tested again <Ensemble:In Progress by niemeyer> < https://launchpad.net/bugs/838568 >
[13:57] <niemeyer> Alow!
[14:16] <hazmat> 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] <jimbaker`> hazmat, jinja2 is fine. but let's go with mustache
[15:01] <hazmat> jimbaker`, wasn't clear that mustache has any advantage over say.. string.Template
[15:05] <hazmat> er.. actually string formatters
[15:06] <hazmat> mustache looks fine though
[15:08] <jimbaker`> hazmat, mustache does one very important thing, which is that it performs html encoding
[15:09] <jimbaker`> when compared to string.Template. obviously the mustache {{}} itself is familiar in both templating systems
[15:10] <niemeyer> jimbaker`: and loops, I guess
[15:53] <niemeyer> Lunch time.. biab!
[16:14] <SpamapS> niemeyer: can we get push-review from a PPA or something?
[16:14] <SpamapS> 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 <Ensemble:New> < https://launchpad.net/bugs/839695 >
[16:27] <SpamapS> hazmat: re the bug linked above..
[16:28] <SpamapS> 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] <SpamapS> but I could be wrong
[16:29] <SpamapS> indeed.. its just a matter of how you checked out the branch
[16:33] <SpamapS> 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] <hazmat> SpamapS, sounds good
[16:45] <SpamapS> hazmat: http://pastebin.com/DaaJ1Mp0
[16:46] <SpamapS> 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] <SpamapS> (with the 3 patches I've submitted for review applied.. ;)
[16:55] <niemeyer> SpamapS: Absolutely! Working on that already.. should be apt-gettable today
[18:16] <jcastro> hey m_3 
[18:16] <jcastro> 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! <Ensemble:In Progress by niemeyer> < https://launchpad.net/bugs/839794 >
[18:17] <jcastro> would now be a good time to ask how the node standalone formula is coming along?
[18:45] <jimbaker`> 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] <m_3> jcastro: hey
[18:47] <m_3> jcastro: yeah, the node formula was part of a talk I gave on IRC a few weeks ago
[18:47] <m_3> jcastro: I'll brush it off, promote it to principia, and blog about it
[18:47] <jcastro> m_3: do you have time to post a response to the guy? 
[18:47] <jcastro> it reads to me like he needs ensemble hard core
[18:49] <m_3> jcastro: yeah, I'll do it during a boring talk this afternoon
[18:49] <jcastro> oh sorry, forgot you were travelling
[18:50] <m_3> jcastro: conf wraps up today, so I'll be able to put time on it over the weekend
[19:51] <negronjl> jcastro: ping
[19:55] <jcastro> negronjl: pong
[19:56] <negronjl> 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] <hazmat> SpamapS, does upstart do env expansion  on the exec stanza?
[21:11] <SpamapS> hazmat: yes
[21:24] <niemeyer> Okay.. lpad is out, lbox is out.. back to reviews and porting formulas 
[21:25] <niemeyer> 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] <hazmat> excellent idea
[21:49] <SpamapS> hazmat: upstart for containers, but not for the agents?!
[21:51] <hazmat> SpamapS, for the agent
[21:51] <hazmat> unit agent only
[21:51] <hazmat> inside a container
[21:52] <hazmat> its not truly restartable.. probably shouldnt' be respawn auto
[21:52]  * hazmat returns with a bloody mary
[21:53] <hazmat> 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] <SpamapS> task tsk.. we need our idempotency. :)
[21:53] <SpamapS> :)
[21:53]  * hazmat reruns tests to ascertain potency
[21:56] <SpamapS> oh I thought you were saying that its not re-startable because of some problem with idempotency
[22:09] <hazmat> 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] <SpamapS> err.. events?
[22:10] <hazmat> no good reason not to go ahead with it i suppose
[22:10] <SpamapS> I thought we just watched to see what the state was
[22:10] <SpamapS> if we miss 4 changes, who cares, just make the new state true.
[22:10] <hazmat> SpamapS, if the agent is down, watches won't be delivered
[22:11] <hazmat> and extant watches need to be restablished as new watches potentially
[22:11] <SpamapS> if we need that, we need a queue, not a data store
[22:11] <SpamapS> But I see what you're saying
[22:12] <hazmat> 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] <SpamapS> 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] <SpamapS> Thats not a queue.. thats a watched data store.
[22:12] <hazmat> yup
[22:12] <SpamapS> Convenient, yes, but not a queue. :)
[22:12] <hazmat> its really a sync between a remote and local data store
[22:12] <hazmat> to compute the delta
[22:13] <SpamapS> I see the problem.. very interesting
[22:13] <hazmat> in truth its probably a very rare issue in practice for a respawn
[22:13] <hazmat> for a net split its more significant
[22:13] <hazmat> or any long running outage
[22:13] <SpamapS> yeah, so at the moment, ensemble is not partition tolerant. ;)
[22:16]  * SpamapS disappears
[22:16] <hazmat> SpamapS, have a good weekend
[22:55] <jimbaker`> 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] <jimbaker`> 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] <hazmat> jimbaker`, i think you just push to ~jimbaker/ensemble/generate-html
[23:10] <hazmat> its on the merge side you pick the series branch afaik
[23:10]  * hazmat checks
[23:10] <jimbaker`> hazmat, ok, i was wondering why it was wanting to use the wrong series
[23:10] <hazmat> yup
[23:11] <hazmat> jimbaker`, so on merge the target branch is ensemble/ftests
[23:11] <hazmat> there all branches of the same project for the user project namespace
[23:11] <hazmat> s/their
[23:15] <_mup_> Bug #839969 was filed: Checkout Ensemble branch, run bash ftests, and generate summary in HTML <Ensemble:In Progress by jimbaker> < https://launchpad.net/bugs/839969 >
[23:18] <hazmat> jimbaker`, is the ftest stuff using jenkins for test running?
[23:18] <jimbaker`> hazmat, no
[23:18] <hazmat> just wondering if we could submit tests for branches in dev
[23:18] <hazmat> via an api
[23:19] <hazmat> w/ the security integration tests get about 30% slower out of the box on average...
[23:19] <jimbaker`> 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] <hazmat> jimbaker`, i guess i'm confused what's running the tests? your not using jenkins or buildbot?
[23:21] <jimbaker`> i'm using two new tools: butler.py, which i just wrote; and niemeyer's churn, which executes bash scripts
[23:21] <jimbaker`> a butler used to manage the buttery, which might store the results of the churning...
[23:22] <jimbaker`> and of course jenkins is presumably a butler. whatever ;)
[23:22] <hazmat> not sure i understand why.. but okay
[23:22] <jimbaker`> hazmat, at some point jenkins is presumed. twisted trial however is definitely not going to be used
[23:23] <jimbaker`> the reason is that we need something that is focused on running ensemble commands
[23:23] <hazmat> jimbaker`, i assume the test runner would be doing normal tests and ftests
[23:23] <hazmat> is that not accurate?
[23:23] <jimbaker`> that's not accurate
[23:23] <jimbaker`> it's only running ftests, which are to be only be written using bash
[23:24] <jimbaker`> that's niemeyer's decision, and it makes sense
[23:24] <hazmat> from a purpose of ease of test dev for users probably
[23:24] <jimbaker`> such test scripts could potentially use resources that are written in python, eg to validate results or to wait for resources
[23:25] <hazmat> still i seems like conflating issues, an ftest suite and test suite, and the test bot 
[23:26] <jimbaker`> 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] <hazmat> jimbaker`, fair enough.. we need a test runner for the ftests that does reports
[23:27] <jimbaker`> and that's the merge proposal :)
[23:32] <hazmat> bcsaller, do you have a moment to catch up?
[23:33] <bcsaller> hazmat: sure do
[23:47] <hazmat> bcsaller, ~hazmat/ensemble/local-unit-deploy is the latest in the pipeline
[23:47] <bcsaller> hazmat: thanks
[23:59] <niemeyer> jimbaker`: lbox propose --for lp:ensemble/ftests
[23:59] <niemeyer> Sorry, single dash
[23:59] <niemeyer> jimbaker`: lbox propose -for lp:ensemble/ftests