[00:32] <_mup_> ensemble/robust-hook-exit r288 committed by jim.baker@canonical.com
[00:32] <_mup_> Comments and better MATCH for mocking
[00:37] <_mup_> ensemble/robust-hook-exit r289 committed by jim.baker@canonical.com
[00:37] <_mup_> PEP8 and better test name
[00:45] <jimbaker> adam_g, did the robust-hook-exit branch work for you?
[00:45] <jimbaker> in any event, i have pushed up a version of this branch that i'm going to now submit for review, now that it has comprehensive testing
[00:46] <jimbaker> (unless of course it doesn't actually work ;) )
[00:47] <jimbaker> adam_g, i did find one bug in the reaping mechanism, but i suspect it would not have actually impacted your use, just a resource exhaustion problem for long-term running in the machine agent
[00:47] <jimbaker> and again fixed in this most recent push
[01:17] <adam_g> jimbaker: sorry. yes, i did test it on friday and it worked just fine. 
[01:33] <jimbaker> adam_g, cool. if you could please try the latest version of the branch, which i just pushed for review, that would be very helpful
[01:34] <jimbaker> i believe in a nutshell we can model such bad hooks as something like this: sleep 0.05 && echo "Slept for 50ms" && sleep 1 && echo "Slept for 1s" && sleep 1000000 &
[01:35] <jimbaker> the & at the end be the operative part to fork, but not to close file descriptors in the child
[05:23] <SpamapS> hmm.. toying with a Venn diagram explaining why service orchestration is not config management, but encompasses some of it..
[05:23] <SpamapS> http://spamaps.org/files/venn-config-service.png
[05:24] <SpamapS> The suggestion there is that the blue stuff on the right is what is being bolted on to config management..
[05:30] <adam_g> SpamapS: what do you mean 'bolted on'?
[05:41] <SpamapS> adam_g: meaning they're being added as afterthoughts.
[05:42] <SpamapS> adam_g: I don't even think, actually, that any of the free cfg mgmt solutions have a built in coordination method.. they just fake it by running themselves over and over.
[05:42] <SpamapS> adam_g: and the elasticity comes from that paradigm too
[05:44] <adam_g> SpamapS: i dont know about chef, but the way puppet traditionally worked was, you install a central puppet master that hosts the configuration, and an agent sleeps on client machines, awakens at interval and to see if they need updates
[05:45] <adam_g> err, checks in to see..
[05:45] <SpamapS> Right, and there's no telling who will see the changes first unless you force a run, right?
[05:45] <adam_g> right
[05:45] <adam_g> well
[05:45] <adam_g> using mcollective, now, though
[05:45] <adam_g> you essentially "turn off" puppet on the clients
[05:45] <SpamapS> right, that new bolt on that is, IMO, a healthy competitor to ensemble. :)
[05:46] <adam_g> and dispatch puppet runs via mcollective, which is running on the clients
[05:46] <SpamapS> because a lot of the time you need to upgrade clients first, then update the server to use some new feature..
[05:47] <adam_g> zright
[05:47] <SpamapS> I've felt for a while that puppet is nothing like Ensemble, and mcollective is a little like ensemble. :P
[05:47] <adam_g> what puppet realy lacks IMHO is coordination between systems, especially for encforcing ordering dependencies with regards to state changes
[05:47]  * adam_g agrees 100% 
[05:47] <adam_g> :)
[05:48] <SpamapS> Ensemble ends up having that by the nature of doing things in a service oriented fashion.. but the upgrade-formula hook is, IMO, a bit weak for ongoing coordination.
[05:49] <SpamapS> I really need to be able to enumerate and act on relations in upgrade-formula.. so I can wake up the related pairs and tell them about any new necessary info.
[05:50] <SpamapS> This is where mcollective's simpler approach wins out.. because all it has to do is dispatch puppet.
[06:49] <_mup_> Bug #816264 was filed: PYTHONPATH causing corrupt environment <Ensemble:New> < https://launchpad.net/bugs/816264 >
[10:56] <kim0> oh we now have config-set \o/ yaay
[11:28] <fwereade> hey all
[11:28] <fwereade> is there a way to give a merge proposal more than one prerequisite branch?
[11:35] <hazmat> fwereade, no..
[11:35] <fwereade> hazmat: does that imply I'm Doing It Wrong? ;)
[11:35] <hazmat> fwereade, logically no.. typically i use a straight line of deps for merges.. but that's tool limitation imo.
[11:36] <fwereade> hazmat: I resisted the urge to just keep everything in one straight line
[11:36] <fwereade> hazmat: the thing that's bugging me is it's only going to get worse
[11:36] <hazmat> fwereade, :-)  bzr-pipeline is a nice bzr plugin that can automate some of the tedium of managing a straight-line of dependent branches
[11:37] <fwereade> hazmat: the next thing I want to do wants to build on the results of 2 independent pipelines
[11:37] <fwereade> hazmat: mreging trunk updates through the whole pipeline and suchlike?
[11:37] <hazmat> fwereade, i'm using it for the security work right now, which is like 7 branches atm, pipeline helps me automate pushing changes through, as well keeping a single checkout workspace for the work on all the branches 
[11:37] <hazmat> fwereade, yup
[11:37] <fwereade> hazmat: cool, I'll check it out
[11:38] <fwereade> hazmat: can I retrofit it onto an existing pipeline or does it need to remember its own state?
[11:39] <fwereade> hazmat: actually, now I think of it, I can suspend work on that feature and go back to the last one I suspended because it was breaking my brain (I think my brain has recovered a bit now ;))
[11:39] <hazmat> fwereade, you can retrofit an existing *branch* with just bzr reconfigure-pipeline, you can retrofit an existing pipeline but its effectively just adding a new branch and merging the existing branch to it..
[11:40] <hazmat> i also appreciate the single workspace model for working with multiple branches
[11:40] <fwereade> heh, I think I'd go even more insane without separate workspaces
[11:41]  * hazmat looks around for pre-review coffee
[11:48] <hazmat> fwereade, out of curiosity what editor do you favor?
[11:49] <fwereade> hazmat: vim
[11:49] <fwereade> hazmat: and yourself?
[11:49] <hazmat> fwereade, right on.. i'm an emacs guy.. i believe we now have achieved 50/50 parity on the dev team ;-)
[11:49] <fwereade> hazmat: haha, nice
[11:50] <fwereade> hazmat: I had a bad early impression of emacs... a colleague used it and we seemed to spend about 50% of our pairing time fiddling with the settings
[11:51] <fwereade> hazmat: not really a fair test ofc ;)
[11:52] <hazmat> fwereade, yeah.. i think i try to keep my settings fiddling to once a year... i know incredibly little about mucking with emacs actually.
[11:53] <fwereade> hazmat: the bad early impression of vim came from trying to type in command mode, ofc... that was exciting, but at least it wastes minimal time
[11:58] <hazmat> fwereade, yeah.. my first vim experience was modifying some oracle setup on an ancient solaris, i ended up tracking down a sysadmin for a cheat sheet... i'm not sure that i ever fully recovered ;-)
[11:59] <hazmat> although i've grown to like solaris since
[11:59] <fwereade> hazmat: heh
[12:00] <fwereade> hazmat: I think having someone who knows the tool to hold your hand is probably the critical factor
[12:16] <niemeyer> GOod mornings!
[12:25] <niemeyer> What a beautiful review queue
[12:28] <fwereade> niemeyer: heh :)
[12:28] <fwereade> niemeyer: good morning
[12:29] <niemeyer> fwereade: No irony.. it's awesome to come back to a review queue like that.. it'd be better to not have it because everything was already merged, but it's much more pleasant than coming back to nothing
[12:33] <fwereade> niemeyer: cool :)
[12:35] <Aram> moin.
[12:35] <Aram> heh, editor discussions.
[12:35] <niemeyer> Hey Aram!
[12:36] <Aram> anyone else using acme or sam? :-).
[12:36] <Aram> hi!
[12:36] <niemeyer> Aram: Was just checking out your PDP11 emulator.. crazy stuff :-)
[12:37] <niemeyer> Aram: I think you'll find mostly emacs/vim users around here
[12:38] <Aram> yeah, I imagine :-).
[12:39] <Aram> I actually read all the PDP-11/40 manual and really liked it. very concise and sane compared to 4833 pages of intel manual.
[12:45] <niemeyer> Aram: How are the Intel manuals when compared to ARM's?
[12:46] <Aram> never read the ARM manuals. I assume they are at least smaller, as ARM is a very small arch and doesn't have 30+ years of legacy cruft.
[12:49] <niemeyer> Aram: Yeah, they feel quite pleasant overall
[12:49] <niemeyer> Aram: I know ARM itself (not the SOC makers) actually sells exactly that kind of thing, so it's somewhat expected that they'd do a good job on it
[12:49] <niemeyer> Aram: I'm curious if Intel had similar material
[12:50] <Aram> I would add ARM support in my emulator at some point to test the power of Go inferred interfaces.
[12:50] <Aram> yeah, Intel has tons of material. very very very very detailed.
[12:50] <Aram> also, guides for kernel developers and compiler writers.
[12:50] <Aram> guides for optimizing etc.
[12:50] <Aram> the only problem is that x86 itself is insane.
[12:51] <Aram> the manuals are good. very sterile, but good.
[12:51] <Aram> (though I like the docs coming from AMD more).
[12:51] <niemeyer> Aram: Nice/not nice :)
[12:52] <niemeyer> Aram: I note you don't have many tests on the emulator yet (hint!)
[12:53] <Aram> yeah... that's true.
[12:53] <Aram> I'm reading about the Go test framework now.
[12:54] <niemeyer> Aram: It's quite neat, even if a bit slim to my taste
[12:54] <niemeyer> Aram: I came up with a slightly more comprehensive version when I started playing with it, following more well-known xunit styles (http://labix.org/gocheck)
[12:55] <niemeyer> Aram: It builds on the standard one, though, rather than replacing it entirely
[12:55] <Aram> aha, nice. I'll take a look into it.
[13:10] <wrtp> Aram: i use acme
[13:11] <Aram> :-).
[13:11] <wrtp> smiley face every time i use it indeed :-)
[13:14] <hazmat> niemeyer, g'morning! re review queue, it looks like  kanban generation has gone stale again
[13:14] <niemeyer> hazmat: Hmm, indeede
[13:15] <wrtp> PS hi gustavo!
[13:17] <niemeyer> wrtp: Rog!
[13:17] <niemeyer> wrtp: How're things going there?
[13:19] <wrtp> niemeyer: pretty good thanks; just hacking up a website for our wedding guests and realising how terrible i am at html/css...
[13:19] <wrtp> so many rules, so little clarity :-(
[13:20] <wrtp> still, it's fun doing it in Go
[13:21] <niemeyer> wrtp: Hah, yeah.. coming back to HTML is always tricky after getting used to the level of cleanliness/power of  a CLI
[13:22] <wrtp> niemeyer: more like the first time. CSS didn't exist the last time i wrote a web site :-)
[13:23] <wrtp> and some people [ahem, looks over shoulder] don't like the "vanilla" look...
[13:25] <niemeyer> wrtp: Wow, ok, that's been a _while_ :-)
[13:25] <wrtp> yeah, probably coming up for 15 years :-)
[14:20] <niemeyer> Kanban is unblocked
[14:22] <niemeyer> jimbaker: ping
[14:22] <niemeyer> fwereade: ping
[14:26]  * hazmat checks out the new golang course
[14:28] <jcastro> robbiew: ok I am relocated and back 100% now. Went over the slides with bacon and he gave me some stuff to fix.
[14:28] <robbiew> cool
[14:34] <fwereade> niemeyer: heyhey
[14:35] <niemeyer> fwereade: yo
[14:35] <niemeyer> fwereade: Would you mind to review this branch: https://code.launchpad.net/~jimbaker/ensemble/expose-provider-ec2/+merge/68478
[14:35] <fwereade> niemeyer: a pleasure :)
[14:35] <niemeyer> fwereade: This is touching the EC2 provider API, so might be nice to have your view on it since you've been so close to it
[14:35] <niemeyer> fwereade: Thanks!
[14:39] <_mup_> ensemble/security-agents-with-identity r297 committed by kapil.thangavelu@canonical.com
[14:39] <_mup_> hierarchy initialization includes otp container.
[14:40] <jcastro> any sexy new formulas that people are tackling this week? (already got cloud foundry)
[14:42] <jimbaker> niemeyer, hi
[14:42] <jimbaker> fwereade, thanks for looking at the expose-provider-ec2
[14:43] <fwereade> jimbaker: np at all
[14:43] <fwereade> jimbaker: I'm happy to see the ugliest code in ec2 is gone now :)
[14:44] <jimbaker> fwereade, you mean the use of all of those callbacks + authz?
[14:44] <fwereade> jimbaker: I think we're talking about the same thing, yeah
[14:45] <fwereade> jimbaker: for some reason it really stuck out ;)
[14:45] <jimbaker> fwereade, i couldn't really read that code, so i just had to refactor it first. it does feel cleaner
[14:48] <niemeyer> jimbaker: Hello
[14:48] <jimbaker> niemeyer, hi
[14:48] <niemeyer> jimbaker: I have one feedback on this too
[14:49] <jimbaker> niemeyer, ?
[14:49] <niemeyer> jimbaker: It doesn't feel like there's a reason to be using classes and inheritance there
[14:50] <jimbaker> niemeyer, you mean the use of EC2PortOperation for get_machine_group_name?
[14:51] <niemeyer> jimbaker: Yeah, and also the classes themselves
[14:51] <niemeyer> jimbaker: Foo(x).do_bar() can easily be do_bar()
[14:52] <jimbaker> niemeyer, oh sure, that's just following the existing convention. but i agree about it being unnecessary. if i were to do it again, i would not group it this way for the provider ops as a whole
[14:52] <niemeyer> jimbaker: Conventions are nice until they are not
[14:53] <jimbaker> niemeyer, absolutely
[14:53] <niemeyer> jimbaker: I think this should be fixed.. let's not grow up classes which are really just functions
[14:53] <jimbaker> niemeyer, so in my case, i'm reading through this operations (hey! command pattern. or something like that) trying to think, what the heck is the reason for them
[14:53] <jimbaker> because generally in python if we have classes they mean something
[14:54] <jimbaker> but in this case, even the fact that some params go in __init__, others in run, made no sense
[14:54] <niemeyer> jimbaker: Overengineering in some cases, caused by us trying to figure a good way to organize code there
[14:54] <niemeyer> jimbaker: Would you mind to reorganize it as functions and see how it goes?
[14:54] <jimbaker> so it was definitely unhelpful noise because it made it harder to start working with the code
[14:55] <jimbaker> niemeyer, sounds good, i can definitely pilot what it could look like
[14:55] <jimbaker> niemeyer, in general i think the way it's done in the dummy provider is nicer
[14:55] <smoser> niemeyer, its not in go, but https://gist.github.com/1100458 is a "get the right ubuntu ami" tool
[14:56] <jimbaker> the other thing that i found annoying was the use of __init__.py when we don't use that convention elsewhere in the code
[14:57] <niemeyer> smoser: Hah, sweet!
[14:57] <niemeyer> smoser: I'll dump that in my bin and start playing with it
[14:57] <niemeyer> smoser: any chance of an entry in the contest for that? ;-)
[14:57] <smoser> maybe
[14:58] <smoser> is there an sh2go converter ;-)
[14:58] <smoser> or maybe i'll just write that instead
[15:04] <ahasenack> smoser: it's in awk, you mean, not shell
[15:04] <ahasenack> ;)
[15:05] <smoser> well, yeah, sh2go would have to include implementations of sed and awk and cat and perl and wget....
[15:05] <smoser> i leave that as an exercise to you
[15:06] <fwereade> jimbaker: I'm a bit confused about the machine_id thing: I understand we can't use the instance ID, but is there really no way to figure out the machine ID giver a ProviderMachine?
[15:06] <fwereade> given a ^^^
[15:07] <jimbaker> fwereade, perhaps the better api would be to have the ProviderMachine know its logical machine id
[15:08] <fwereade> fwereade: I would personally strongly favour that, but not enough to actually disapprove of the branch ;)
[15:08] <fwereade> er, I have no idea where I got this habit of talking to myself :/
[15:09] <jimbaker> fwereade, it looks like i'm going to do more refactoring anyway in light of the conversation i just had w/ niemeyer 
[15:09] <fwereade> jimbaker: I saw that
[15:09] <jimbaker> it would definitely clean things up, so that's a good thing
[15:10] <fwereade> jimbaker: I'm not sure the scope we're talking about though
[15:10] <jimbaker> fwereade, i don't believe the scope is very much at all, fortunately
[15:11] <fwereade> jimbaker: cool, as long as we're not planning to change every single operation from a class to a function
[15:11] <fwereade> because that feels a bit drastic to me
[15:11] <jimbaker> fwereade, i'm not going to do a general refactoring of the code, but a small one to try out just using functions for the securitygroup instead of java-like commands
[15:11] <fwereade> jimbaker: cool
[15:12] <jimbaker> fwereade, if that looks good, the next step is to have a refactoring branch that can apply it to the rest of the code in ec2 provider
[15:12] <fwereade> jimbaker: sounds good to me
[15:13] <jimbaker> fwereade, maybe that branch can remove having both MachineProvider and ProviderMachine ;)
[15:14] <fwereade> jimbaker: <3, that gives me a headache
[15:14] <jimbaker> fwereade, indeed. i know why that came about, but it must die ;)
[15:15] <fwereade> jimbaker: anyway, I'l like the machine_id thing to go, but it feels separate to me -- we'll need some independent code to make machine_id gettable given a machine
[15:15] <fwereade> jimbaker: so I don't think it's a reason to disapprove
[15:16] <fwereade> jimbaker: but I'm not sure how to track my concern -- just file another bug, and point out that it dirties up the port interface?
[15:17] <jimbaker> fwereade, i think in general we would use "approve" for a branch at this point if the remaining changes are obvious and agreed upon. but it probably is best to just say "needs fixing"
[15:17] <fwereade> jimbaker: cool, thanks
[15:17] <jimbaker> fwereade, so no more bug, just point it out in the review
[15:26] <RoAkSoAx> fwereade: i.
[15:26] <RoAkSoAx> fwereade: o/
[15:32] <fwereade> RoAkSoAx: er, what?
[15:32] <RoAkSoAx> fwereade: was just saying hi (o/)
[15:32] <fwereade> RoAkSoAx: heyhey :)
[15:33] <RoAkSoAx> fwereade: heh how's it going
[15:33] <fwereade> RoAkSoAx: I ought to recognise translated gestures ;)
[15:33] <fwereade> RoAkSoAx: not too shabby; yourself?
[15:34] <RoAkSoAx> fwereade: good good
[15:34] <RoAkSoAx> fwereade: bug squashing day for me
[15:35] <RoAkSoAx> fwereade: any updates on the key related stuff?
[15:38] <fwereade_> RoAkSoAx: hey again :)
[15:38] <RoAkSoAx> fwereade_: hehe troubles with xchat?
[15:39] <fwereade_> RoAkSoAx: yeah, today seems to be a stuff-breaking-randomly day
[15:39] <fwereade_> RoAkSoAx: seem to have VMs actually installing though which is reassuring
[15:41] <RoAkSoAx> fwereade_: yeah either installer or mirror/proxy issue
[15:42] <RoAkSoAx> fwereade_: any luck on the key thingy?
[15:42] <fwereade_> RoAkSoAx: niemeyer explained how config stuff gets to other machines, if I think a mo I might find it again ;)
[15:43] <RoAkSoAx> fwereade_: cool
[15:44] <RoAkSoAx> fwereade_: no I think that by the time of the sprint, we should have everything merged in trunk, or, at least have a common branch
[15:44] <fwereade_> RoAkSoAx: yep, at least there's a way we can do it ;)
[15:47] <RoAkSoAx> fwereade_: cool, let's coordinate that tomorrow as today I'll be working on unrelated stuff
[15:59]  * hazmat heads out to lunch
[15:59] <kim0> TeTeT: glad to see you o/ :)
[15:59] <SpamapS> m_3: hey, how's that NFS formula looking?
[15:59] <TeTeT> kim0: the class starts in one hour, right?
[16:00] <kim0> TeTeT: yes
[16:00] <kim0> thanks man
[16:00] <SpamapS> RoAkSoAx: hey, how did the cloud days presentation go? I missed it.
[16:00] <RoAkSoAx> SpamapS: i think it went well
[16:00] <kim0> m_3: please ping me when u're back :)
[16:01] <RoAkSoAx> SpamapS: we couldn't demo anything as there were installation/installer issues
[16:01] <SpamapS> RoAkSoAx: thats pretty understandable given the number of moving parts involved in bare metal deployment.
[16:02] <RoAkSoAx> SpamapS: indeed
[16:05] <adam_g> jimbaker: i used your branch pretty extensively last night while working on some formulas, works well!
[16:05] <jimbaker> adam_g, glad to hear that!
[16:09] <niemeyer> Lunch time here
[16:09] <niemeyer> Back for more reviews in a moment
[16:25] <SpamapS> Hrm.. so I am running into an interesting situation that I think we need an answer to.
[16:26] <SpamapS> Basically, I have a service config that affects the relationships a service has. I want to be able to set the database that a service uses.
[16:27] <SpamapS> adam_g: did you see that service configs have landed?
[16:29] <adam_g> SpamapS: i haven't but thats cool, show me how to use it over beer :)
[16:30] <SpamapS> adam_g: Indeed. :) It should let you get rid of any hard codes you have in the openstack stuff
[16:30] <SpamapS> adam_g: can I say that there are formulas for openstack in my talk?
[16:33] <adam_g> SpamapS: cool, maintaining that has bitten me a bunch 
[16:33] <adam_g> SpamapS: yah, definitely! i wanted to actually "release" those formulas out o fmy +junk branches but a bunch of openstack bugs were introduced last week that broke everything
[16:33]  * SpamapS is almost done w/ slides.. just need to add a few more lolcatz
[16:33] <SpamapS> adam_g: son of a! ;)
[16:51] <SpamapS> hrmph.. 13 slides.. 40 minute presentation. I don't know if 3 minutes per slide is a good average
[16:51] <m_3> SpamapS: sorry, been head-down on a stack for ubuntu-classroom
[16:52] <SpamapS> m_3: no worries. :)
[16:53] <m_3> ec2 picks now to be dog-slow
[17:02] <kim0> m_3: if that demo is broken, feel free to replace with any formula that works :)
[17:03] <m_3> kim0: thanks
[17:03] <m_3> kim0: still testing
[17:03] <kim0> rock n roll
[17:03] <m_3> kim0: you know how to get the screen bigger in byobu classroom?
[17:03] <m_3> kim0: it's maxing out at half the screen
[17:04] <kirkland> m_3: the host session needs to be a bigger terminal
[17:04] <kirkland> m_3: resize the terminal running the host session, and press F5 in byobu
[17:04] <m_3> kim0: perfect... thanks!
[17:08] <SpamapS> m_3: are you practicing or is this going now?
[17:08] <m_3> kim0: scratch that
[17:08] <m_3> kirkland: perfect... thanks!
[17:08] <m_3> SpamapS: at 1800UTC
[17:09] <m_3> think I'll just set up the stack and talk about it rather than wait for it
[17:10] <kirkland> m_3: which reminds me, i need to test your updates to byobu-classroom and propose it for principia
[17:10] <kirkland> m_3: i'll try to do that today
[17:11] <SpamapS> kirkland: you're a composer, just push :)
[17:11] <m_3> kirkland: simple update... oneliner
[17:11] <kirkland> SpamapS: k
[17:11] <kirkland> m_3: kewl, just want to retest
[17:22] <fwereade_> must dash, later all
[17:40] <SpamapS> http://spamaps.org/files/ensemble-oscon-2011.odp
[17:40] <SpamapS> Note that it doesn't make much sense w/o the notes
[17:42] <niemeyer> SpamapS: Is it done, or is it to-do?
[17:42] <SpamapS> niemeyer: Thursday afternoon.
[17:42] <SpamapS> to-do
[17:43] <SpamapS> http://www.oscon.com/oscon2011/public/schedule/detail/18367
[17:43] <niemeyer> SpamapS: Awesome!
[17:43] <niemeyer> SpamapS: Re. config vs. relations, yeah, we'll need dynamic relations at some point
[17:43] <SpamapS> niemeyer: I think its a corner case that can be dodged right now
[17:44] <SpamapS> niemeyer: but one that will come up as diagrams get bigger and bigger
[17:45] <SpamapS> I wonder if there couldn't just be a command... refresh-relations .. that just tells the local unit agent to re-run all the hooks as if the relation data had changed.
[17:45] <niemeyer> SpamapS: Absolutely.. I don't have a good design in mind for it yet, to be honest, but I think we can do something good
[17:46] <niemeyer> SpamapS: It's a bit tricky because we have to take into account dependency resolution too
[17:46] <niemeyer> SpamapS: So in terms of ordering, we should get dependency resolution in first, so that we can implement this in light of the understanding that dep-resolv will provide
[17:47] <SpamapS> Yeah.. I'm less excited about dependency resolution than you guys are. :)
[17:48] <SpamapS> I can't really articulate why tho
[18:05] <niemeyer> SpamapS: Well, it's not that I'm terribly excited either.  I'm much more excited about stacks
[18:05] <niemeyer> SpamapS: But feels like a very nice convenience we want to get in place
[18:08] <SpamapS> Yeah, stacks!
[18:11] <hazmat> i think dynamic relations i think config based dependencies for generic formulas, that run apps, and have app spec'ified deps
[18:13] <niemeyer> hazmat: parsing failure :)
[18:14] <SpamapS> I think hazmat was just using lossy compression
[18:14] <SpamapS> up the bitrate a bit
[18:15] <hazmat> connection loss
[18:17] <hazmat> but just as a common example a rails or wsgi app that checkouts from vcs, and deploys the app.. but it has to assume currently a set of optional/required deps representing app infrastructure choices, does it use memcached or postgres v. mysql v. nosql.
[18:17] <hazmat> really their runtime dynamic deps, and what we capture are static ones
[18:17] <niemeyer> hazmat: Right.. that's exactly the context
[18:19] <hazmat> niemeyer, effectively we're another cli api.. for declaring additional deps.. although we lack an execution context that's service local rather than unit local.
[18:20] <niemeyer> hazmat: We don't declare additional deps.. the dependencies can be pre-defined, since they are always fixed
[18:20] <niemeyer> hazmat: Unless there's some genetic voodoo within the formula :-)
[18:22] <niemeyer> hazmat: E.g. the hooks will be pre-defined
[18:23] <niemeyer> There's very cool stuff we can do around this..
[18:23] <niemeyer> Hopefully before 2017
[18:23] <hazmat> :-)
[18:32] <_mup_> Bug #816581 was filed: Ensemble needs easy end user initial configuration <Ensemble:New> < https://launchpad.net/bugs/816581 >
[18:36] <_mup_> ensemble/expose-hooks r282 committed by jim.baker@canonical.com
[18:36] <_mup_> Merged trunk
[18:49] <niemeyer> jimbaker: robus-hook-exit looks nice in general, but I'm missing some of the context about why it's needed
[18:49] <niemeyer> jimbaker: I've posted some comments there
[18:50] <jimbaker> niemeyer, ok. i will take a look at your comments
[18:50] <niemeyer> jimbaker: Feel free to bring any of them up for debate here, please
[18:51] <jimbaker> niemeyer, yes, i assume you read the corresponding bug?
[18:51] <niemeyer> jimbaker: I've read your merge proposal description, the code, and the test
[18:52] <jimbaker> niemeyer, re the refactoring, sounds good to me, again i was following the convention in this code
[18:52] <niemeyer> jimbaker: Which convention?
[18:52] <jimbaker> niemeyer, so does it make sense the scenario being described, that a hook script may exit, but w/o its file descriptors being closed?
[18:52] <jimbaker> niemeyer, the convention of the existing file
[18:53] <niemeyer> jimbaker: Which convention, specifically?
[18:54] <jimbaker> niemeyer, the usage of the nested functions cleanup_process, which i followed in doing cleanup_ended
[18:54] <niemeyer> jimbaker: Ok, I see
[18:54] <niemeyer> jimbaker: When introducing new logic, some reevaluation is needed to ensure the style used still makes sense
[18:55] <jimbaker> niemeyer, sure, we just had that discussion earlier ;)
[18:55] <niemeyer> jimbaker: It might not be a big deal with a small closure.. when you have more than a full screen of closure which doesn't really use the fact it's a closure in a good way, something isn't right
[18:56] <jimbaker> niemeyer, correct neither nested function closes over variables
[18:56] <niemeyer> Right, anyway.. mionr
[18:56] <niemeyer> mionr
[18:56] <niemeyer> miNNOr
[18:56] <niemeyer> :-0
[18:56] <niemeyer> jimbaker: So
[18:56] <niemeyer> jimbaker: On the actual meaning of the branch
[18:57] <jimbaker> niemeyer, i think it is captured succinctly in a hook like this one:
[18:57] <niemeyer> jimbaker: I don't understand the scenario.. a hook exiting without fds being closed?  How's that a problem?
[18:57] <jimbaker> sleep 0.05 && echo "Slept for 50ms" && sleep 1 && echo "Slept for 1s" && sleep 1000000 &
[18:57] <jimbaker> some computation, some output
[18:58] <jimbaker> and of course the very relevant & at the end to fork it in the background
[18:58] <hazmat> jimbaker, but how is that an exceptional condition outside of its a taking a long time
[18:58] <hazmat> :-)
[18:58] <niemeyer> jimbaker: Ok.. sorry, I'm not trying to be difficult in any way.  How's that an issue?
[18:58] <jimbaker> hazmat, niemeyer - this arises in certain formulas where we have badly behaving code
[18:59] <niemeyer> jimbaker: This feels pretty normal?
[18:59] <hazmat> rabbitmq specifically per the bug
[18:59] <jimbaker> so in particular adam_g  brought it up
[18:59] <hazmat> niemeyer, it shouldn't be normal but it exists
[18:59] <niemeyer> What exists?
[18:59] <jimbaker> i worked on the branch because i made the original change from exited to ended semantics
[18:59] <niemeyer> hazmat: It's a problem, and it exists.. ookaaay :-)
[18:59] <hazmat> and this adds robustness to how we handle hooks, we had switched in the past to get better testing output
[18:59] <jimbaker> thomas herve diagnosed it
[19:00] <niemeyer> jimbaker: What was the problem he diagnosed?
[19:00] <niemeyer> jimbaker: and how is the branch fixing it?
[19:00] <hazmat> indeed.. that was very helpful.. he pointed out the difference between processEnded vs processExited on the process protocol
[19:01] <jimbaker> that child processes were not properly closing file descriptors because how they were redirecting things
[19:01] <hazmat> in the context of a rabbitmq, which had some odd behavior per its start scripts
[19:01] <jimbaker> hazmat, correct
[19:01] <jimbaker> and apparently this not so uncommon and there's an easy fix for us
[19:02] <niemeyer> jimbaker: How not closing file descriptors affect the way process ending happens?
[19:02] <hazmat> niemeyer, its waiting for the file descriptors to be closed
[19:02] <hazmat> vs waiting for the process to exit
[19:02] <jimbaker> niemeyer, waiting on process ending means waiting for the FDs to be closed
[19:02] <jimbaker> niemeyer, so this is generally the right thing to do because it means we fully capture useful stdout/stderr for logging
[19:03] <jimbaker> niemeyer, i had changed the semantics from exited to ended when i standardized the logging
[19:03] <jimbaker> niemeyer, as you may recall, we were doing some odd things there that ultimately was just making the tests to *usually* wait long enough for the logs to be complete
[19:04] <niemeyer> jimbaker: No, it doesn't mean that in general.. if you fork a process, and wait for it to exit with normal system calls, you don't wait for FDs to be closed
[19:04] <jimbaker> niemeyer, correct
[19:04] <jimbaker> niemeyer, so that's the distinction between waiting on process exited vs process ended
[19:05] <jimbaker> niemeyer, the twisted process protocol supports both, since they both have some nice qualities
[19:05] <SpamapS> m_3: is your mongo formula in principia yet?
[19:05] <niemeyer> jimbaker: Which fd is processEnded holding out on?  stdin?
[19:05] <jimbaker> niemeyer, the FD is going to be stdout or stderr
[19:05] <jimbaker> or both
[19:06] <jimbaker> niemeyer, in this particular test hook that i just pasted here, it's stdout
[19:06] <m_3> SpamapS: nope, I just got hazmat's and stripped it of replication
[19:06] <m_3> SpamapS: negronjl has one inbound that I expect will be nice
[19:06] <jimbaker> niemeyer, so because we capture these streams for logging, ideally we work with them
[19:07] <niemeyer> jimbaker: There's some detail missing still.. if a process exits, you get a SIGPIPE
[19:07] <jimbaker> niemeyer, in general this doesn't impact hook code - the process exits, it's done for the invoker. however if there's still more output, these are still written to logs
[19:07] <negronjl> m_3:  I'll push it soon .. 
[19:07] <niemeyer> jimbaker: and the process ended
[19:08] <niemeyer> jimbaker: Your example shows a sleep going into background, and never returning
[19:08] <jimbaker> niemeyer, correct - a child process just hanging around just like what we see in real cases
[19:09] <jimbaker> niemeyer, who knows when it returns? 
[19:09] <niemeyer> jimbaker: Hmm, ok, I think I start to see what you mean
[19:09] <jimbaker> niemeyer, in any event, in that case we reap them because we don't want processes like that around indefinitely
[19:09] <niemeyer> jimbaker: There's a child process, started by the hook, and we want it to continue running
[19:09] <niemeyer> jimbaker: Is that the case?
[19:10] <jimbaker> niemeyer, i chose 5 seconds because it's much larger than reasonable for good children, but doesn't matter in practice even w/ lots of bad children
[19:10] <niemeyer> jimbaker: Uh.. lost again
[19:10] <jimbaker> niemeyer, only for a little bit, just to let its logs settle
[19:10] <jimbaker> the actual reaper time probably would be fine w/ something like 200 ms
[19:10] <SpamapS> jimbaker: there are daemons that take a long time to start up .. but usually they don't let the parent die until they're ready for it to die.
[19:11] <jimbaker> SpamapS, correct - this doesn't impact such "good" children
[19:11] <jimbaker> niemeyer, so we are not trying to solve a larger problem of having time limits on hooks
[19:11] <SpamapS> In rabbit's case, it seems like we should report a bug in the init script that it needs to run w/ nohup
[19:12] <jimbaker> SpamapS, correct, that would be the normal simple way to get the desired behavior
[19:12] <SpamapS> which turns bad children into good children by first redirecting its own fds to dev null or a log
[19:12] <jimbaker> SpamapS, :)
[19:12] <m_3> like long-term care insurance
[19:12] <jimbaker> the analogies just pour in
[19:12] <SpamapS> m_3: Great example node.js app btw..
[19:13] <SpamapS> m_3: you may not have gotten much uptake on that... today is node.js day at OSCON ;)
[19:13] <m_3> cool thanks man
[19:13] <hazmat> jimbaker, we are and there is a bug open for that, but that has other things it needs to take into account like respecting debug hooks which will break time limits.. a standard hook timeout though needs to be quite large (large installs come to mind).
[19:13] <m_3> didn't know if I was going into too much detail
[19:13] <m_3> lots of zzzz's I think
[19:13] <jimbaker> hazmat, correct, a much larger problem
[19:13] <SpamapS> m_3: The log of the session may prove useful to someone. :)
[19:14] <m_3> wish there was a way to get the ajaxterm session too
[19:14] <niemeyer> jimbaker: Ok, I think I understand, and the approach looks good
[19:14] <m_3> should create a screencast I guess
[19:14] <niemeyer> jimbaker: It just needs proper documentation
[19:14] <jimbaker> hazmat, i think such a solution should allow for measuring *useful* progress back to the agent
[19:14] <niemeyer> jimbaker: I'll read the handling of processEnded, just to make sure I'm indeed getting what happens there
[19:14] <jimbaker> niemeyer, cool, i will work on that
[19:14] <niemeyer> jimbaker: Thanks for the patience explaining it
[19:14] <jimbaker> niemeyer, np
[19:15] <jimbaker> SpamapS, speaking of node.js, seeing any golang interest at oscon?
[19:15] <SpamapS> jimbaker: I'm not there yet. :-/
[19:16] <SpamapS> trying to keep up with keynotes and goings on so I won't be lost when I arrive on Thursday
[19:16] <jimbaker> SpamapS, cool, makes sense
[19:16] <niemeyer> jimbaker: Are you able to reproduce the problem easily?
[19:19] <adam_g> jimbaker: google people led a 3.5 hour go tutorial this morning
[19:19] <adam_g> niemeyer: the problem is easily reproduced deploying lp:principia/rabbitmq-server
[19:19] <SpamapS> Hey guys, I could use feedback on this.. please view w/ the notes .. http://spamaps.org/files/ensemble-oscon-2011.odp
[19:20] <niemeyer> adam_g: Yeah, by easily I was wondering about a trivial test case
[19:20] <niemeyer> I suspect the real issue here is that Python is eating SIGCHLD
[19:20] <niemeyer> which is the standard way by which a parent gets to know it child has died
[19:24] <jimbaker> niemeyer, pretty certain that the ProcessProtocol stuff is quite robust with respect to that
[19:24] <jcastro> SpamapS: too many lolcats, that's like 2 years ago
[19:25] <jimbaker> niemeyer, i can readily see the child process not completing its writes to output before process exit, simply by looping test_invoker
[19:26] <jimbaker> niemeyer, on this laptop maybe occurs 50% of time (don't recall specifics!) if i don't have the yields on process ended
[19:27] <jimbaker> niemeyer, so that's often enough that one really doesn't need to loop ;)
[19:29] <niemeyer> jimbaker: I think I get it.. I'm wondering mostly about this sentence from therve now:
[19:29] <niemeyer> """I don't think that bug is related to what's done during the install hook, fwiw. It happened to me with an empty install script."""
[19:30] <niemeyer> jimbaker: There's no "sleep" in this case, as per your example
[19:30] <niemeyer> jimbaker: So why would it remain un-ended
[19:31] <ahs3> probably a dumb n00b question...is there a way to have ensemble install a service on one or more existing machines (real ones, not EC2 instances)?  i'm not finding it in the docs, if there is...
[19:31] <jimbaker> niemeyer, i'm reading that a bit differently - there's some actual hook being executed, just not an install one
[19:32] <jimbaker> or at least just a trivial "empty" install one
[19:32] <jimbaker> niemeyer, so in particular i'm looking at reply #9 where we start to move into actual diagnosis
[19:32] <niemeyer> jimbaker: Ah, interesting, could be
[19:32] <niemeyer> jimbaker: That'd make more sense
[19:32] <hazmat> ahs3, that's a good question.. not at the moment re a standalone machine, there is  work being done today for physical machine integration  is in the context of using something like orchestra (cobbler)
[19:33] <jimbaker> niemeyer, yeah, i'd be very concerned if a empty hook would act like an infinite sleep ;)
[19:33] <hazmat> for setting up ensemble deployment with a physical machine data center
[19:33] <niemeyer> jimbaker: Exactly
[19:34] <jimbaker> niemeyer, but again we would fix that in the other one, bug 705433
[19:34] <_mup_> Bug #705433: Hooks need to have an enforceable timeout. <hooks> <Ensemble:New> < https://launchpad.net/bugs/705433 >
[19:34] <niemeyer>     def maybeCallProcessEnded(self):
[19:34] <niemeyer>         # we don't call ProcessProtocol.processEnded until:
[19:34] <niemeyer>         #  the child has terminated, AND
[19:34] <niemeyer>         #  all writers have indicated an error status, AND
[19:34] <niemeyer>         #  all readers have indicated EOF
[19:34] <niemeyer>         # This insures that we've gathered all output from the process.
[19:35] <hazmat> jimbaker, well an empty hook and a timeout are different, the question is really do want to use processExited instead
[19:35] <ahs3> hazmat: hrm.  thx.  i thought that might be the case.  what i would especially like is something that assumes a machine is already up, running and available, and then just puts the service on it.
[19:35] <jimbaker> hazmat, to clarify: this branch now uses processExited
[19:35] <hazmat> jimbaker, indeed it does both
[19:36] <niemeyer> jimbaker: Beautiful.. all looks great
[19:36] <jimbaker> hazmat, the only thing it uses processEnded for is to do the loseConnection handshake. unless the time between processExited and processEnded is larger than a ludicrous amount (5 s), in which case it simply kills the process with loseConnection
[19:36] <hazmat> jimbaker, yeah.. the branch looked good to me
[19:36] <niemeyer> jimbaker: Just a sentence or two highlighting the distinction between processEnded and Exited, given that these names are entirely unhelpful
[19:37] <jimbaker> i expect closing < 50 ms. 5 seconds ensures the probability of delays in normal closing to be exceedingly low, which seems a reasonable cost
[19:37] <niemeyer> jimbaker: This, specifically, will bite us when we read it again:
[19:37] <niemeyer> +        # The corresponding process has ended, so output streams have
[19:37] <niemeyer> jimbaker: The process has already ended  by the time processExited was called
[19:38] <niemeyer> jimbaker: (in unix/non-twisted lingo)
[19:38] <hazmat> jimbaker, the long inline functions seem a little strange stylistically, but thats minor
[19:39] <jimbaker> hazmat, yeah, no worries, they are moving to our established convention of _ methods since they are not actual closures (in the sense of actually closing over a non-empty set of variables)
[19:39] <jimbaker> hazmat, i was simply following the convention in that particular file, but it
[19:40] <jimbaker> represents somewhat earlier code for us
[19:40] <niemeyer> jimbaker: The convention is still the same.. we often put short local snippets in-context, but for 40+ lines the convention changes
[19:40] <hazmat> indeed that was so last year ;-)
[19:41] <niemeyer> as hazmat says, no big deal.. that's what reviews are for
[19:41] <jimbaker> niemeyer, oh sure, i think we all understand what's what
[19:42] <niemeyer> jimbaker: Cool, thanks again for the explanation
[19:42] <niemeyer> jimbaker: Had no idea about the processEnded concept used by Twisted
[19:42] <jimbaker> niemeyer, until this came up, neither did i, that's for certain
[19:43] <niemeyer> hazmat: have you looked over the branch?
[19:43] <jimbaker> but it makes perfect sense in the overall context of daemonization
[19:43] <hazmat> niemeyer, i have
[19:43] <niemeyer> jimbaker: Not sure it does.. the only use case I've seen so far was a bug. ;-D
[19:44] <hazmat> i think i looked at it when i implemented it, and used exited for the initial implementation, but i definitely understood and agreed why it was switched, and this additional robustness around usage looks good to me
[19:44] <niemeyer> hazmat: Cool, would you mind to put your concerns in the MP if you have any, or +1 it?
[19:45] <hazmat> niemeyer, sure
[19:45] <niemeyer> hazmat: Thanks
[19:50] <niemeyer> hazmat: This MP is empty: https://code.launchpad.net/~hazmat/ensemble/security-connection/+merge/68621
[19:50] <niemeyer> hazmat: Is it missing a push?
[19:53] <hazmat> perhaps.. let me check
[19:54] <hazmat> i think that was one of the borked branches
[19:54] <hazmat> niemeyer, it says its up to date revno 285
[19:55] <hazmat> niemeyer, to answer the mp question lp is on crack for that branch
[19:55] <_mup_> Bug #816621 was filed: Ensemble doesn't appear to set up a complete environment while running the installation scripts and hooks <Ensemble:New> < https://launchpad.net/bugs/816621 >
[19:57] <niemeyer> hazmat: Cool
[19:57] <niemeyer> I'll step out for a coffee break.. 
[20:01] <hazmat> negronjl, re cloud foundry bug above, did you  have ruby's eventmachine installed via package locally?
[20:02] <hazmat> negronjl, i'm wondering if the issue is dep not specified in packaging
[20:03] <SpamapS> jcastro: I need a new meme. :)
[20:05] <hazmat> negronjl, the package software is depending on eventmachine, and its not being installed via package per the hook logs, unless there's a private copy to cloudfoundry, it definitely seems like a missing dep issue.
[20:11] <SpamapS> jcastro: should I go with fuuuuuuuuuuu instead?
[20:12] <jcastro> SpamapS: you started with a terminator-skynet meme
[20:12] <jcastro> SpamapS: "ensemble with me if you want to live."
[20:13] <jcastro> SpamapS: deployment day = judgement day. I mean, there's so many places to go with this
[20:13] <SpamapS> jcastro: my reason for lolcats was to say that ensemble was invented primarily to help process all of the pictures of cats incoming from smart phone users.. but it never materialized
[20:14] <SpamapS> jcastro: This is true.. and open source can be John Connor's rebels. ;)
[20:14] <jcastro> SpamapS: use the fuuuuuu-maker thing from reddit
[20:15] <jcastro> wait, no, that's a bad idea, that will just lead to hilarity
[20:23] <niemeyer> hazmat: The contributor's page is up-to-date already
[20:23] <niemeyer> s/'//
[20:26] <hazmat> niemeyer, url?
[20:26] <niemeyer> hazmat: http://www.canonical.com/contributors
[20:29] <hazmat> niemeyer, cool, thanks
[20:33] <SpamapS> jcastro: I want the last 20 minutes back... distractions... http://spamaps.org/files/hadoop-rage.png
[20:34] <hazmat> :-)
[20:35] <jcastro> I new you wouldn't let me down
[20:35] <jcastro> knew even
[20:45] <SpamapS> jcastro: Not sure thats hilarity.. its a little too commercial for me. ;)
[20:54] <negronjl> hazmat:  All the deps are satisfied.  If you run the script manually, everything works just fine.
[20:54] <negronjl> hazmat:  It only breaks when run via ensemble
[21:06] <hazmat> SpamapS, slides look nice
[21:13] <niemeyer> hazmat: lp is seriously wedged on that branch 
[21:13] <niemeyer> % bzr branch lp:~hazmat/ensemble/security-connection
[21:13] <niemeyer> bzr: ERROR: Not a branch: "/home/kapil/canonical/ensemble/mine/security/.bzr/pipes/security-connection/".
[21:13] <niemeyer> hazmat: !!!
[21:24] <niemeyer> SpamapS: Good stuff in the slides indeed
[21:34] <hazmat> niemeyer, ugh
[21:36] <hazmat> niemeyer, locally it looks fine.. trying with push --overwrite
[21:36] <hazmat> yeah.. still nothing
[21:37] <niemeyer> hazmat: Trying branching to the side, maybe?
[21:37] <niemeyer> hazmat: Worth saving the whole tree somewhere else first!
[21:37] <niemeyer> hazmat: To avoid losing any work
[21:37] <hazmat> niemeyer, its the middle branch of a pipeline already, additional branches have pushed succesfully
[21:38] <_mup_> ensemble/trunk-merge r273 committed by kapil.thangavelu@canonical.com
[21:38] <_mup_> merge trunk
[21:44] <hazmat> niemeyer, redid the merge proposal with a copy of the branch
[21:44] <niemeyer> hazmat: Phew, glad it worked
[21:45] <niemeyer> That was weird
[21:45] <kirkland> m_3: what's your LP id?
[21:46] <kirkland> m_3: https://launchpad.net/~mark-mims ?
[21:48] <kirkland> m_3: okay, I'm sufficiently convinced that's you :-P
[21:52] <m_3> kirkland: yes, ~mark-mims
[21:54] <RoAkSoAx> lol
[21:54]  * RoAkSoAx once again remembers the pains of having a nick name different for a LP id... :)
[21:55] <kirkland> RoAkSoAx: for the love, yes, standards!
[21:56] <RoAkSoAx> kirkland: tried to change my nick to lp id but it was simply better to keep it as is cause nobody knew me with the new nicknam,e :)
[21:57] <niemeyer> hazmat is the review queue lord
[21:57] <hazmat> niemeyer, slave? ;-)
[21:57] <niemeyer> hazmat: Nah, I'm the slave
[21:57] <niemeyer> :-)
[22:02] <lynxman> hey guys, just wanted to share the news
[22:02] <lynxman> Ensemble is already in Macports
[22:02] <lynxman> lynxman@kreuzberg:~ $ sudo port search ensemble
[22:02] <lynxman> ensemble @0.5 (python, net) Ensemble is a next generation service orchestration framework.
[22:03] <lynxman> err false alarm, I'm too sleepy :)
[22:03] <lynxman> sorry
[22:05] <lynxman> :D
[22:05] <SpamapS> well, cool anyway ;)
[22:05] <m_3> +1
[22:10] <niemeyer> lynxman: neat :-)
[22:11] <lynxman> thought the package was just added to the repo, as soon as it's there I'll let you know :)
[22:38] <niemeyer> jimbaker: Finally got to review your debug-log-relations branch
[22:38] <niemeyer> jimbaker: Some comments, but good stuff overall
[22:38] <niemeyer> jimbaker: Sorry for the delay
[22:49] <daker> hazmat, sorry to disturb you, on this page http://www.canonical.com/contributors there is no mention of "ensemble"
[22:51] <niemeyer> daker: Indeed.. feel free to send it to kapil himself
[22:51] <niemeyer> daker: In addition to the email there
[22:53] <daker> niemeyer, i send what ? don't tell i need to download the pdf, fill it with my name, then scan it.
[22:54] <niemeyer> daker: Ok, I won't tell it.. :-)
[22:55] <hazmat> daker, afaik, that's what needs to be done for contribution to any canonical sponsored software project, i guess a photo would suffice in lieu of a scan
[22:56] <daker> that sucks :/
[22:57] <niemeyer> daker: Sorry for the boilerplate.. note this is somewhat normal on contributions 
[23:02] <SpamapS> Heh.. so.. I'm preparing to upload trunk to Ubuntu .. and I've started the process of running the test suite when the package builds.
[23:02] <SpamapS> It doesn't fail the build..
[23:03] <SpamapS> But it will record the results in /usr/share/doc/ensemble/test-results.txt ... so we can start the process of fixing bugs where tests fail on the buildd.
[23:55] <_mup_> Bug #816736 was filed: debian dir gets in the way of packaging and is no longer necessary <Ensemble:New> < https://launchpad.net/bugs/816736 >