#ubuntu-ensemble 2011-09-01 <niemeyer> Man.. the interaction between Launchpad pieces to create our workflow is never-ending <hazmat> :-) <niemeyer> Seriously.. bugs, bug tasks, milestones, projects, series, proposals, people, branches.. we use it all <_mup_> ensemble/managed-agent r344 committed by alexanderlisa@example.com <_mup_> managed machine agent <SpamapS> niemeyer: OOHHH YEAHHH <FLEX> <niemeyer> SpamapS: :) <hazmat> niemeyer, like i said.. i found it easier to just sync everything local.. <hazmat> when working with any sort of report/ui on top of lp <hazmat> and then factoring in the speed of the average rest call.. and becomes a quick win <_mup_> Bug #838472 was filed: local-dev needs to manage/inspect the network <local-dev> <Ensemble:In Progress by hazmat> < https://launchpad.net/bugs/838472 > <_mup_> Bug #838476 was filed: local-dev provider needs a provider machine <local-dev> <Ensemble:In Progress by hazmat> < https://launchpad.net/bugs/838476 > <_mup_> ensemble/managed-agent r345 committed by alexanderlisa@example.com <_mup_> verify agent/process controls can be called multiple times <niemeyer> hazmat: It'd not help much I think.. even if you sync up everything locally, you still have all the linkage between the multitude of types <hazmat> niemeyer, you can collapse the types into app oriented docs/objs when syncing <hazmat> s/types/links <niemeyer> hazmat: Sure, but you're still processing everything up <niemeyer> hazmat: Almost done: http://goneat.org/pkg/launchpad.net/lpad/ <niemeyer> It _looks_ like I just need to sort out series now <_mup_> Bug #838480 was filed: local-dev needs a way to manage a machine agent <Ensemble:New> < https://launchpad.net/bugs/838480 > <niemeyer> And then "push-review" is done.. :) <hazmat> niemeyer, nice <hazmat> niemeyer, re lpad.. looking much more complete <niemeyer> hazmat: Goes from branch to ready for review with no interaction <niemeyer> hazmat: Following all of our conventions <niemeyer> hazmat: Opens the preferred text editor for summary/desc <hazmat> niemeyer, awesome.. bug report + lp ? <hazmat> er mp <niemeyer> hazmat: push, bug report, mp, link everything <hazmat> niemeyer, great <hazmat> niemeyer, can i get a copy i? :-) i just did like 4 of those by hand <niemeyer> hazmat: Oh, most definitely.. I'm doing that for the team <hazmat> niemeyer, nice that you can group all the lp interactions in parallel as well, really cuts down on the command time i would guess <niemeyer> hazmat: Exactly.. it does quite a few things in parallel <niemeyer> hazmat: With nice reporting to stdout and all <niemeyer> hazmat: It was also a good way to push the Launchpad API a bit forward.. I'll need it to continue on the store <niemeyer> That was my day today.. <hazmat> niemeyer, yeah. that's great.. i know bcsaller was interested in using it, but needed alot of boilerplate classes to get going <niemeyer> hazmat: There's still a ton missing because the API is so huge, but the foundation is more laid down now <hazmat> niemeyer, good stuff.. i've done pretty well by local dev today.. i'm going to finish up some test for the provider, and move on to the service unit deployment with lxc tomorrow <niemeyer> hazmat: Wow, neat <hazmat> i'm very excited to start using it <hazmat> it will actually totally justify me getting an ssd <niemeyer> hazmat: I noticed a lot of things flying by today <niemeyer> hazmat: Feels like a good wave :) <niemeyer> hazmat: Haha :) <niemeyer> hazmat: It's worth it :) <hazmat> niemeyer, yeah... nice to get some interrupted time.. i've been neglecting the review queue though, i'll have a look at that tomorrow morning <hazmat> i know both you and william have some branches there that need attention <niemeyer> hazmat: Thanks, there are a few things we have to push forward there indeed <_mup_> ensemble/local-provider r345 committed by alexanderlisa@example.com <_mup_> wire in the managed machine agent and zk state initialization into provider bootstrap <_mup_> ensemble/local-provider r346 committed by alexanderlisa@example.com <_mup_> store zookeeper address into local provider storage, implement connect <hazmat> i started having this problem w/ lxc <hazmat> ssh {{EMAIL+PHONE}} <hazmat> {{EMAIL+PHONE}}'s password: <hazmat> PTY allocation request failed on channel 0 <hazmat> bcsaller, you seen that? <bcsaller> thats the issue with add-apt-repo asking for you to press enter I'd guess <bcsaller> http://paste.ubuntu.com/679240/ <bcsaller> but not sure, if you change it off the ppa (where it doesn't add the repo) does it work? <hazmat> bcsaller, we're using cloud init in the container now? <hazmat> or is this something just inherent? <bcsaller> I don't use it for anything <hazmat> these are just on oneiric containers that used to be working for me <bcsaller> this isn't a cloud-init issue, its a change in python-softwareproperties <bcsaller> add-apt-repo started asking for confirmation when its got a tty on stdin <bcsaller> might be able to close stdin first and fake it out, not sure yet <bcsaller> or echo y | add-apt-repo... <bcsaller> since it only checks that it gets a newline <hazmat> ugh <_mup_> Bug #838565 was filed: Testing push-review <Ensemble:New> < https://launchpad.net/bugs/838565 > <_mup_> ensemble/local-provider r347 committed by alexanderlisa@example.com <_mup_> lxc utility to get a python dict mapping container name to runtime boolean status <_mup_> Bug #838566 was filed: push-review must be tested <Ensemble:In Progress by niemeyer> < https://launchpad.net/bugs/838566 > <_mup_> ensemble/local-provider r348 committed by alexanderlisa@example.com <_mup_> shutdown and destroy all containers when destroying environment. <_mup_> Bug #838568 was filed: push-review must be tested again <Ensemble:In Progress by niemeyer> < https://launchpad.net/bugs/838568 > <_mup_> ensemble/local-provider r349 committed by alexanderlisa@example.com <_mup_> check required packages installed with python-apt <niemeyer> Alright.. that was a loooong day.. <niemeyer> Have a good time everybody <hazmat> niemeyer, indeed.. it was.. looking forward to using the new tool.. cheers <niemeyer> hazmat: Cheers! <_mup_> ensemble/local-unit-deploy r350 committed by alexanderlisa@example.com <_mup_> unit deployment with containers <smoser> SpamapS, bug 831505 should be fixed. we chose to redirect output to /dev/null rather than add '-y' as older versions of apt-add-repository dont know that flag. <_mup_> Bug #831505: add-apt-repository blocks cloud-init on oneiric <cloud-init (Ubuntu):Fix Released> < https://launchpad.net/bugs/831505 > <fwereade> is there any consensus solution (heh, I'd take any solution) to the problem of multiple methods with intentionally identical docstrings (eg MachineProviderBase.connect and ZookeeperConnect.run)? <fwereade> or is this just another "the price is eternal vigilance" situation? <hazmat> g'morning <hazmat> fwereade, i was wondering about that <hazmat> fwereade, i thought about using a decorator that pulled from the base class doc string <hazmat> its more relevant with abstract base classes that document the protocol <fwereade> hazmat: I had a similar thought, but it seemed a bit icky ;) <fwereade> hazmat: true <fwereade> hazmat: but then there are cases where the base specifies (say) :class:`ProviderMachine` and the base will want to say :class:`OrchestraMachine` <hazmat> fwereade, i used to use zope.interfaces as a primary doc point, and let the implementation stand alone, with a see ``interface.method`` <fwereade> hazmat: I couldn't see anything that would be useful in enough cases to make it feel worth bothering <fwereade> hazmat: mm, handy in the right context <fwereade> hazmat: hey, is sphinx smart enough to connect things with unique names? <fwereade> hazmat: so :exc:`ProviderInteractionError` rather than :exc:`ensemble.errors.ProviderInteractionError`? <fwereade> hazmat: feels like a bit too much to expect, but if not I have to go back and fully qualify a bunch of stuff <fwereade> ah well <hazmat> fwereade, i believe it is <hazmat> we need to start genering the docs from source to find out <hazmat> jim mentioned he had an issue with it earlier * hazmat tries to find a place in sf to stay next week for the lxc sprint <fwereade> hazmat: hm, I guess I should actually try generating them :/ <hazmat> niemeyer, morning <niemeyer> hazmat: Morning! <fwereade> morning niemeyer <niemeyer> fwereade: yo! <niemeyer> How's everyone doing this morning? <niemeyer> Or rather, this X? :-) <hazmat> fwereade, great reviews, thanks <fwereade> not too bad :) and you? <hazmat> niemeyer, i'm still recovering from a late night, but early wake up <fwereade> hazmat: cool, glad they're helpful -- I got a bit overwhelmed by the test failures so I kinda stopped half way through <hazmat> fwereade, yeah those suck <niemeyer> hazmat: Indeed! This must be pretty early for you given how late we were yesterday <hazmat> fwereade, i'm looking at the control deploy failures now <hazmat> very odd <hazmat> KeyInteruption in the middle of a test without hitting a keyboard <fwereade> hazmat: incidentally, should I WIP them when I mark them "needs fixing"? it seemed presumptuous, but on balance I think it's less helpful *not* to <fwereade> hazmat: (if that makes sense) <hazmat> fwereade, i think its appropriate when there's a test failure like this <fwereade> hazmat: cool, cheers <niemeyer> fwereade: Yeah, you have to take a decision there, of whether it'd be beneficial for the next reviewer to look at the changed branch, or if it doesn't make a difference <hazmat> fwereade, it really depends imo, if the changes for the review are substantial enough that a second reviewer would be better to have a look after the changes <fwereade> hazmat: sounds sensible <hazmat> looks like there was something in the lxc-lib branch which has a delta to trunk regarding placement policies <_mup_> ensemble/lib-zookeeper r340 committed by alexanderlisa@example.com <_mup_> revert changes from lxc-lib to ensemble/control, resolves some deploy test failures <jimbaker> hazmat, trial can raise a KeyboardInterrupt in _wait, see twisted.trial.unittest: http://paste.ubuntu.com/679811/ <hazmat> jimbaker, thanks, thats very useful to know <fwereade> jimbaker: I've just been poking at sphinx docstring-grabbing; hazmat mentioned you might know of some problems <jimbaker> fwereade, indeed i did experience problems in generating docs using autodoc <jimbaker> fwereade, so did you just do the basic stuff of setting up autodoc through conf.py and linking in packages to be doc'ed? <fwereade> jimbaker: basically yes <fwereade> jimbaker: what was the problem? <jimbaker> fwereade, when i did that, i ran into a recursion error in docutils <jimbaker> fwereade, i assumed it was just bad some docstring that was breaking things and just needed to be isolated <fwereade> jimbaker: heh, haven't hit that yet -- btw, have I missed some option that will cause it to find and document *all* the docstrings? <jimbaker> fwereade, you expected that? ;) <fwereade> jimbaker: kinda :p <fwereade> jimbaker: the "auto" bit of the name "autodoc" got my hopes up a bit <jimbaker> fwereade, in fact so did i. but the sphinx project apparently thinks this is not so useful. there is a third party script to do that which i found <jimbaker> fwereade, to be honest, the mechanism they do have which is to require this be done in __init__.py is not so bad <fwereade> jimbaker: I noticed something like that, and then I started thinking about stripping test docstrings, and then I started doing something else <fwereade> jimbaker: indeed, quite sensible, may as well go with that then <fwereade> jimbaker: and I guess I'll build after every change and hopefully spot the recursing thing that way <fwereade> jimbaker: cheers :) <jimbaker> fwereade, indeed, i think it should pop out quickly <niemeyer> Holy crap.. our review queue is _amazing_ <niemeyer> I'll step out for lunch.. may be a few minutes late for our meeting <robbiew> fyi, tweaked https://ensemble.ubuntu.com/ a bit last night....holler if there's an issue <_mup_> ensemble/lib-files r341 committed by alexanderlisa@example.com <_mup_> remove use of file_storage.path by some tests. * niemeyer is around <niemeyer> robbiew: Ohh, video <niemeyer> robbiew: Great stuff, thanks man <robbiew> np <niemeyer> bcsaller, jimbaker, fwereade, hazmat: Call time? <fwereade> niemeyer: sounds goood <niemeyer> robbiew: Wanna join? <bcsaller> niemeyer: I'm around <jcastro> g+? I wouldn't mind listening in if you guys have the room <niemeyer> jcastro: We can put a few things away to accommodate you for sure <jimbaker> niemeyer, cool <robbiew> niemeyer: invite me...I'll join later, on a call <niemeyer> jcastro: Not entirely sure if I did the right thing when inviting you.. I used your canonical addres <niemeyer> s <niemeyer> Weird.. <niemeyer> It broke down <jcastro> odd, never seen that error before <hazmat> just sent out a new invite <hazmat> g+ hangouts have been flakey for me on occasion <bcsaller> my camera isn't working, going to relog <jimbaker> still waiting on a g+ hangout <hazmat> these leaking temp files and dirs are a problem <hazmat> seeing lots of them <niemeyer> jimbaker: ping <niemeyer> bcsaller, hazmat: I've renamed a couple of blueprints to remove the redundant "ensemble-" prefix.. feel free to change further please <jimbaker> niemeyer, hi <niemeyer> jimbaker: Sent some private comments <SpamapS> http://paste.ubuntu.com/680072/ <SpamapS> ^^ this test fails for me sometimes.. but not all the time <SpamapS> actually it fails every time <hazmat> SpamapS, interesting <hazmat> SpamapS, that's one of the tests that i found leaks files as well <hazmat> actuall a temp directory <_mup_> ensemble/ftests r1 committed by alexanderlisa@example.com <_mup_> Bootstraped simplistic functional test suite. <niemeyer> jimbaker: https://launchpad.net/ensemble/ftests <jimbaker> niemeyer, thanks <niemeyer> jimbaker: mkdir ensemble-ftests; cd ensemble-ftests; bzr init-repo .; bzr branch lp:ensemble/ftests ftests <niemeyer> jimbaker: Different line of development <niemeyer> jimbaker: Branches, merge proposals, etc, all as usual.. <niemeyer> jimbaker: http://bazaar.launchpad.net/~ensemble/ensemble/ftests/files <niemeyer> jimbaker: Please preserve the structure and spirit in there.. churn should continue to be a shell-script too <niemeyer> jimbaker: Generate the html out of the output directory.. should be trivial <jimbaker> niemeyer, ok, taking a look at the skeleton <niemeyer> jimbaker: Leave environments.yaml and AWS credentials outside of the test suite itself, for now <niemeyer> jimbaker: So that it works with any deployment method based on who sets it up <jimbaker> niemeyer, sure <niemeyer> jimbaker: Not sure if that'll be a good idea, but let's try it <niemeyer> jimbaker: The tool to generate the html can be in Python or whatever you please, for convenience <niemeyer> jimbaker: It'll also have to take into account different runs of the tool <niemeyer> jimbaker: To produce the waterfall <jimbaker> niemeyer, i'm certainly glad i don't have to write everything in bash <niemeyer> jimbaker: :-) <SpamapS> devops_borat.. "If you are still do manual deployment, you need of know in devops we call it 'hand job'" <jimbaker> niemeyer, is it really necessary to have churn (what we discussed as the runner) be a shell script too? <niemeyer> jimbaker: Yes, it is, because it'll ensure you keep it simple <jimbaker> seems like a painful lesson in bash scripting, but ok <SpamapS> Hmm, so.. working on bug 813112 so I can make the package builds fail on test failure.. <_mup_> Bug #813112: test suite cannot run without an ssh key <Ensemble:New> < https://launchpad.net/bugs/813112 > <niemeyer> jimbaker: It's more than that.. it's a lesson in simplicity. I don't expect you'll need much more than what's there to solve our problem. <niemeyer> jimbaker: If alexanderlisa@example.com. <SpamapS> http://paste.ubuntu.com/680131/ <jimbaker> niemeyer, i'll see what it takes <SpamapS> That fixes it.. <SpamapS> I suppose I should just throw it in the review queue. * SpamapS waves his hands... nothing to see here <jimbaker> niemeyer, in particular, why are log/fatal defined in churn? <niemeyer> jimbaker: I don't get what you mean.. the functions seem self-obvious to me? <jimbaker> niemeyer, well why would you need them there? shouldn't it be the responsibility of the tests to produce output, as they do in the examples now? <niemeyer> jimbaker: Again, I don't understand what you mean.. <niemeyer> jimbaker: I want to be able to type ./churn and have reasonable output presented to me <niemeyer> jimbaker: log is an incredibly trivial function that simply presents a message with a timestamp in it.. <niemeyer> jimbaker: Why does that sound strange? <jimbaker> niemeyer, never mind <niemeyer> jimbaker: Done <niemeyer> I'll get some coffee <hazmat> niemeyer, is there a reason why the golang-weekly hasn't been updated in a month? does it depend on an upstream weekly release? <hazmat> yeah.. it looks like no recent weeklies <niemeyer> hazmat: I've been slacking <niemeyer> hazmat: I was just updating it _today_ though <niemeyer> hazmat: After lucio asked about it <niemeyer> hazmat: tip has been updated.. I'll poke the weekly now <hazmat> niemeyer, cool.. where does goinstall put files on disk for a go-lang package install? <hazmat> got it /usr/lib/go/pkg <niemeyer> hazmat: $GOPATH, if you set it as a user <niemeyer> hazmat: Otherwise it'll try to put in $GOROOT <hazmat> niemeyer, ic, just doing the package install <hazmat> niemeyer, so do you manipulate GOPATH when you have multiple packages in the same source tree <hazmat> niemeyer, i'm trying to run the formula tests, but it won't find the schema package for example <niemeyer> hazmat: Hmm <hazmat> do i need to goinstall the schema package? and then continually update it ? <niemeyer> hazmat: I may have to tweak that to work with GOPATH <niemeyer> hazmat: What I've been doing, and which should work, is to make install within the schema package <niemeyer> hazmat: The detail is that I have a local tip branch <niemeyer> of go <niemeyer> hazmat: This should work with GOPATH as well, though <niemeyer> hazmat: But I'll have to fix it <niemeyer> hazmat: The design was made in such a way that you can goinstall straight from Launchpad <niemeyer> hazmat: goinstall launchad.net/ensemble/go/schema works <niemeyer> hazmat: and so does goinstall launchad.net/ensemble/go/formula <niemeyer> hazmat: the latter will automatically perform the former even <hazmat> niemeyer, sure.. but if i'm testing a source tree which has multiple packages, then i'll need to constantly update those <niemeyer> hazmat: There are just some minor inconveniences right now because $GOPATH is a recent thing and hasn't been introduced across the board in all tools, so I'll have to tweak the Makefile a bit <hazmat> niemeyer, cool, it would definitely be a benefit to have packages tested together from the same tree, instead of having to version manage the installed against the src tree. <niemeyer> hazmat: How do you mean? As I just explained, there are some details right now, but the design is that you'll have to do nothing besides goinstalling <niemeyer> hazmat: I think we misunderstand each other.. they are in the same tree <hazmat> niemeyer, goinstalling puts files in into the $GOROOT/pkg tree.. but say i have two interdependent package changes in the same src tree, i want to run make test, and have it use the src tree for both packages, not manually update the $GOROOT/pkg beforehand <niemeyer> hazmat: As I explained, you should use $GOPATH, not $GOROOT, and they'll all be in $GOPATH/src, in the same tree <niemeyer> hazmat: goinstall will soon also figure changes in dependent packages automatically, and rebuild/reinstall <niemeyer> hazmat: It's flaky right now because this area is being worked on, but the plan is pretty good <niemeyer> hazmat: Soon we'll need no Makefile iether <niemeyer> either * hazmat looks up gopath <hazmat> interesting, sort of like an encapsulation of virtualenv into an environment variable <niemeyer> hazmat: Yeah <niemeyer> hazmat: If you want to test the code quick & fast without worrying about anything else, you can just install Go from tip with: hg clone https://go.googlecode.com/hg go; cd go; export GOROOT=$PWD; cd src; ./make.bash <niemeyer> hazmat: This will mean GOROOT is writable <niemeyer> hazmat: and it's why it works.. <niemeyer> hazmat: I'll sort out the Makefiles in the future, though, so that GOPATH is taken care of in the Makefiles <niemeyer> hazmat: Sorry for the trouble there <hazmat> niemeyer, no worries, thanks for the info, i'll see if i can run the tests with that.. the remote version of launchpad.net/ensemble/go/schema is more recent than the one in the branch, so it gets undefined symbols for the renames <niemeyer> hazmat: Hmm <niemeyer> hazmat: Have you noticed that schema and formula are in the same branch? <hazmat> niemeyer, i have <hazmat> niemeyer, how do you install a src package with goinstall <niemeyer> hazmat: Have I screwed up something then? Any branch should be self-consistent <hazmat> afaics, i have to rename the directories into import paths to use GOPATH <niemeyer> hazmat: goinstall "server.com/import/path" <niemeyer> hazmat: Why? <hazmat> niemeyer, that installs the remote version <niemeyer> hazmat: Unless you have a local version <hazmat> niemeyer, the remote version is incompatible with one of the packages in the branch, it needs to compile against the other package in the branch <hazmat> niemeyer, i'm just running make test from the formulas directory <hazmat> niemeyer, if there's a way to install the local version of the package that would work <niemeyer> hazmat: I don't understand.. the remote version works with the remote version.. branches work with the content of the branch <niemeyer> hazmat: It's like Python <niemeyer> hazmat: If you have a branch, ensemble.provider works with ensemble.state of the same branch <niemeyer> hazmat: There's no difference there <hazmat> niemeyer, is there some path variable you have to define for that? .. i'm trying to run 'make test' in the formula directory <niemeyer> hazmat: No.. as I explained, what I do is to: cd schema; make install; cd ../formula; gotest <hazmat> niemeyer thanks, that's what i needed <niemeyer> hazmat: http://paste.ubuntu.com/680159/ <niemeyer> hazmat: And again, this is still pretty clumsy compared to what we'll have shortly.. <niemeyer> hazmat: Once $GOPATH and gomake come fully to life, it'll be brainless.. <hazmat> niemeyer, indeed that will be much easier <niemeyer> hazmat: Just gomake inside schema will do everything <hazmat> niemeyer, http://paste.ubuntu.com/680163/ <niemeyer> hazmat: Define GOROOT <hazmat> k <niemeyer> hazmat: export GOROOT=/usr/lib/go <niemeyer> hazmat: If you're using the package <niemeyer> gomake would do that for you already, by the way <niemeyer> But since you'll be playing with it often, it's worth putting it in the profile <hazmat> niemeyer, i've got the standard go variables defined pointing at the system path <hazmat> s <hazmat> /usr/lib/go for goroot /usr/bin for gobin <niemeyer> Cool <hazmat> i've got a previous install of the newer remote package version in goroot <hazmat> which is causing the problem <niemeyer> hazmat: But it was undefined in that paste, right? <hazmat> niemeyer, oh.. i assumed the newer version has the renames already in it.. it would have a different error regarding the package import if it wasn't installed <hazmat> if i remove the pkg from $GOHOME, and do the cd schema; make install; cd ../formula; gotest it fails with http://paste.ubuntu.com/680165/ <niemeyer> hazmat: DEFINE $GOROOT! <niemeyer> :-) <niemeyer> Makefile:1: /src/Make.inc: No such file or directory <niemeyer> There's a $GOROOT variable before the /src/ in that line.. which is empty! <hazmat> hmm.. but its defined.. make test in the schema works fine <niemeyer> It's not defined, no <niemeyer> export GOROOT=/usr/lib/go <niemeyer> Or whatever it is <hazmat> http://paste.ubuntu.com/680169/ <hazmat> yeah <niemeyer> hazmat: It's not defined.. <niemeyer> hazmat: That's the error you're getting <niemeyer> hazmat: This is the first line in the Makefile: <hazmat> niemeyer, that's env | grep GO in the shell. it is defined <niemeyer> include $(GOROOT)/src/Make.inc <hazmat> ah <niemeyer> hazmat: Works now? <niemeyer> hazmat: Can't find a way to link blueprints and bugs in the API :-( <hazmat> niemeyer, nope. <niemeyer> hazmat: What's wrong now? <hazmat> niemeyer, same problems, if i install it complains about undefined schema.M, if i uninstall it.. it complains about it not being found <niemeyer> hazmat: Can you please paste the error? <hazmat> niemeyer, it was the sudo.. killing the env variable i think <hazmat> nope.. still an error <niemeyer> hazmat: Same error? <hazmat> http://paste.ubuntu.com/680178/ <niemeyer> hazmat: It's the same error.. GOROOT not defined <niemeyer> hazmat: Use gomake.. it'll export the variable fo ryou <hazmat> niemeyer, sweet! that works <niemeyer> hazmat: Woohay * hazmat grabs some dinner <hazmat> niemeyer, yeah i don't see any way to attach a bug to the blueprint/spec via the api <hazmat> bummer <niemeyer> hazmat: Sadness.. let's see if the LP folks can give us a hand #ubuntu-ensemble 2011-09-02 <jimbaker> niemeyer, any preferences in terms of python tools for writing html? cheetah? <niemeyer> jimbaker: I would prefer something very simple <jimbaker> niemeyer, exactly. so please tell me what you prefer, and i will use it :) <niemeyer> jimbaker: If possible a single Python file we can embed in the project itself <niemeyer> jimbaker: Since our needs are pretty trivial.. just iterating over a list building a table with OK/FAILED + links <niemeyer> jimbaker: Do you know anything like that? <niemeyer> I'll get some food, biab <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 <SpamapS> OK/FAILED links? isn't that what jenkins does? <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 <jimbaker> SpamapS, correct, we are re-implementing what jenkins does <jimbaker> SpamapS, regardless this is the task i have <SpamapS> eh? <jimbaker> for our functional testing <SpamapS> Right, subunit doesn't have something ? <SpamapS> I mean, jenkins is like, the industry standard. <SpamapS> And we have a.. really kick ass jenkins formula. :) <jimbaker> SpamapS, agreed that jenkins is the industry standard <SpamapS> https://wiki.jenkins-ci.org/display/JENKINS/NUnit+Plugin <SpamapS> I was kind of hoping we'd get to a point where we were graphing all that lovely test coverage <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 <SpamapS> aww snap <jimbaker> SpamapS, this is actually a good thing. trial is pretty wretched for long running functional tests <jimbaker> SpamapS, niemeyer has written a new test runner that will execute shell scripts (this is the churn we discussed earlier on this channel) <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. <jimbaker> SpamapS, however, it might make sense to output junitxml instead. perhaps that could be considered at a later time. <SpamapS> A new test runner that runs shell scripts? <SpamapS> Thats also what jenkins does. :) <SpamapS> Tho its not much of a tool for developers to run in an iterative sense.. <SpamapS> I didn't think the functional tests would be somethign you'd do in that manner. <SpamapS> Figured you'd just set jenkins jobs up to point at in progress branches and trunk and run tests on commit <jimbaker> SpamapS, that makes a lot of sense to do. again the test runner could readily output junitxml <jimbaker> SpamapS, the more important thing is that we want functional tests directly exercising ensemble commands <SpamapS> Hey, me too. :) <SpamapS> On all supported configurations <SpamapS> (that last bit is integration testing.. but .. details.. ;) <jimbaker> SpamapS, cool. so consider this as an intermediate step <jimbaker> trust me, it will be very easy to have this integrated into jenkins in some subsequent step <SpamapS> Alright, well yeah, I'd think the time spent outputting HTML would be better spent outputting junitxml that jenkins can read and digest. <SpamapS> On the tests.. <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 ... <SpamapS> we should have a pow-wow once you've got the test runner doing some stuff. <jimbaker> SpamapS, sounds like a plan. i definitely want to hear more about james' ideas <jimbaker> SpamapS, we could readily add your bash scripts <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 <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 <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 <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 <jimbaker> (it might also be a useful ensemble subcommand in the future, don't know) <SpamapS> Not sure what you mean <SpamapS> I wrote a wait4state perl script that just runs status <niemeyer> jimbaker: This looks nice: https://github.com/defunkt/pystache <SpamapS> but /win 10 <SpamapS> doh <jimbaker> niemeyer, looks good to me, thanks! <jimbaker> SpamapS, but /win... ? <SpamapS> irssi <SpamapS> hey quick python question <SpamapS> do lists keep an internal length? <niemeyer> jimbaker: It's an incarnation of this: http://mustache.github.com/ <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) <niemeyer> SpamapS: They do <niemeyer> SpamapS: Are you doing tons of those calls? <SpamapS> yes <niemeyer> SpamapS: function calls in Python are expensive in general.. you may just be seeing that cost <jimbaker> niemeyer, yeah, mustache is a fine approach <SpamapS> 5 for every line of a 500,000 line file.... <SpamapS> So I'm not crazy.. its not a massive expense per call.. but it adds up <jimbaker> SpamapS, doesn't seem to be so much even for cpython <niemeyer> SpamapS: Yeah, definitely.. you'd notice 2.5M Python function calls for sure <SpamapS> http://paste.ubuntu.com/680217/ <jimbaker> so there, we have two contrasting viewpoints <SpamapS> now to find out where the other 8.8s are spent. :-P <niemeyer> jimbaker: You mean you don't find them expensive? <jimbaker> niemeyer, i just don't think it's that bad if it's just 2.5M <niemeyer> jimbaker: <jimbaker> niemeyer, functional call overhead in cpython is obviously quite expensive, for a variety of reasons <niemeyer> def f(): pass <niemeyer> start = time() <niemeyer> for i in range(2500000): f() <niemeyer> print time()-start <niemeyer> jimbaker: This takes 1 second in my machine <niemeyer> jimbaker: Doing absolutely nothing <niemeyer> jimbaker: There's more than a function call there, but gives an idea <jimbaker> niemeyer, i'm sure that's the case :) <niemeyer> jimbaker: That's what I meant by "you'd notice" <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 ;) <jimbaker> but if run in a command, or in the direct path for rendering a page, sure, it's extremely noticeable <SpamapS> That, and things like .append, .sort, etc, are the only function calls.. <SpamapS> this script lags the same algorithm in perl by about 15% <SpamapS> I was wrong btw, it doesn't do 5 for every line <SpamapS> just 1 len for every line <SpamapS> but yeah, 500,000 is 0.504s <jimbaker> SpamapS, did you try it w/ pypy? that would be an interesting exercise <SpamapS> jimbaker: I wanted to but didn't know how to even get pypy ;) <jimbaker> functional call overhead w/ pypy is extremely reduced <niemeyer> Yeah, should kick ass <SpamapS> lol.. lucid, karmic, and jaunty.. :-P <jimbaker> http://pypy.org/download.html - just give it a try, i don't know where they are on latency <niemeyer> Takes 16ms in Go.. <niemeyer> The 2.5 <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 <jimbaker> (i too should give it a try ;) ) <niemeyer> Maybe.. haven't tried that kind of thing there yet.. would be curious, though <niemeyer> Given their latest work it must be pretty amazing <jimbaker> bbl <SpamapS> pretty hard to find pypy binaries.. :-P <_mup_> Bug #838568 was filed: push-review must be tested again <Ensemble:In Progress by niemeyer> < https://launchpad.net/bugs/838568 > <niemeyer> Alow! <hazmat> jimbaker`, jinja2 is pretty nice re templating engines <_mup_> ensemble/local-provider r353 committed by alexanderlisa@example.com <_mup_> remove utility wait_for_node, just make the nesc. method public on zookeeperconnect, allow get open port to take a host option. <jimbaker`> hazmat, jinja2 is fine. but let's go with mustache <hazmat> jimbaker`, wasn't clear that mustache has any advantage over say.. string.Template <hazmat> er.. actually string formatters <hazmat> mustache looks fine though <jimbaker`> hazmat, mustache does one very important thing, which is that it performs html encoding <jimbaker`> when compared to string.Template. obviously the mustache {{}} itself is familiar in both templating systems <niemeyer> jimbaker`: and loops, I guess <niemeyer> Lunch time.. biab! <SpamapS> niemeyer: can we get push-review from a PPA or something? <SpamapS> niemeyer: I *really* like the automation it promises. :) <_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 > <SpamapS> hazmat: re the bug linked above.. <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.. <SpamapS> but I could be wrong <SpamapS> indeed.. its just a matter of how you checked out the branch <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 <hazmat> SpamapS, sounds good <SpamapS> hazmat: http://pastebin.com/DaaJ1Mp0 <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. <SpamapS> (with the 3 patches I've submitted for review applied.. ;) <niemeyer> SpamapS: Absolutely! Working on that already.. should be apt-gettable today <jcastro> hey m_3 <jcastro> http://blog.carbonfive.com/2011/09/01/deploying-node-js-on-amazon-ec2/ <_mup_> Bug #839794 was filed: Final test for the tool! <Ensemble:In Progress by niemeyer> < https://launchpad.net/bugs/839794 > <jcastro> would now be a good time to ask how the node standalone formula is coming along? <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..." <m_3> jcastro: hey <m_3> jcastro: yeah, the node formula was part of a talk I gave on IRC a few weeks ago <m_3> jcastro: I'll brush it off, promote it to principia, and blog about it <jcastro> m_3: do you have time to post a response to the guy? <jcastro> it reads to me like he needs ensemble hard core <m_3> jcastro: yeah, I'll do it during a boring talk this afternoon <jcastro> oh sorry, forgot you were travelling <m_3> jcastro: conf wraps up today, so I'll be able to put time on it over the weekend <negronjl> jcastro: ping <jcastro> negronjl: pong <negronjl> jcastro: in a meeting right now.. I'll ping you later * jcastro nods <_mup_> ensemble/local-unit-deploy r354 committed by alexanderlisa@example.com <_mup_> factor out unit environment retrieval into separate method. <_mup_> ensemble/local-unit-deploy r355 committed by alexanderlisa@example.com <_mup_> user/environment qualified lxc container name, tweak upstart job <_mup_> ensemble/local-unit-deploy r356 committed by alexanderlisa@example.com <_mup_> additional test for qualified container name <hazmat> SpamapS, does upstart do env expansion on the exec stanza? <SpamapS> hazmat: yes <niemeyer> Okay.. lpad is out, lbox is out.. back to reviews and porting formulas <niemeyer> But I'll step out for now.. may do some extra time tomorrow for helping on the queue * niemeyer bbl <_mup_> ensemble/local-unit-deploy r357 committed by alexanderlisa@example.com <_mup_> have upstart respawn and run the container in the foreground, doc strings for all container deployment methods. * robbiew needs a drink <hazmat> excellent idea <SpamapS> hazmat: upstart for containers, but not for the agents?! <hazmat> SpamapS, for the agent <hazmat> unit agent only <hazmat> inside a container <hazmat> its not truly restartable.. probably shouldnt' be respawn auto * hazmat returns with a bloody mary <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. <SpamapS> task tsk.. we need our idempotency. :) <SpamapS> :) * hazmat reruns tests to ascertain potency <SpamapS> oh I thought you were saying that its not re-startable because of some problem with idempotency <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 <SpamapS> err.. events? <hazmat> no good reason not to go ahead with it i suppose <SpamapS> I thought we just watched to see what the state was <SpamapS> if we miss 4 changes, who cares, just make the new state true. <hazmat> SpamapS, if the agent is down, watches won't be delivered <hazmat> and extant watches need to be restablished as new watches potentially <SpamapS> if we need that, we need a queue, not a data store <SpamapS> But I see what you're saying <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 <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. <SpamapS> Thats not a queue.. thats a watched data store. <hazmat> yup <SpamapS> Convenient, yes, but not a queue. :) <hazmat> its really a sync between a remote and local data store <hazmat> to compute the delta <SpamapS> I see the problem.. very interesting <hazmat> in truth its probably a very rare issue in practice for a respawn <hazmat> for a net split its more significant <hazmat> or any long running outage <SpamapS> yeah, so at the moment, ensemble is not partition tolerant. ;) * SpamapS disappears <hazmat> SpamapS, have a good weekend <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 <jimbaker`> niemeyer, ^^^ ? <_mup_> ensemble/local-unit-deploy r358 committed by alexanderlisa@example.com <_mup_> use ensemble home instead of units directory for all unit deployments <hazmat> jimbaker`, i think you just push to ~jimbaker/ensemble/generate-html <hazmat> its on the merge side you pick the series branch afaik * hazmat checks <jimbaker`> hazmat, ok, i was wondering why it was wanting to use the wrong series <hazmat> yup <hazmat> jimbaker`, so on merge the target branch is ensemble/ftests <hazmat> there all branches of the same project for the user project namespace <hazmat> s/their <_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 > <hazmat> jimbaker`, is the ftest stuff using jenkins for test running? <jimbaker`> hazmat, no <hazmat> just wondering if we could submit tests for branches in dev <hazmat> via an api <hazmat> w/ the security integration tests get about 30% slower out of the box on average... <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 <hazmat> jimbaker`, i guess i'm confused what's running the tests? your not using jenkins or buildbot? <jimbaker`> i'm using two new tools: butler.py, which i just wrote; and niemeyer's churn, which executes bash scripts <jimbaker`> a butler used to manage the buttery, which might store the results of the churning... <jimbaker`> and of course jenkins is presumably a butler. whatever ;) <hazmat> not sure i understand why.. but okay <jimbaker`> hazmat, at some point jenkins is presumed. twisted trial however is definitely not going to be used <jimbaker`> the reason is that we need something that is focused on running ensemble commands <hazmat> jimbaker`, i assume the test runner would be doing normal tests and ftests <hazmat> is that not accurate? <jimbaker`> that's not accurate <jimbaker`> it's only running ftests, which are to be only be written using bash <jimbaker`> that's niemeyer's decision, and it makes sense <hazmat> from a purpose of ease of test dev for users probably <jimbaker`> such test scripts could potentially use resources that are written in python, eg to validate results or to wait for resources <hazmat> still i seems like conflating issues, an ftest suite and test suite, and the test bot <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 <hazmat> jimbaker`, fair enough.. we need a test runner for the ftests that does reports <jimbaker`> and that's the merge proposal :) <hazmat> bcsaller, do you have a moment to catch up? <bcsaller> hazmat: sure do <hazmat> bcsaller, ~hazmat/ensemble/local-unit-deploy is the latest in the pipeline <bcsaller> hazmat: thanks <niemeyer> jimbaker`: lbox propose --for lp:ensemble/ftests <niemeyer> Sorry, single dash <niemeyer> jimbaker`: lbox propose -for lp:ensemble/ftests #ubuntu-ensemble 2011-09-03 <niemeyer> jimbaker`: Run this within the branch directory and it'll do the whole magic <marrusl> hey folks... so if I set "default-instance-type: m1.large" ... what should I do to change the default AMI to 64-bit? <marrusl> should I dig up the ami number manually? or can I set the architecture in environments.yaml? <marrusl> I mean "dig up the ami # manually and set default-image-id? or..." <_mup_> ensemble/lib-zookeeper-base r316 committed by alexanderlisa@example.com <_mup_> Merge base for lib-zookeeper. <hazmat> marrusl, it looks like you need to manually select the image for 64 bits <marrusl> hazmat, ok. in any case I did end up doing that. no problems. thanks for the confirmation. #ubuntu-ensemble 2011-09-05 <_mup_> ensemble/machine-with-type r337 committed by alexanderlisa@example.com <_mup_> machine state includes provider type <kim0> Hey folks .. is LXC deployment actually working right now <kim0> Another questions, is Ensemble known to run successfully client-side and cloud-side on Ubuntu 10.04+ ? <hazmat> kim0, no to both <hazmat> kim0, there used to be some compatible fixes for 10.04 cloud-init, but those got yanked, so it no longer works <kim0> hazmat: so supported versions are 11.04+ ? <hazmat> the lxc work is in dev, i'm hoping to get it to a testing state for those who want to try off a branch by the end of the week, but first plumbers <kim0> client and cloud ? <hazmat> kim0, for client 10.04 is fine <hazmat> for the cloud portion we need 11.04 or newer <kim0> got it <kim0> thanks <hazmat> np <hazmat> kim0, are you going to be at plumbers? <kim0> nope <kim0> Dustin is however <hazmat> kim0, oh.. i thought you where co-track lead? <hazmat> k <fwereade> hazmat: btw, I have done my best to review everything, but I ended up a bit tired by the time I got to bcsaller's LXC branch -- can I ask you to pick that one up please? <hazmat> fwereade, absolutely <hazmat> fwereade, also fwiw today's a national holiday in the us <fwereade> hazmat, cheers :) <fwereade> hazmat: ah, I missed that <hazmat> so the review queue might be sitting through till tomorrow.. i'll try to dig into some of that today though <fwereade> hazmat: no rush, I don't mean to demand you work on a day off ;) <hazmat> i'm going to spend most of the day getting ready for a presentation on wednesday anyways <hazmat> fwereade, no worries, wasn't planning on taking the day off * niemeyer waves <fwereade> niemeyer: heyhey <fwereade> niemeyer: hope you're ok? <niemeyer> fwereade: Yeah, mostly alright <fwereade> glad to hear it :) <niemeyer> fwereade: Thanks to modern medicine :-) <fwereade> niemeyer: what happened? <niemeyer> fwereade: Fuzzed around with a minor tooth issue a bit too much and made it into a bigger issue <fwereade> niemeyer: ouch :( <fwereade> niemeyer: I'd been vaguely wondering if you were, I dunno, into extreme mountain fighting or something ;) <niemeyer> fwereade: Haha, no.. I might feel less silly if that was the case, though :-) <niemeyer> fwereade: Thanks for the docstring changes <niemeyer> fwereade: Very nice to have it being standardized <niemeyer> fwereade: I'm slightly concerned it might be going overboard in terms of syntax in some cases.. not sure if the benefit of the linkage is worth the reduced readability in the code itself <niemeyer> fwereade: Simple example: <niemeyer> - @param instance_id: instance_id of the `ProviderMachine` you want. <niemeyer> vs. <niemeyer> 316 + :param str instance_id: :attr:`instance_id` of the <niemeyer> 317 + :class:`ensemble.machine.ProviderMachine` you want. <hazmat> it reads better html <niemeyer> hazmat: Yeah, I'm just not sure if the benefit of the linkage in HTML is worth the reduced readability in the code itself <niemeyer> hazmat: I suspect we'll be reading the code more often than the HTML <hazmat> niemeyer, yeah.. that particular example is a bit obtuse <hazmat> and self referential <fwereade> I did wonder about that, but I found it very hard to justify not having stuff linked if it were there <fwereade> I felt on balance that the awesomeness of the linkage made up for the ugliness of the code, for the simple reason that when we're reading the code we're reading the *code* -- I trust docstrings about as much as I trust comments, which is to say not at all ;) <fwereade> and so I end up viewing the docstrings as targeted more to a reader of the docs than a reader of the code <hazmat> fwereade, instance_id = opaque string identifier specific to the provider <hazmat> fwereade, where you able to build the html output? <fwereade> I was, yes, are yu having problems? <hazmat> fwereade, haven't tried.. jim mentioned some issue, wasn't clear if it was endemic or not <hazmat> fwereade, was that with the code linked using autodoc? <fwereade> hazmat: I didn't end up hitting jim's issue, so I'm not sure if it's waiting to trip me up as I rationalise the rest, or whether it was just an artifact of his approach <niemeyer> Will get some "food".. biab <hazmat> niemeyer, cheers <fwereade> hazmat: instance_id -- yes, I know; but I don't follow your train of thought <fwereade> hazmat: they're also how we identify machines at the provider level <hazmat> fwereade, ah.. i think i missed the context of the diff <hazmat> i thought that was on a provider machine, but ic now its actually more likely get_machine <fwereade> hazmat: I'd be sympathetic to an approach in which we used machine_id throughout, but it doesn't seem very convenient atm ;) <hazmat> fwereade, but you are using autodoc when building the html output? <fwereade> hazmat: yes, but I have a little script that does more than and less than that script jim linked the other day to build the structure we want <fwereade> hazmat: I output a very few directives basically just saying "autodoc this module here" <fwereade> hazmat: but the resulting structure is (IMO) nicer, and tests get excluded withot enormous hassle <fwereade> hazmat: anyway, I must dash, ttyl :) * hazmat lunches <hazmat> fwereade, cheers <hazmat> niemeyer, the formulas/ -> formulas- change was to accomodate openstack's s3server which didn't like the "/" separator on a key name <hazmat> i'm not entirely sure why as the trunk code of it, seems to do the right thing with the key (hash on key name b4 store in dir).. its possible its interacting poorly with the route dispatch logic <hazmat> but it seemed more expedient to change our storage key then pushing the fixes upstream... <hazmat> kirkland, ping <niemeyer> hazmat: WTF, seriously? <hazmat> niemeyer, indeed <niemeyer> hazmat: Cool, thanks for the explanation.. +1 <hazmat> niemeyer, its the bug where upstream explicitly noted s3 compatibility isn't a goal.. https://bugs.launchpad.net/nova/+bug/829880 <_mup_> Bug #829880: object store doesn't like key with '/' <Ensemble:Triaged by hazmat> <OpenStack Compute (nova):Confirmed> <ensemble (Ubuntu):New> < https://launchpad.net/bugs/829880 > <niemeyer> hazmat: Yeah, it's just not clear anymore why we're even talking about S3 in this context now <hazmat> niemeyer, well it is *just* enough s3 for ec2 compatibility.. which is all ensemble needs as well atm.... <niemeyer> hazmat: Yeah, I commented on it even.. it just wasn't so obvious to me until now that it's another beast entirely <hazmat> ah * hazmat gets back to work on his presentation <hazmat> niemeyer, also fwiw, i'll be offline most of tomorrow morning, entransit to plumbers <niemeyer> hazmat: Sounds great, thanks for your assistance today, btw <thebishop> hello, I'm interested in the new "Orchestra" feature. I know it's not the primary use, but can Orchestra be used as a Proxmox "private cloud" replacement as well? <hazmat> thebishop, proxmox ve looks like a commericial ovirt?... orchestra+ensemble+openstack is effectively auto private cloud provisioning.. its not clear what exactly proxmox ve is doing outside of providing a web ui ontop of a virt mechanism (kvm or openvz) <hazmat> ah.. ic http://pve.proxmox.com/wiki/Vision <hazmat> so ensemble does real encapsulation at a service level instead of just virtual image appliance management <hazmat> but it doesn't include backup/restore builtin or live migration atm <hazmat> lxc support for the latter features is still in the works <hazmat> ugh.. i really want to use the local dev for the talk <_mup_> ensemble/machine-with-provider-type r359 committed by alexanderlisa@example.com <_mup_> pull machine-with-type into local dev pipeline <_mup_> ensemble/no-regex-option r338 committed by alexanderlisa@example.com <_mup_> Dropped unused class var, as pointed out by William. <_mup_> ensemble/trunk r337 committed by alexanderlisa@example.com <_mup_> Merged no-regex-option branch [r=fwereade,hazmat] <_mup_> This removes the regex configuration type, and renames 'str' to 'string'. <_mup_> For the second change, it also introduces backwards compatibility logic <_mup_> so that we can continue to work with 'str' for the moment while we warn <_mup_> authors to move out of it. <_mup_> ensemble/trunk r338 committed by alexanderlisa@example.com <_mup_> Merged simplify-iface-schema branch [r=hazmat,fwereade] <_mup_> Minor simplification in the implementation of the interface schema. <_mup_> ensemble/go r3 committed by alexanderlisa@example.com <_mup_> Merged go-iface-schemas branch [r=fwereade,hazmat] <_mup_> This kicks off the formula schema support in the Go port. <_mup_> ensemble/go r4 committed by alexanderlisa@example.com <_mup_> Merged go-initial-formula-meta branch [r=fwereade,hazmat] <_mup_> This introduces metadata.yaml parsing in the Go port. <_mup_> ensemble/go r5 committed by alexanderlisa@example.com <_mup_> Merge go-rename-short-types branch [r=hazmat,fwereade,jkakar] (!) <_mup_> This makes the schema.M/L types more readable, as suggested by Kapil. <_mup_> ensemble/go r6 committed by alexanderlisa@example.com <_mup_> Merged go-final-formula-meta branch [r=fwereade,hazmat] <_mup_> This completes the parsing of metadata.yaml in the Go port. <_mup_> ensemble/go-formulas r14 committed by alexanderlisa@example.com <_mup_> Added formula(_test).go files with the generic bits that were <_mup_> all together in alexanderlisa@example.com. <_mup_> ensemble/go-formulas r15 committed by alexanderlisa@example.com <_mup_>
{'channel': 'ubuntu-ensemble', 'month': 9}