#ubuntu-ensemble 2011-04-11
<niemeyer> Hmm.. time to sort out UDS arrangements now that I have a passport again
<niemeyer> hazmat: Good morning
<hazmat> niemeyer, good morning!
<niemeyer> hazmat: How's the upgrade stuff coming?
<niemeyer> hazmat: Just trying to get a grasp of what we'll be presenting at UDS, etc
<hazmat> niemeyer, pretty good, i finally got the workflow stuff figured out, and i've got some of that coded out, the actual mechanism was pretty easy, just figuring out error conditions and recovery took some time
<niemeyer> hazmat: Interesting, cool
<niemeyer> hazmat: So how does the time frame feel for you?
<hazmat> niemeyer, upgrade will be done by then, i can probably fit one more feature on my plate.. or a bunch of useability things
<hazmat> shutdown with warning, some more sample formulas, ensemble scp.. etc
<niemeyer> hazmat: Nice, cool.. I think that'd be best indeed
<niemeyer> hazmat: Our formulas need some love indeed
<hazmat> niemeyer, i setup a monitoring / alerting system over the weekend for some folks.. i'm starting to think we need a new abstraction around the 'machine policy'/formula
<niemeyer> hazmat: Interesting, what kind of alerting system was that?
<hazmat> niemeyer, just munin and nagios
<niemeyer> Ok
<niemeyer> hazmat: Yeah, we have to discuss the whole placement idea
<hazmat> i tried out this nice visualization on collectd which was pretty slick.. scripted it all with fabric.. their probably going to move over to chef at some point
<niemeyer> hazmat: What about Ensemble?
<hazmat> niemeyer, i've discussed it with them, their interested, but their not up for living on the bleeding edge
<niemeyer> hazmat: Understandable
<hazmat> niemeyer, still one of the nicer collectd visualizations i've used.. http://ec2-174-129-219-53.compute-1.amazonaws.com:9292/profiles/shotgun+graph
<hazmat> all jquery flot ui
<hazmat> https://github.com/auxesis/visage
 * niemeyer looks
<niemeyer> Nice
<kim0> niemeyer: Hey Gustavo o/
<kim0> Are you ok with the weekly progress meeting 
<kim0> the one I mentioned in email
<niemeyer> kim0: Hi there
<kim0> can we do it on Wed for example
<niemeyer> kim0: Hmmm, but I thought we already had a weekly meeting?
<kim0> niemeyer: the server team one ?
<niemeyer> kim0: No, the weekly meeting we have in 37 minutes :-)
<kim0> I'm talking about a public irc meeting 
<kim0> niemeyer: I'm in a call .. sorry for not being too focused
<niemeyer> kim0: Ok, let's talk latter then.. I have to have lunch too
<kim0> sure thing
<niemeyer> Laters
<niemeyer> kim0: Meeting time?
<kim0> niemeyer: ew sorry, suddenly my internet is at 60% packet loss
 * kim0 recovering
<niemeyer> kim0: No worries
<niemeyer> kim0: Regarding the weekly meeting you were proposing earlier, what kind of content would you like to have on it?
<niemeyer> hazmat: Are you subscribed to the public Ensemble list?
<hazmat> niemeyer, i believe so
 * hazmat checks
<niemeyer> hazmat: Ah, I guess you've seen my answer
<hazmat> niemeyer, yeah.. i had my reply drafted for a while but needed to transfer from thunderbird to sup
<niemeyer> :-)
<niemeyer> hazmat: Might be cool to send the same msg to the public one too
<hazmat> niemeyer, oh.. didn't realize it was private only
<jimbaker> it's ensemble@lists.ubuntu.com - i thought that was public
<hazmat> jimbaker, it is
<hazmat> jimbaker, the original email came in @lists.canonical.com which is private, and my reply wen there as well
<jimbaker> hazmat, ok, but in my case i see the reply to the list mentioned above
<niemeyer> jimbaker: My reply, not his
<hazmat> hmm.. there are two replies in two different threads
<niemeyer> Yep
<hazmat> gustavo is referring to my reply in the 1st time user thread which was private
<hazmat> er. on the internal list.. i just forwarded it to the public one
<jimbaker> hazmat, yeah i see the distinction now - ahmed's vs clint's
<bcsaller> hazmat: I've mostly refactored out a YAMLState object which handles some of the issues we talked about re retry change but allowing BadVersionErrors to bubble through would change semantics and I'm not sure what that we mean in the live system yet
<hazmat> bcsaller, awesome!
<hazmat> bcsaller, a base class or utility that generically handles dictionary merges for retry change sounds like a good win
<bcsaller> Its a state object you bind to the node and then delegate to
<bcsaller> pseudo-code:: hook.get(): returnValue(relation_node.get())
<hazmat> bcsaller, as for the error condition, its handling its going to be context sensitive.
<bcsaller> yeah, I'll get this in its own branch and push it so we can talk about the same thing, I need a little feedback before its ready for a merge
<hazmat> bcsaller, sounds good
<_mup_> ensemble/yaml-state-node r183 committed by bcsaller@gmail.com
<_mup_> initial work on YAMLState object
<kim0> niemeyer: hey ... my internet is unchocked again :)
<kim0> niemeyer: so I was talking about the email "Ensemble community venues"
<kim0> basically would like to setup a weekly irc meeting where the team mentions progress about ensemble development
<kim0> this should pick up community members going forward
<kim0> Since the conversation drifted to whether or not we should freeze formula definitions ..
<kim0> would be great if you and the team could reply letting me know whether you guys agree on that 
<bcsaller> hazmat: lp:~bcsaller/ensemble/yaml-state ensemble/state/utils.py when you have a minute to talk it over, doesn't have to be now
<niemeyer> kim0: I don't have any email with that subject (or something related) coming from you
<kim0> niemeyer: it's on the public list
<kim0> niemeyer: everyone else replied 
<kim0> niemeyer: kim0@ubuntu.com
<niemeyer> kim0: "from:kim0@ubuntu.com venue" returns an empty list to me
<kim0> niemeyer: https://lists.ubuntu.com/archives/ensemble/2011-April/000020.html
<kim0> niemeyer: your reply to that would great .. nothing urgent .. tyt
<hazmat> kim0, i agree that it makes sense, post budapest.. i've been keeping an itinerant ensemble development newsletter going, but i've been waiting for things to queue up before writing it
<kim0> would be*
<niemeyer> kim0: I never got that
<kim0> niemeyer: weirdo ?!
<kim0> hazmat: I'm fine with post budapest
<kim0> niemeyer: spam filters ?
<niemeyer> I have no idea.. I'm a member
<niemeyer> kim0: I got your previous message too
<kim0> yeah weird indeed
<kim0> niemeyer: you didn't even get replies from others
<niemeyer> Nope
<niemeyer> I didn't get Kapil's fwd yet either
<kim0> quite strange
<kim0> just forwarded you the thread 
<niemeyer> kim0: Thanks, I'm looking through the archives
<_mup_> ensemble/unit-agent-formula-upgrade r199 committed by kapil.thangavelu@canonical.com
<_mup_> additional documentation of the steps, clear upgrade flag before proceeding with ugprade work
<hazmat> niemeyer, could you have a look at my comments regarding the state-machine branch? should i put it back into review? re needs information status on the merge.
<niemeyer> hazmat: Yeah, please put it back
<niemeyer> hazmat: That WIP <=> Needs Review back and forth is a neat way to very easily know who's got the ball ATM
<hazmat> niemeyer, agreed, sounds good.
<jimbaker> agreed on the WIP/NR state transition, it just works
<niemeyer> hazmat: We'll have to talk a bit about the transition stuff.. it feels like the simplicity of a state machine is derailing a bit 
<hazmat> niemeyer, yeah.. i'm diagramming it at the moment
<hazmat> niemeyer, i'm not sure i need the action handler 
<hazmat> niemeyer, it looks like i'll end up structuring the upgrade transitions as a transtion from state X to state X
<hazmat> with the success transition to follow
<hazmat> the question is what's the best handling of an upgrade-error
<niemeyer> hazmat: Yeah, loops are good abstractions in state machines
<niemeyer> hazmat: We can put it in an upgrade-error state, but in that sense it feels a bit like we're doing the opposite of what we should do
<niemeyer> hazmat: What do we want to happen?
<niemeyer> hazmat: We shouldn't be talking about the state machine, but about the goal
<niemeyer> hazmat: The state machine will reflect it
<hazmat> niemeyer, agreed
<niemeyer> We might: a) Stop the unit world;  or b) Log and move on
<hazmat> the question is what's the best handling of an upgrade-error.. do we want to re-exec the upgrade hook, do we want to continue with the last known pre-ugprade step.. or just have a definite procedure.. of redo install-start
<niemeyer> hazmat: Reexecuting implicitly feels bad
<hazmat> niemeyer, sure, we do both a+b
<niemeyer> hazmat: Looking at packages, upgrade hooks are not really idempotent in most cases
<hazmat> niemeyer, the case i'm asking about is someone trying to recover manually an upgrade error
<hazmat> do we just expose transition something like transition to state("x") where x is running, stopped?
<hazmat> more generically do we have a definite sequence of hooks we want to have happen, or do we want let the user specify hooks to run or state to try and achieve.
<niemeyer> hazmat: Seems like too much knowledge would be needed
<niemeyer> hazmat: We need something people can more easily reason about
<niemeyer> hazmat: E.g. "ensemble recover unit/1" simply unblocks the unit and puts it back in the state the last transition was trying to achieve
<hazmat> hmm
<niemeyer> hazmat: Or perhaps, "ensemble resolved unit/1"
<hazmat> niemeyer, looks good
<hazmat> niemeyer, i prefer recover, it suggests actions to be performed, rather than noting something already done.
<niemeyer> hazmat: Since it's not really an action.. it's simply informing that "I have resolved the issue"
<niemeyer> hazmat: Exactly, the intention is the latter
<niemeyer> hazmat: We won't be doing the action.. the user is supposed to resolve the problem himself
<hazmat> niemeyer, hm... so your suggesting we don't execute the transition?
<hazmat> for failure recovery
<niemeyer> hazmat: Right, not by default at least
<niemeyer> hazmat: We can have
<niemeyer> hazmat: ensemble resolved --retry
<hazmat> niemeyer, what about an exposing an easy way to run an abitrary hook?
<hazmat> also useful for the debugging hooks scenarios
<niemeyer> hazmat: Feels pretty invasive..  formulas are not built with the idea that hooks can be run in arbitrary moments
<niemeyer> hazmat: The user can go into the machine and run it manually, if they wish to
<hazmat> niemeyer, this is more an advanced tool for formula authors or motivated users.
<hazmat> niemeyer, not in the proper environment without a debug running which needs hook execution to trigger fully
<niemeyer> hazmat: Sure, we can have a debug command for that, no worries with that
<niemeyer> hazmat: But this should not be documented anywhere, if you see what I mean
<niemeyer> hazmat: This is far from a workflow we want to encourage
<bcsaller> simulating the context for relation hooks might be a bit strange there too
<niemeyer> hazmat: Yep
<hazmat> niemeyer, i see your point yeah its not something we want to expose.. users shouldn't need to care about this... but in the real world they often do ;-)
<niemeyer> hazmat: That's why "ensemble resolved" feels more "grounded"..  If a hook exploded in-flight, we have no idea why
<niemeyer> hazmat: Let the user debug it and then type "ensemble resolved" to restore normal operation
<niemeyer> hazmat: They don't, actually.. I don't see people typing "postrm" manually
<niemeyer> Or postinst...
<hazmat> niemeyer, true, but the formula-author might having inspected its logs, and fixed the hook, and might just want to run 'dpkg' again for example
<hazmat> the --retry works
<niemeyer> hazmat: Yes, they remove and reinstall the package.. that works for us too :)
<kim0> niemeyer: just replied .. letting you know in case you don't get it 
<niemeyer> hazmat: So I guess, going back to the original point, we have to introduce "ensemble resolved", and then make an error transition to upgrade-error or the such
 * kim0 mostly afk now on
<niemeyer> hazmat: and then transition back with resolved
<niemeyer> kim0: I got it
<kim0> niemeyer: hmm, what does driving that meeting entail? Is it like the server meeting chair
<niemeyer> kim0: It is about taking care of organizing it, collecting topics for it, and in general ensuring it stays sensible and useful to everyone involved.
<kim0> sounds good
<kim0> No problem, volunteering :)
<niemeyer> kim0: Awesome, thanks!
<kim0> niemeyer: when do we start? this week or after udso
<niemeyer> kim0: You tell me.. I'll be happy to attend it this week already :)
<kim0> niemeyer: well I have no problem announcing the meeting publicly and starting from this week. As mentioned don't expect much attendance for the first period, but everything should be kept public from day one. Mostly it's gonna be about team members talking the current state of ensemble ..etc, and if you're ok with it, I'm definitely ok having it this week
<niemeyer> kim0: Sure, let's do it then
<kim0> awesome .. deal
<niemeyer> kim0: It's important to be a bit prepared for it
<niemeyer> kim0: Rather than simply inviting us to speak
<kim0> Tips are welcome
<niemeyer> kim0: You can always keep an eye on what's happening here: http://people.canonical.com/~niemeyer/budapest.html
<niemeyer> kim0: If you participate in the team in Launchpad, you can also watch reviews passing by
<niemeyer> kim0: So it should be very easy to keep track of what the most interesting conversations/actions happening
<kim0> well yeah, except non devs like me don't particularly enjoy reading patches :)
<kim0> but yeah sure
<niemeyer> kim0: Yeah, I'm not suggesting that
<niemeyer> kim0: Patches always have textual descriptions accompanying them, and a bug attached
 * kim0 nods
<_mup_> ensemble/trunk-merge r184 committed by kapil.thangavelu@canonical.com
<_mup_> merge trunk
<niemeyer> kim0: You should also feel free to poke people that don't describe what they're doing well.
<kim0> Ok ... so making sure devs can speak in plain English
<niemeyer> kim0: I'll be happy to explain better something I slack when describing in a review, for instance.
<kim0> I can do that :)
<niemeyer> kim0: Right, exactly
<kim0> got you
<niemeyer> kim0: Our docs also have been improving a lot
<niemeyer> kim0: Features should generally be accompanied by a doc patch/improvement
<niemeyer> kim0: If they are not, that's a good thing to poke about
<kim0> I'm planning on contributing to that soonish too
 * niemeyer pokes jimbaker  ;-)
<kim0> Yes.. excellent point
<jimbaker> niemeyer, poked
<niemeyer> kim0: If you can't figure what's happening, no one else will
<kim0> True .. got your point
<kim0> niemeyer: thanks for tips .. we'll definitely improve with time as well
<niemeyer> kim0: You're welcome, and thanks for organizing this
<kim0> rock n roll the service management space :)
 * kim0 afk for real this time .. :)
<kim0> btw does Ensemble have a logo/mascot 
<kim0> or is someone working on one rather
<hazmat> kim0, definitely.. perhaps a musical instrument on a cloud background
<kim0> hazmat: definitely means someone is working on it ? or you'd love to :)
<hazmat> kim0, love to have it
<kim0> ah hehe
<kim0> I'd love to .. would give a nice visual ID
<jimbaker> http://en.wikipedia.org/wiki/File:Zentralfriedhof_Vienna_-_Boltzmann.JPG
<jimbaker> related to the other meaning of "canonical ensemble" ;)
<kim0> is that blotzman the scientist
<jimbaker> kim0, yes
<hazmat> jimbaker, yeah.. looking at http://en.wikipedia.org/wiki/Machine_learning_ensemble i almost think of a mathematical E symbol over a cloud might be cool as well
<kim0> of "constant" fame hehe
<kim0> we need a bunch to choose from :)
<kim0> okie dokie .. I'll see who I can bribe to work on this :)
<jimbaker> hazmat, it is cool how such ensembles do perform nicely - similar i guess to doing metanalysis of study results to boost signal
<jimbaker> bcsaller, hazmat, niemeyer - i really want to have lunch. should we do our standup?
<niemeyer> jimbaker: Sure, let's do it
<niemeyer> Or maybe not?  Where's everyone? :)
<jimbaker> looks like it's just hazmat who is not visible to me
<niemeyer> jimbaker: Nevermind.. go have your lunch
<niemeyer> jimbaker: We can catch up later/tomorrow
<jimbaker> just the time of year when DST ensures this standup window falls right in the middle of lunchtime
<jimbaker> ok, sounds good, i'm making progress
<niemeyer> jimbaker: We should also move the standup if it's right in your lunch time
<niemeyer> jimbaker: I'm sure we can find another suitable time that works for the three of us
<jimbaker> if we start on time (75 minutes ago), it's fine. it's just the variance on the window time that makes me starve :)
<hazmat> doh.. sorry got a snack
<hazmat> also making progress
<bcsaller> I am as well
<_mup_> ensemble/state-machine-enhancements r203 committed by kapil.thangavelu@canonical.com
<_mup_> support for firing transition with fuzzy match on transition
<_mup_> ensemble/unit-agent-formula-upgrade r202 committed by kapil.thangavelu@canonical.com
<_mup_> lifecycle integration of upgrade-formula hook
<hazmat> apport concurrent report productivity kill
<hazmat> niemeyer, irc as other medium or skype?
<niemeyer> hazmat: Skype would probably work better
<hazmat> niemeyer, ready when you are
<niemeyer> hazmat: Cool, just a moment
<niemeyer> hazmat: I'm up
<SpamapS> niemeyer: re-reading my post, it may have been a bit dramatic and overriden my point that I don't feel comfortable suggesting people start playing with it without some kind of release strategy.
<niemeyer> hazmat: ensemble upgrade --force 
<niemeyer> hazmat: ensemble resolved --retry
<niemeyer> hazmat: id + "_upgrade_" + id
<niemeyer> SpamapS: So, off meeting
<niemeyer> SpamapS: We just have to be honest about the project state
<niemeyer> SpamapS: We've been doing pretty well in terms of compatibility so far
<niemeyer> SpamapS: and it feels like the ground we're building is quite solid
<niemeyer> SpamapS: But there's no point in making blank statements right now.. the project works at all for a couple of months
<jimbaker> biab, need to take my daughter to her doctor checkup
<niemeyer> SpamapS: If we decide to make changes, there will be some very good background to them, and you'll be in the loop
<SpamapS> niemeyer: Indeed I think its time to bring on early adopters who may actually use it for something... its only going to be *very* aggressive users who will use it w/o an official release.
<niemeyer> SpamapS: We'll have releases.. we're just walking towards it
<niemeyer> SpamapS: We're working on important features right now which are also critical for these same users which care about the release
<niemeyer> Alright, I'll step out for some exercising.. bbl likely
<SpamapS> niemeyer: sounds good. Glad we're on the same page then. :)
<_mup_> ensemble/state-machine-enhancements r204 committed by kapil.thangavelu@canonical.com
<_mup_> backout of matching or alias tranasitions
<hazmat> something quite strange
#ubuntu-ensemble 2011-04-12
<_mup_> ensemble/unit-agent-formula-upgrade r203 committed by kapil.thangavelu@canonical.com
<_mup_> upgrade workflows
<_mup_> ensemble/new-hook-semantics-5-docs r196 committed by jim.baker@canonical.com
<_mup_> New hook semantics editing, along with more general copy editing of the formulas section
<_mup_> ensemble/yaml-state-node r184 committed by bcsaller@gmail.com
<_mup_> When setting same content even different cached node version don't raise error 
<_mup_> This is similar to the behavior of retry_change as used in the state/hook.py code. If however the change is different a BadVersionError will be raised. This commit fixes a small typo that vexed me far too long.
<_mup_> ensemble/config-state-manager r186 committed by bcsaller@gmail.com
<_mup_> using YAMLState object for config_get/set
<_mup_> Bug #758583 was filed: Should refactor out pattern of applying changes to zookeeper nodes <Ensemble:New> < https://launchpad.net/bugs/758583 >
<_mup_> ensemble/state-machine-enhancements r205 committed by kapil.thangavelu@canonical.com
<_mup_> restore match support, to build alias functionality
<_mup_> ensemble/state-machine-enhancements r206 committed by kapil.thangavelu@canonical.com
<_mup_> morph matching into transition aliases and document
<_mup_> ensemble/state-machine-enhancements r207 committed by kapil.thangavelu@canonical.com
<_mup_> alias transition property
<hazmat> niemeyer_lunch, ping me when you've got a moment, i wanted to talk about recording workflow transition cycles
<niemeyer> hazmat: Cool
<niemeyer> There's a server meeting starting in #ubuntu-meeting right now
<niemeyer> Since we qualify as "server team" now, it'd be good to participate
<kim0> IS can be slow to get sites up
<kim0> feel free to give me the ticket number and I'll pester them some more :)
<niemeyer> kim0: Yeah.. cool, will hand it in a momment
<kim0> We're on the tubez https://twitter.com/#!/ubuntucloud/status/57846045803159552
<kim0> spread the love :)
<jimbaker> kim0, like the appropriate background image
<kim0> jimbaker: hmm surprisingly I'm just getting blue background for now
<kim0> jimbaker: you're see'ing the "clouds" image right
<kim0> Twiter must be coserving bandwidth or something :)
<jimbaker> yes, it looks like an african savanna setting too
<jimbaker> those trees in the image always remind me of the pbs nature program - i must have a concept neuron for that :)
<hazmat> niemeyer, up for that upgrade discussion now?
<niemeyer> hazmat: Yeah, let's do it
<hazmat> niemeyer, just ping me on skype when your ready
<niemeyer> hazmat: Already ready
<jimbaker> how much does txaws actually work with eucalyptus for issues around buckets? the description of bug 725082 implies to me that it's our usage of txaws that's causing this problem, but i don't see any support for that
<_mup_> Bug #725082: DNS error when specifying a different S3 URI <Ensemble:In Progress by jimbaker> < https://launchpad.net/bugs/725082 >
<SpamapS> Ok.. now that I've had coffee and I'm well fed I can rationally discuss updating principia for ensemble. :)
<SpamapS> I've opened 2 bugs in principia to update all the hooks and the formulate/proof tools
<SpamapS> And I got to thinking.. can we have _mup_ watch principia's bug tracker?
<jimbaker> in particular it seems to fail within txaws.s3.client.URLContext and how that interacts with query submission
<jimbaker> i looked at both txaws trunk and 0.0.1, they produce the same problems (and don't seem to differ here). also, there doesn't seem to be any testing with respect to walrus. now comparing against boto, which has seen some love from eucalyptus devs
<jimbaker> SpamapS, did you have a chance to look at my updated version of lp:~jimbaker/ensemble/bashified-wordpress-mysql-examples ?
<SpamapS> jimbaker: no. :( I have no time whatsoever again... bugs must be fixed! ISO's must be tested! ;)
<jimbaker> i should also push my latest version of some editing i did on the formula docs... may need to split it out, since i did a lot of copy editing, not just updates related to new hook semantics
<jimbaker> SpamapS, not a problem!
<jimbaker> just thought it might help focus with the conversion since imho, it actually makes things easier than the previous semantics
<SpamapS> not to mention the impending doom I feel as my talk is now 27 hours away and I have approximately 2 slides.
<jimbaker> SpamapS, oh... what's this?
<SpamapS> not ensemble
<SpamapS> talking about Drizzle in natty
<SpamapS> at the MySQL user's conference
<jimbaker> ok, you're going have to rally on that
<SpamapS> I have the esteemed advantage of talking in the final spot of the day, so I can run short and nobody will demand a refund from O'Reilly :)
<jimbaker> but feel free to come here for help on slides for anything ensemble related, we should be able to pump stuff out
<SpamapS> I really wish OSCON didn't close their CFP so early.. I'd love to talk about Ensemble there. :-P
<jimbaker> SpamapS, it's a little late for this talk - but i found that writing slides in rst is so much better... and then converting to a presentation to a fellow canonical employee's tool, rst2pdf
<SpamapS> http://www.cloudcamp.org/sandiego/2011-06-14
<SpamapS> here's an idea tho!
<jimbaker> http://lateral.netmanagers.com.ar/stories/BBS52.html
<SpamapS> jimbaker: not a bad idea! I was thinking of doing console presenter..
<SpamapS> :)
<jimbaker> (that's roberto alsina's blog and tool)
<SpamapS> But no.. I have some fun visuals to throw out with my word play on natty natalia near a wall narwhal fizzle with sizzle for drizzle my nizzle
<jimbaker> i found it super, super, super easy
<jimbaker> but i guess it's because i hate so much formatting code for presentations, and in this case, no such need , since pygments does the work for me :)
<SpamapS> If I didn't have to fix this PHP bug I'd even get my example blog deployed w/ ensemble. ;)
<SpamapS> jimbaker: hmm.. so you can embed images too..
<jimbaker> cloudcamp looks like a good venue
<SpamapS> this may actually be worth converting
<jimbaker> SpamapS, yeah, it does work pretty well
<jimbaker> i just used the standard ubuntu pdf viewer (whatever that is) for my talk at pycon, but there are some good choices to do interesting transitions too
<hazmat> jimbaker, bcsaller standup?
<bcsaller> sure
<hazmat> jimbaker, so your saying txaws has euca support?
<jimbaker> hazmat, apparently this may be more than what is offered then :)
<hazmat> jimbaker, skype?
<jimbaker> i do know there's mention of eucalyptus support in the code
<jimbaker> hazmat, just logging on as it approaches 6p utc
<jimbaker> i'm just getting some weird static output on the skype call right now
<jimbaker> i'm going to hang up, please call me back in
<hazmat> jimbaker, calling
<jimbaker> hazmat, switching to my os x laptop, something's wrong here w/ my natty laptop
<hazmat> jimbaker, cool
<jimbaker> hazmat, try call me back in now, i think rebooting fixed my natty laptop's sound
<jimbaker> (i can everybody now, so that's much better than weird static popping noises!)
<hazmat> lxc in natty seems kinda of broken
<jimbaker> hazmat, in what way?
<hazmat> jimbaker, as in it fails several different ways when attempting to use it
<hazmat> there's a new ubuntu-template for various releases.
<hazmat> creating a natty one.. and then trying to execute bash in it.. or start it. fails. with different error messages, tried copying /usr/lib/lxc/lxc-init.. and installing libcap, but still fails.. all different error messages, all inscrutable to me
<hazmat> jimbaker, are you working on the status thing?
<hazmat> jimbaker, i've started implementing a unit workflow zk accessor  thingy which was also needed for status
<hazmat> just curious
<hazmat> no pushed branch on it afaics
<niemeyer> OMG, can't believe inbox is empty again
<niemeyer> If I didn't answer a mail someone sent me, please ping me because I've missed it for real :)
<jimbaker> hazmat, i have just started working on the this before getting pulled onto other things
<jimbaker> the zk accessor stuff sounds useful
<hazmat> jimbaker, so i can mark the bug 737949 as unassigned?
<_mup_> Bug #737949: ensemble status should take into account unit and relation workflows and unit agent status <Ensemble:In Progress by jimbaker> < https://launchpad.net/bugs/737949 >
<jimbaker> hazmat, i guess that's ok. i would still prefer to finish my work on it however
<jimbaker> what sort of api are you considering for the zj accessor? is this just implementing the load-only version of the WorkflowState classes (what i'm dubbing ObserveUnitWorkflowState, etc)?
#ubuntu-ensemble 2011-04-13
<hazmat> http://gigaom.com/cloud/vmware-open-source-cloud/
<hazmat> jimbaker, yup.. i named it workflowclientstate to distinguish
<hazmat> er. workflowstateclient
<hazmat> it would also make sense as a method
<niemeyer> "Gustavo Niemeyer (niemeyer) has assigned this bug to you for Ensemble:"
<niemeyer> It'd be cool if Launchpad knew that "Gustavo Niemeyer" and "you" are the same person
<_mup_> ensemble/bashified-wordpress-mysql-examples r180 committed by jim.baker@canonical.com
<_mup_> Addressed review points re comments and db check
<_mup_> ensemble/bashified-wordpress-mysql-examples r181 committed by jim.baker@canonical.com
<_mup_> Merged trunk
<jimbaker> hazmat, i like the quote "[mongodb evp] says it took about three months to integrate MongoDB with Cloud Foundry"
<jimbaker> surely the average app won't take any longer than that
<jimbaker>  hazmat, ok, i will wait for this branch so we don't duplicate work
<jimbaker> it's obviously pretty minimal
<_mup_> ensemble/bashified-wordpress-mysql-examples r182 committed by jim.baker@canonical.com
<_mup_> Get the public hostname for wp config
<_mup_> ensemble/bashified-wordpress-mysql-examples r183 committed by jim.baker@canonical.com
<_mup_> Comment on the secret key used in wp config
<kim0> hey guys .. is the principia repo now broken ?
<kim0> how hard is it to fix it
<kim0> niemeyer: I wanted to ask if now we have some simple path for contributing formulas. I suppose that's a good topic to discuss within today's irc meeting
<kim0> I am aware of previous discussions to customize launchpad for that purpose .. but that's probably more long term 
<niemeyer> kim0: Yeah, right now the easiest path is simply to publish them in whatever form and expect people to download them 
<niemeyer> kim0: The repository is on the pipeline
<kim0> ok .. I'll bring that up today
<kim0> niemeyer: the other thing .. I understand principia is currently broken due to ensemble updates ? What would it take to fix it to match ensemble head
<kim0> I was wanting to contribute a doc page about usage, but that needs a working formula :)
<niemeyer> kim0: It would actually be very simple to fix it
<niemeyer> kim0: I'm hoping to get a hand from SpamapS in the near future to push that forward
<niemeyer> kim0: Feel free to bring that up in the meeting too
 * kim0 nods
<kim0> what caused the breakage ? a new hook .. trying to remember
<niemeyer> kim0: Yeah, we've split a single hook in three
<niemeyer> kim0: But it's trivial to fix because it was actually already three different hooks conflated into one
<niemeyer> kim0: So it's basically copy & pasting part of the content out of a file
<kim0> niemeyer: changed => {changed,established,broken} right ?
<niemeyer> jimbaker: Almost, changed => {joined, changed, departed}
<kim0> niemeyer: is joined a rename for established? same for departed/broken ? if so, I'll update docs
<niemeyer> kim0: It's not, I think jimbaker is already updating them, though
<kim0> ok
<niemeyer> kim0: He mentioned yesterday in the call he had a branch to push for review
<niemeyer> kim0: joined/changed/departed runs whenever a remote unit is detected/modified/removed in a relation
<niemeyer> kim0: established/broken is called when the unit executing the hook has been taken out of the relation by itself
<niemeyer> kim0: -broken means the world of that relation is gone.. -departed means a remote unit has left
<niemeyer> kim0: There may still be other units after -departed.. there's nothing after -broken
<kim0> niemeyer: so the last departed necessitates a broken, right
<niemeyer> kim0: That's right!
<niemeyer> hazmat: ping
<jimbaker> kim0, the docs are very confusing on that i think
<jimbaker> my doc branch should fix that, i will be pushing it for review sometime in the next couple of hours
<hazmat> niemeyer, pong
<niemeyer> hazmat: Hey there
<niemeyer> hazmat: It looks like your UDS registration is still pending
<hazmat> registration?
<niemeyer> hazmat: Can you please check Marianna's email to allhands?
<hazmat> i booked a ticket
<hazmat> k
<hazmat> oh.. missed that, thanks, bedless and badgeless sounds bad ;-)
<kim0> jimbaker: awesome :)
<_mup_> ensemble/new-hook-semantics-5-docs r197 committed by jim.baker@canonical.com
<_mup_> More copy editing
<_mup_> ensemble/new-hook-semantics-5-docs r198 committed by jim.baker@canonical.com
<_mup_> More copy editing. Removed unimplemented -relation-established hook description
<_mup_> ensemble/new-hook-semantics-5-docs r199 committed by jim.baker@canonical.com
<_mup_> Copy editing on relation settings
<_mup_> ensemble/unit-status-remote r200 committed by kapil.thangavelu@canonical.com
<_mup_> unit and unit relation remote workflow clients.
<_mup_> Bug #759981 was filed: The ensemble command line needs access to the workflow states of units and unit relations. <Ensemble:New> < https://launchpad.net/bugs/759981 >
<_mup_> ensemble/new-hook-semantics-5-docs r200 committed by jim.baker@canonical.com
<_mup_> Minor fix
<_mup_> ensemble/unit-agent-formula-upgrade r205 committed by kapil.thangavelu@canonical.com
<_mup_> merge unit-status-remote, throw away lots of upgrade workflow tests.
<jimbaker> kim0, i just pushed up lp:~jimbaker/ensemble/new-hook-semantics-5-docs for review
<_mup_> ensemble/bashified-wordpress-mysql-examples r184 committed by jim.baker@canonical.com
<_mup_> Better comments
<SpamapS> heh.. Marten Mickos talking about how FOSS has changed from "distribution centric" to "service centric" .. hmmm.. where have I heard that before? ;)
<_mup_> ensemble/unit-agent-formula-upgrade r206 committed by kapil.thangavelu@canonical.com
<_mup_> ensure that install error in agent is handled correctly (skips transition attempt to started)
<hazmat> niemeyer, so for units of a service just report they won't be upgraded since their not running, and upgrade those that are?
<_mup_> ensemble/bashified-wordpress-mysql-examples r185 committed by jim.baker@canonical.com
<_mup_> Removed unnecessary sudo
<hazmat> niemeyer, also on install_error.. ensemble resolved, would leave it at the installed state, right now post install, the agent moves things through to started. it seems like we should move it to the started state, but on a resolved without --retry from install_error  should we execute the 'start' hook, its not a retried hook, its a hook that hasn't been executed
<hazmat> else sans workflow manipulation the unit is in a terminal state
<hazmat> s/terminal/final
<niemeyer> hazmat: Sorry, I've been in an intense conversatin for the past hour or so
<niemeyer> Related to the repository tech
<hazmat> niemeyer, cool  w/ lp folks?
<niemeyer> hazmat: Yeah, sounds good regarding the upgrade=reporting+upgrade rest
<jimbaker> i have pushed up an updated version of lp:~jimbaker/ensemble/bashified-wordpress-mysql-examples for review, this might be useful for people writing formulas
<niemeyer> hazmat: I think install_error+resolved should move it to installed so that start is run normally
<niemeyer> hazmat: No, with ISD
<_mup_> ensemble/unit-agent-formula-upgrade r207 committed by kapil.thangavelu@canonical.com
<_mup_> filtering and reporting for unit state on upgrade.
<_mup_> ensemble/unit-agent-formula-upgrade r208 committed by kapil.thangavelu@canonical.com
<_mup_> filtering and reporting for unit state on upgrade.
<niemeyer> kim0: What time is our meeting today?  In 3 minutes?
<kim0> niemeyer: yes
<kim0> :)
<jimbaker> are we meeting on skype?
<niemeyer> kim0: I have a meeting overlapping with it this week specifically :-(
<kim0> ew
<kim0> jimbaker: irc
<niemeyer> kim0: I'll keep an eye on it, though
<kim0> ok cool
<kim0> so let's jump over to #ubuntu-cloud
<kim0> and start rumbling
<kim0> jimbaker: can you please ping others who'd be joining
<hazmat> kim0, what's the cloud rumble topic?
<kim0> basically weekly overview of the development of ensemble
<kim0> let's talk there
<hazmat> kim0, sounds good
<jimbaker> bcsaller, we are meeting over in #ubuntu-cloud
<bcsaller> jimbaker: thanks
<jimbaker> SpamapS, others, feel free to join us
<hazmat> bcsaller, jimbaker anything to add in #ubuntu-ensemble
<bcsaller> not really
<hazmat> bcsaller, jimbaker, niemeyer postpone standup till tomorrow?
<bcsaller> hazmat: works for me
<niemeyer> hazmat: Hmm
<niemeyer> robbiew: Are you still up for it?
<robbiew> huh...what?
<robbiew> heh
<robbiew> niemeyer: I'm up for whatever ;)
<niemeyer> Cool, let's do it
<niemeyer> hazmat, bcsaller, jimbaker: Let's do a quick stand up with robbiew to talk about the reorg
<niemeyer> hazmat: Can you quick it off?
<jimbaker> ok, on skype?
<niemeyer> Yea
<niemeyer> h
<niemeyer> hazmat?
<robbiew> niemeyer: so having never conferenced in skype, is it just a simple means of having one person conference in everyone else?
<robbiew> I'm a mumble man, damn it!!! :P
<niemeyer> robbiew: Yeah, exactly :)
<niemeyer> robbiew: It feels like getting someone with more bandwidth to host has shown better results, which is why I generally ask someone else rather than just firing it off
<robbiew> ah, cool
<hazmat> niemeyer, sure
<hazmat> sorry.. zoned
<hazmat> robbiew, what's your skype id
<hazmat> robbiew, yeah.. its one person dialer
<robbiew> hazmat: robbie.v.williamson
<robbiew> very original
<niemeyer> kim0: Thanks a lot for the meeting.. that was awesome
<kim0> niemeyer: thanks man .. great work .. great team
<hazmat> kim0, indeed. thanks
<_mup_> ensemble/unit-agent-formula-upgrade r208 committed by kapil.thangavelu@canonical.com
<_mup_> upgrade --dryrun reports unupgradeable service units.
<_mup_> ensemble/unit-agent-formula-upgrade r209 committed by kapil.thangavelu@canonical.com
<_mup_> additional tests for upgrade-formula cli around unupgradeable units.
<kim0> hazmat: Hi, You had reviewed my tiny branch at https://code.launchpad.net/~kim0/ensemble/doc-fixes .. but it wasnt merged afaict .. should I rebase and bug you to merge it ? :)
<hazmat> kim0, yeah. i was looking at that earlier today.. if you wouldn't mind rebasing that would be great
<_mup_> ensemble/unit-agent-formula-upgrade r210 committed by kapil.thangavelu@canonical.com
<_mup_> hook execution prioritization support for upgrade-formula hook.
<_mup_> ensemble/unit-agent-formula-upgrade r211 committed by kapil.thangavelu@canonical.com
<_mup_> ensure mutation access to _running attribute of hook executor is always done with the run lock.
<hazmat> its a strange semantic to interact with prioritize through the workflow, with a stopped hook executor
<hazmat> the workflow responds to the hook exit, but we won't have that till the executor is restarted
<hazmat> i guess we restart it  inline.
<hazmat> yeah.
<_mup_> ensemble/unit-agent-formula-upgrade r212 committed by kapil.thangavelu@canonical.com
<_mup_> hook executor.prioritize now returns after the priority hook is scheduled, and returns the exec deferred of the priority hook, unit lifecycle.upgrade_formula will prioritize the upgrade-formula hook, and start the executor.
<hazmat> argh.. unity fail
<hazmat> mumble seems to cause issues with unity
<hazmat> at least for me
<jimbaker> bbl, i'm going to the boulder hadoop meetup. my neighbor is giving a talk on katta (distributed lucene), which uses zk to support its scaling
#ubuntu-ensemble 2011-04-14
<_mup_> ensemble/unit-agent-formula-upgrade r213 committed by kapil.thangavelu@canonical.com
<_mup_> make lifecycle.start deferred fire only after the initial service relation watch has completed processing, this gives a much better interaction within tests, as the unit relations will also be initialized, and zk communication done after the end of the start lifecylce method for test environments with existing relations (and also works fine with none)
<_mup_> ensemble/unit-agent-formula-upgrade r214 committed by kapil.thangavelu@canonical.com
<_mup_> additional upgrade workflow tests.
<niemeyer> Yo
<crazed> how does ensemble differ from CloudFormation?
<niemeyer> crazed: CloudFormation is a service to coordinate AWS specific functionality
<niemeyer> crazed: So I'd say it differs entirely :-)
<niemeyer> crazed: Ensemble takes care of the actual service deployment and maintenance
<niemeyer> crazed: and configuration, etc
<crazed> does it also handle launching aws resources?
<niemeyer> crazed: It does, yeah
<niemeyer> crazed: and shutting them down too
<crazed> i've been dropping stuff into userdata currently to launch chef-solo
<crazed> does ensemble make life easier?
<niemeyer> crazed: Yeah, absolutely.. that's the primary reason why we're working on ti
<niemeyer> it
<crazed> i'm reading through the documentation, don't have much experience with zookeeper unfortunately
<niemeyer> crazed: No other tool at the moment is really focused on the integration of services the way Ensemble does
<niemeyer> crazed: You can pretty much ignore it
<niemeyer> crazed: it's an implementation detail, not necessary for working with it
<crazed> how does ensemble handle service specific configurations? for example, i want to use some specific nginx configuration
<crazed> where do you store that config, and can it be populated with data based on the running environment
<niemeyer> crazed: Yes, to both, if I understand what you mean
<niemeyer> crazed: Formulas are the basic unit of deployment
<niemeyer> crazed: You can think about it as a package
<niemeyer> crazed: Formulas can communicate with each other through simple interfaces
<niemeyer> crazed: So you can create a frontend app and make it communicate with a postgres app
<crazed> i understand the higher level parts with the metadata, relations, etc
<crazed> i'm just trying to wrap my head around the config management part
<niemeyer> crazed: Ah, ok
<niemeyer> crazed: This part is one we're actively working on
<niemeyer> crazed: I think we have a published draft of the specification for you, hold on
<crazed> i like the relations/formulas a lot, i think that's an aspect missing from CloudFormation 
<crazed> seems ensemble takes care of that and config management
<crazed> which nothing else currenlty does, you have to string together a bunch of pieces to get that full package
<niemeyer> crazed: RIght, you get the exact spirit of why we're building it
<niemeyer> crazed: Sorry about the delay.. the document is misplaced
<crazed> definitely something i'm interested in, i do a lot of ec2 deployments
<niemeyer> crazed: Here is a useful link, for the moment:
<niemeyer> http://people.canonical.com/~niemeyer/ensemble/service-config.html
<niemeyer> crazed: Please note this is a specification which is being developed still, so it's not yet working
<niemeyer> crazed: But that's exactly how it will work
<niemeyer> crazed: Well, unless we get feedback which makes us change it
<crazed> i'm going to have to read this over, i'll hang out here though and help out where possible
<niemeyer> crazed: That's awesome, your EC2 experience on deployments is most welcome.  Thanks a lot.  
<_mup_> ensemble/yaml-state-node r185 committed by bcsaller@gmail.com
<_mup_> Provides a dict like interface around a Zookeeper node
<_mup_>     containing serialised YAML data. The dict provided represents the
<_mup_>     local view of all node data.
<_mup_>     `flush` pushes this information into the Zookeeper node.
<_mup_>     YAMLState(client, path)
<_mup_>     `client`: a Zookeeper client
<_mup_>     `path`: the path of the Zookeeper node to manage
<_mup_>     The state of this object always represents the product of the
<_mup_>     pristine settings (from Zookeeper) and the pending writes.
<_mup_>     All mutation to the dict expects the use of inlineCallbacks and a
<_mup_>     yield. This includes set and update.
<_mup_> ensemble/yaml-state-node r186 committed by bcsaller@gmail.com
<_mup_> added revert to return to pristine state
<_mup_> added sync (as a published name for _combine)
<_mup_> ensemble/config-state-manager r189 committed by bcsaller@gmail.com
<_mup_> service.config_get using new YAMLState
<kim0> Morning folks
<hazmat> unity multi touch is pretty slick
<TeTeT> was there a 'getting started' tutorial somewhere?
<TeTeT> reading docs/getting-started.rst ...
<TeTeT> do I need to get txaws and txzookeeper from source, or are there any packages available?
<hazmat> TeTeT, source atm
<hazmat> TeTeT, txzookeeper is in pypi though.. 
<TeTeT> hazmat: just built the txzookeeper package, as it had a debian dir in the branch
<hazmat> TeTeT, yeah.. i put together some packaging for a ppa a while ago, but we have setup any lp source build recipes to automate it
<hazmat> ^don't
<TeTeT> hazmat: how do I install txaws? python setup.py <argument>? What would be the argument?
<hazmat> TeTeT, i typically do it in a virtualenv.. 
<hazmat> TeTeT, actually the txaws python package should be fine for us.. unless your trying to use it with eucalyptus
<TeTeT> hazmat: yep, I do it in a natty vm at the moment
<TeTeT> hazmat: and unfortunately I would love to try it with UEC ;)
<hazmat> ah.. well in that case.. python setup.py develop or install will work.. 'develop' will link that directory to your python installation, install will copy it over.. 'virtualenv' is a python technique to isolate python packages from the system python.
<TeTeT> one step further: $ bin/ensemble
<TeTeT> error: No environments configured. Please edit: /home/ubuntu/.ensemble/environments.yaml
<TeTeT> hazmat: didn't know about virtualenv
<hazmat> TeTeT, so far so good. it created a sample config for you
<TeTeT> hazmat: so I dumped it in /usr/local ...
<hazmat> TeTeT, that's fine.. you'll just want keep track in the future in case your upgrading it.. 
<TeTeT> hazmat: ok
<TeTeT> now I need to find my amazon credentials first ... somewhere under account they are
<hazmat> TeTeT, fwiw, i do something like this https://pastebin.canonical.com/46144/
<hazmat> that allows me to just update the source directories with bzr and the latest versions are installed
<hazmat> alternatived you can manipulate PYTHONPATH environment variable to include the source of the each package
<hazmat> instead of messing with setup.py
<TeTeT> hazmat: not sure if I see through that yet - I'll have a look. I now added the aws credentials. is there an easy 'print hello world' like example?
<hazmat> TeTeT, ./bin/ensemble bootstrap  will startup a machine.. you can do ./bin/ensemble status  and ./bin/ensemble deploy --repository=examples mysql after that
<kim0> TeTeT: there's a "examples/" folder in there
<hazmat> TeTeT, i stuck a minimal walkthrough in examples/readme.txt
<TeTeT> kim0 + hazmat : thanks, trying that - how do I inform ensemble on which ssh key to use? I downloaded ensemble-key.pem to the vm, but where to place it?
<kim0> hazmat: do you know which branch uses the new hooks (joined, departed) ?
<hazmat> kim0, trunk
<kim0> hazmat: trunk has docs for that too
<kim0> ?
<hazmat> kim0, not yet.. that's in the review queue 
<hazmat> kim0, https://code.launchpad.net/~jimbaker/ensemble/new-hook-semantics-5-docs/+merge/57536
<kim0> awesome thanks
<kim0> hazmat: n00b question, why doesn't that branch (new-hook-semantics-5-docs) show in https://code.launchpad.net/ensemble 
<hazmat> TeTeT, you can put the ssh key into the environments.yaml and reference it by path or putting the contents of the public key there. by default it sniffs for a public key, and barfs it can't find one. the config setting for it in the environment is 'authorized-keys' for the content, or 'authorized-keys-path' to reference it by file path.
<hazmat> kim0, it does for me
<hazmat> 5th one down after trunk
<kim0> oh duh .. old page hehe
<kim0> I am not sure why "provides" must be satisfied
<TeTeT> so I copied my ensemble-key.pem to id_rsa.pub and I get this error: http://pastebin.ubuntu.com/594014/
<crazed> sounds like the aws signature is wrong
<TeTeT> crazed: does that mean access and secret key?
<hazmat> TeTeT,  yes.. it sounds like your access/secret key for aws might be wrong
<hazmat> s/sounds/looks
<TeTeT> hazmat: hmm, I use them from s3fox just fine
<TeTeT> hazmat: wouldn't I need to put my account id somewhere as well?
<hazmat> TeTeT, your access key / secret key effectively are your account id
<hazmat> TeTeT, do the ec2 cli tools work for you?
<TeTeT> hazmat: I'll give it a try
<hazmat> TeTeT, we don't use the private key / cert mechanism which is used for the ec2 soap api.
<hazmat> and the ec2 cli tools
<TeTeT> hazmat: works and apparently ensemble did bootstrap something: http://pastebin.ubuntu.com/594021/
<hazmat> TeTeT, cool! ./bin/ensemble status will tell you what it did :-)
<TeTeT> hazmat: unfortunately not:
<TeTeT> $ bin/ensemble status
<TeTeT> No Ensemble machines found. Is the environment bootstrapped?
<TeTeT> 2011-04-14 15:46:03,116 ERROR No Ensemble machines found. Is the environment bootstrapped?
<hazmat> TeTeT, hmm.. that's very strange, 
<hazmat> it looks like you launched machines,  and now their not visible to ensemble, did the settings change in between bootstrap and status?
<TeTeT> hazmat: yeah, is there a way to get more debugging output I might make available?
<hazmat> ensemble -v subcommand  turns up the cli logging
<TeTeT> hazmat: I changed the credentials one time, but I started another bootstrap
<hazmat> there's also distributed logging, but it more about observing system operation.. this problem sounds more fundamental
<TeTeT> here's bootstrap -v : http://pastebin.ubuntu.com/594030/
<hazmat> TeTeT, thanks thats helpful
<TeTeT> and that's status -v immediately thereafter: http://pastebin.ubuntu.com/594032/
<hazmat> TeTeT, so the problem is that we launch the machine via ec2.. that works fine.. but we get an error saving our 'map' to s3, we use the map to find out where things are in the environment.
<TeTeT> hazmat: the status is saved in the map?
<hazmat> TeTeT, the underlying problem though looks like an issue with txaws s3 
<hazmat> TeTeT, the instance-id to the bootstrap machine
<hazmat> or more specifically, the instance-ids of the ensemble zookeeper cluster machines
<hazmat> TeTeT, its not clear what version of txaws is being used, the traceback shows the package version being used
 * hazmat checks for differences
<TeTeT> hazmat: I used rev no 79 from bazaar and did the $ sudo python setup.py install
<hazmat> TeTeT, cool, yeah. its in /usr/local
<_mup_> Bug #760719 was filed: ensemble should verify s3 access before launching bootstrap nodes <Ensemble:New> < https://launchpad.net/bugs/760719 >
<TeTeT> he he, that was quick
<hazmat> TeTeT, yeah.. i've been using revno 68 of txaws, i'm updating now to try it out.
<hazmat> still not clear what the issue with s3 write is
<TeTeT> hazmat: confirm that reverting to 68 and doing an install over it seems to work - still launching a new instance
<hazmat> TeTeT, confirmed that the latest (rev 80) seems to  have issues
<TeTeT> still can't connect due to ssh problems - seems my key gets not injected correctly
<hazmat> hmm.. looks like python2.6 compatibility issues with the latest rev 80 of txaws
<hazmat> TeTeT, are you using a key from ssh-keygen ?
<TeTeT> hazmat: nah, I generated it via the web console - should I use euca-add-keypair for a change?
<TeTeT> hazmat: I would think natty has 2.7, so not sure if 2.6 is an issue
<hazmat> TeTeT, its not a provider key/cert.. its just an ssh-keygen key.. preferrably one for which you have the private side in .ssh 
<hazmat> then things like `ensemble ssh` just work
<hazmat> niemeyer, it looks like your merge of s3-bucket-paths to txaws broke ensemble bootstrap
<hazmat> and jamu's following yours broke python 2.6 compatibility
<niemeyer> hazmat: Ugh, seriously?
<niemeyer> hazmat: How did it break it?
<hazmat> niemeyer, yup
<hazmat> niemeyer, re s3.. http://pastebin.ubuntu.com/594030/
<niemeyer> hazmat: I actually tested the changes in practice against S3 with the command line tools within txaws
<hazmat> niemeyer, cool, it could just be something we have to update in our usage.
<niemeyer> hazmat: Hmm.. wait.. I think the changes after the review were not tested
<niemeyer> hazmat: Let me have another look at that
<niemeyer> hazmat: I'll just finish the review I'm doing and will check it out
<hazmat> niemeyer, great, thanks
<kim0> folks .. I've just written my understanding of a trace of how hooks would trigger for the sample wordpress formula .. It's at http://j.mp/fUOgbF .. Would someone please check/correct it ?
<niemeyer> hazmat: I won't be able to look at this right now, sorry.. the review took some time, and I have to get lunch to attend a meeting in less than an hour
<niemeyer> hazmat: If you don't get to it first, I can check it out after the meeting, though
<hazmat> niemeyer, sounds good, i'm trying to get back into the upgrade stuff
<hazmat> kim0, looking
<kim0> hazmat: the relation is called "db" in this case
<kim0> I'm tracing this particular example
<hazmat> kim0, i can put it back.
<kim0> not too important
<kim0> what's the green highlight
<hazmat> kim0, if you run ensemble debug-log .. before the deploy you'll see it all
<kim0> hazmat: great!
<hazmat> kim0, you can filter to just hook execution as well
<hazmat> --include hook
<kim0> what's the green highlight
<hazmat> kim0, those hooks don't exist
<kim0> hazmat: yeah .. so the sequence is correct .. but the hooks dont exist in this case, right
<hazmat> yup
<kim0> great .. are you done with it 
<hazmat> yup. looks good
<kim0> hazmat: thanks :)
<kim0> I feel much more confident now hehe ;)
<kim0> understanding hook firing sequence is pretty important
<kim0> hazmat: I think it'd be useful to merge that trace to the readme file .. to me that was about the most confusing thing about ensemble
<hazmat> kim0, definitely, sounds good to me.
<kim0> cool .. branching .. proposing
<hazmat> the examples can be improved a bit, jim's got some bashified version which may change the sequence
<kim0> hazmat: I was actually reading from the bashified
<hazmat> kim0, cool
<kim0> yeah
<_mup_> Bug #760818 was filed: debug log is initialized too late in the unit agent startup, to catch install/start hooks <Ensemble:New> < https://launchpad.net/bugs/760818 >
<jimbaker> kim0, i think it would be good to expand the formula example section with this information
<jimbaker> hazmat, i don't think the sequence changes in the bashified version
<kim0> jimbaker: I just proposed it for merging into your bashified branch
<jimbaker> kim0, ahh, sounds good
<jimbaker> kim0, i'm unable to see your branch proposal
<kim0> woot
<jimbaker> but i did get the email about it
<kim0> jimbaker: it's the next one 
<kim0> jimbaker: https://code.launchpad.net/~kim0/ensemble/adding-hook-traces-to-readme-for-bashified-example/+merge/57716
<jimbaker> kim0, i think for your branch proposal you may need to explicitly mention my branch as a dependency, it was hard for to me read because my branch changes were mixed with yours since it was a diff against trunk
<kim0> because I initially proposed it into lp:ensemble
<kim0> then deleted that
<kim0> and proposed into your branch
<jimbaker> kim0, got it, now that is much clearer
<kim0> yeah :) first time to propose merging into other branch :)
<jimbaker> kim0, i still got it messed up a couple of weeks ago with a bunch of stacked branches
<jimbaker> add to redo the proposals
<jimbaker> s/add/had
<kim0> jimbaker: I was actually surprised this always failed:  bzr push lp:~kim0/ensemble/bashified-wordpress-mysql-examples/adding-hook-traces-to-readme
<jimbaker> launchpad is powerful, but nonobvious some times
<kim0> I concluded it wasn't possible to push 2 level stacks or something ?!
<jimbaker> kim0, never tried that style, but it looks like something unsupported for sure :)
<kim0> felt natural to me hehe :)
<jimbaker> kim0, it would be nice if the merge proposal did catch that you had branched something besides trunk, and so therefore needed that branch dependency in place
<jimbaker> i think that would be more natural
<kim0> yeha
<jimbaker> hazmat, i want to establish something, so to speak; the <relation name>-relation-established hook is not implemented, right? it was discussed in the docs (In formula.rst), which i updated in my docs branch proposal
<jimbaker> but unless it's hiding really well, it's not in the code
<hazmat> jimbaker, we did away with it
<jimbaker> hazmat, good. because i noticed that kim0 mentions this hook in his trace analysis
<jimbaker> but apparently such phantom hooks can leave the impression of being there :)
<jimbaker> hazmat, i had removed it in my branch proposal, we just need to update the mentioning text in kim0's proposal, and it will be gone forever i hope. (unless we need to actually implement it)
<hazmat> jimbaker, sounds good
<hazmat> there where challenges around implementing it, and utility became a question, since the first hook always executed is relation-join 
<hazmat> s/where/were
<jimbaker> hazmat, agreed, it seems like -relation-joined is sufficient for this case
<_mup_> ensemble/unit-agent-formula-upgrade r215 committed by kapil.thangavelu@canonical.com
<_mup_> revert r213, having start execute return after initial watch callback
<_mup_> ensemble/unit-agent-formula-upgrade r216 committed by kapil.thangavelu@canonical.com
<_mup_> upgrade formula error handlers that shutdown hook execution.
<niemeyer> jimbaker: That's the danger of documenting stuff without a notice about whether it's implemented or not.
<jimbaker> niemeyer, indeed
<_mup_> ensemble/unit-agent-formula-upgrade r217 committed by kapil.thangavelu@canonical.com
<_mup_> redo hook executor prioritize, instead as run immediate hook execution while stopped, bypassing the queue, and allowing us better control of hook executor start/stop status from lifecycle methods
<niemeyer> hazmat: Interestingly, I can't reproduce the signature failure with a hand-made test case
<niemeyer> hazmat: Nevermind, reproduced a bug when listing the bucket
<hazmat> niemeyer, cool
<_mup_> ensemble/unit-agent-formula-upgrade r218 committed by kapil.thangavelu@canonical.com
<_mup_> update executor tests with new renamed run priority hook method
<hazmat> we're almost at 1k unit tests
<niemeyer> Wow
<jimbaker> bcsaller, hazmat, niemeyer - standup?
<hazmat> soudns good
<niemeyer> jimbaker: If there are no pressing issues, I'd be happy to skip it today
<hazmat> niemeyer, i'm curious about the repository discussion
<jimbaker> niemeyer, sounds good, i can proceed immediately to lunching then :)
<niemeyer> I've been involved in a bunch of things and don't feel like I've really produced much yet.. I'd like to get this fixed and the rest of branches reviewed
<niemeyer> Well, cool
<niemeyer> hazmat, jimbaker: let's do it
<niemeyer> We can do an *actual* standup :)
<hazmat> bcsaller, ping?
<jimbaker> niemeyer, sounds good, keep us focused
<bcsaller> yeah, here
<hazmat> bcsaller, skype?
<bcsaller> hazmat: with all the desktop crashes with natty I sometimes forget to log back in :(
<bcsaller> hazmat: dropped, back now
<niemeyer> hazmat: https://code.launchpad.net/~niemeyer/txaws/fix-path-with-bucket/+merge/57753
<_mup_> Bug #761015 was filed: FORMULA_DIRECTORY should be available to hooks <Ensemble:New> < https://launchpad.net/bugs/761015 >
<_mup_> ensemble/unit-agent-formula-upgrade r219 committed by kapil.thangavelu@canonical.com
<_mup_> extract formula_download from machine agent into utility function
<_mup_> Bug #761053 was filed: Formula state should carry a referenced to a download url <Ensemble:New> < https://launchpad.net/bugs/761053 >
<_mup_> ensemble/unit-agent-formula-upgrade r220 committed by kapil.thangavelu@canonical.com
<_mup_> note the relevant bug url by the implementation
<niemeyer> jimbaker: ping
<hazmat> bcsaller, put some comments on the yaml-state proposal
<bcsaller> hazmat: still working on it but its pretty close to whats up there, thank you for looking at it :)
<jimbaker> niemeyer, hi
<niemeyer> Yo
<_mup_> ensemble/status-workflow r201 committed by jim.baker@canonical.com
<_mup_> Collect workflow state for service units and their relations
<_mup_> ensemble/status-workflow r202 committed by jim.baker@canonical.com
<_mup_> Cleanup
<_mup_> ensemble/unit-agent-formula-upgrade r221 committed by kapil.thangavelu@canonical.com
<_mup_> additional agent upgrade tests.
 * niemeyer => execrising
 * niemeyer => exercising even
<_mup_> ensemble/unit-agent-formula-upgrade r222 committed by kapil.thangavelu@canonical.com
<_mup_> minor prereview cleanups
#ubuntu-ensemble 2011-04-15
<niemeyer> Hi all!
<jimbaker> niemeyer, hi
<niemeyer> jimbaker: Hey man
<jimbaker> niemeyer, hi. just working on algebra with my 10 year old daughter
<jimbaker> (which incidentally is a lot of fun)
<niemeyer> jimbaker: Nice, I can imagine
<TeTeT> success! after adding a key with ssh-keygen as hazmat recommended, the bootstrap did succeed: http://pastebin.ubuntu.com/594364/
<TeTeT> hmm, I followed the example and now seem to have 3 instances running - how do I figure out on which instance my wordpress instance resides?
<TeTeT> ah, figure that machine: 2 refers to the list of instances ...
<TeTeT> http://ec2-184-72-176-29.compute-1.amazonaws.com/?p=3
<TeTeT> there we go!
<niemeyer> Good morning all
<hazmat>  niemeyer good morning
<niemeyer> hazmat: Yo!
<niemeyer> hazmat: How's... Shago!?  Not sure that's the proper way to pronounce the name
<hazmat> niemeyer, the workflow-state-client review suggestions sound great, thanks. i'm doing some write ups this morning on the async watch and constructors from yesterday. 
<niemeyer> hazmat: Ah, sweet, you're welcome
<hazmat> niemeyer, chego (as short for manchego) is doing great.. he's a getting a little older, but still quite playful. i moved a pillow next to my chair for him :-)
<niemeyer> hazmat: Re. the write up, thanks, looking forward to check it out
<niemeyer> hazmat: Aha, ok
<niemeyer> hazmat: Heard him barking the other day, and reminded of him
<niemeyer> hazmat: It's actually quite amazing how motivated he really is, given his age
<hazmat> niemeyer, indeed, he's pretty awesome, we started doing some regular short runs for him
<hazmat> 0.5 miles
<hazmat> or long walks
<niemeyer> Neat, he must be enjoying it
<niemeyer> hazmat: Btw, this is interesting: http://xph.us/2011/04/13/introducing-doozer.html
<hazmat> niemeyer, interesting
<niemeyer> hazmat: This is the most interesting thing from the whole announcement for us: "However ZK is getting a minitransaction API in the spirit of Sinfonia which should satisfy this need..."
<niemeyer> hazmat: It feels bad that the guy hasn't done a basic homework on ZooKeeper to understand how it works, though
<hazmat> niemeyer, agreed
<niemeyer> hazmat: Man, this is awesome: https://issues.apache.org/jira/browse/ZOOKEEPER-965
<niemeyer> It will make our life so much easier
<hazmat> niemeyer, indeed, we could actually construct transactions for our interactions
<hazmat> that would be awesome
<hazmat> niemeyer, i'm wondering if we also need service level relation data.. along the lines of service-config, but for relations.
<hazmat> i suppose we could say such is derived from the service-config
<niemeyer> hazmat: In which sense?
<hazmat> in the sense of making the relation between services take user defined config
<niemeyer> hazmat: Yeah, this is a case we have to discuss more
<niemeyer> hazmat: I hope we don't have to add something like this.. in a sense having less "buckets" of data is better for understanding
<niemeyer> hazmat: Use cases will tell, though
<hazmat> niemeyer, yeah.. its not clear that we do.. i'm just brainstorming
<hazmat>  still trying to figure out some of the machine/policy configuration in writing
<hazmat> going to take a walk around the block bbiab
<niemeyer> hazmat: Enjoy
<hazmat> niemeyer, that transaction stuff would be gold for the upgrade cli command, its piecemeal writing approach still makes me concerned about interruptions scenarios
<niemeyer> hazmat: Yeah, definitely
<niemeyer> hazmat: I don't think we have any real problems in terms of races, though
<niemeyer> hazmat: At least I don't see a reason yet
<_mup_> ensemble/unit-agent-formula-upgrade r223 committed by kapil.thangavelu@canonical.com
<_mup_> resolve some merge conflicts
<hazmat> hmm.. constructors with like 10 arguments are a little ugly..
<niemeyer> "a little" :)
<jimbaker> there should be a pep
<hazmat> niemeyer, re the workflow-state-client concrete bases, have a look at this and let me know what you think.. https://pastebin.canonical.com/46240/
<niemeyer> Looking
<jimbaker> hazmat, definitely a nicer separation at first look
<jimbaker> also for the testing of status, it looks like i can just use ZookeeperPersistentWorkflowStateBase without having to no-oping the disk methods, which  is much nicer
<hazmat> jimbaker, there's still a read only client there
<hazmat> and it does have to no-op the store
<jimbaker> hazmat, sure, that's what i need for the status
<niemeyer> hazmat: I still don't understand why this is so complex, to be honest
<jimbaker> what i'm describing is what is necessary for setup of testing for ensemble status
<hazmat> yup.. it was there before.. main difference functionally now is that its using classmethod constructors
<hazmat> before in that branch that is
<jimbaker> in this case i need the info stored to zk, preferably without just directly writing into the nodes, since there's a fair amount of logic re the history
<niemeyer> hazmat: Conceptually, the problem is so simple
<jimbaker> hazmat, but i would prefer to ignore storing to disk if possible
<hazmat> niemeyer, indeed, there are four operations and two sets of parameters and we want to configure and combine the behaviors.
<niemeyer> hazmat: Which four operations?
<hazmat> jimbaker, sure.. the state client classes should do what you want, effectively just with UnitWorkflowStateClient.from_domain_object(client, unit)
<hazmat> niemeyer, read state disk, write state disk, read state history, write state history, read zk state, write zk state.
<niemeyer> hazmat: There are two operations: write and read
<jimbaker> hazmat, yes, that also looks simpler
<niemeyer> hazmat: and the "combine" is actually "doing something in addition to"
<niemeyer> hazmat: Also, why is the state format different depending on where it's stored?
<hazmat> niemeyer, because on disk the state file is specific to the domain object, in zk we share with the rest of the domain objects of the unit (ie unit and relations states in one node)
<niemeyer> hazmat: No reason for the format to be different, even then
<jimbaker> hazmat, but i still need ZookeeperPersistentWorkflowStateBase in my case, since i want the test setup to store in zk, for the status collector to then read later with UnitWorkflowStateClient, etc
<hazmat> niemeyer, its not differently stored
<hazmat> niemeyer, each is a yaml serialization of the state dict
<niemeyer> hazmat: It is
<hazmat> where its stored is within the file is different, in zk we store in a node with other states, in the fs we own the file.
<niemeyer> hazmat: Well, the behavior is different
<niemeyer> hazmat: 
<niemeyer>         content = self._read_state_file()
<niemeyer>         if content is None:
<niemeyer>             return {"state": None}
<niemeyer>         return yaml.load(content)
<niemeyer> hazmat: It's write and read, really
<niemeyer> hazmat: The difference is where the data comes from
<hazmat> niemeyer, that same bit should be on the zk _load as well
<niemeyer> hazmat: Let me try provide a sketch
<hazmat> its not finished
<niemeyer> hazmat: I won't code it.. I'll try to demonstrate what I mean with a non-functional sketch
<hazmat> niemeyer, also out of curiosity did you see my mail to the list re async watchers and their creators?
<niemeyer> hazmat: Yes, I've already read it.. still thinking about it
<hazmat> i've been mucking with my outbound mail setup the last few days
<hazmat> cool
<niemeyer> hazmat: Re. what I said above, this is what I meant:
<niemeyer>         returnValue(
<niemeyer>             yaml.load(unit_data.get("workflow_state", {}).get(
<niemeyer>                 self._zk_state_key, "")))
<niemeyer> The stored value is different.. it feels like it could be the same
<hazmat> niemeyer, if i push workflow to a separate node sure
<hazmat> for each domain object
<niemeyer> hazmat: Or add the node to the other side
<niemeyer> s/node/key
<niemeyer> But that's minor I think
<niemeyer> Let me finish the sketch
<niemeyer> hazmat: http://paste.ubuntu.com/594567/
<hazmat> niemeyer, looks good
<niemeyer> hazmat: It's probably broken, but I think it can be made to work along those lines
<hazmat> niemeyer, yeah.. that cleans up the rest of the minor method dispatch
<hazmat> s/minor/excessive 
<hazmat> niemeyer, the one part that's missing is picking up the state directory to construct the path for fs_workflow_identity
<hazmat> but i can just pass in the directory as arg as it is now
<_mup_> ensemble/status-workflow r204 committed by jim.baker@canonical.com
<_mup_> Modified test setup in build_topology for test_status such that unit relation states are now created
<niemeyer> hazmat: Yeah, to the constructor of Disk, specifically
<jimbaker> hazmat, niemeyer, yes the proposed sketch looks even nicer to work with in terms of separating out disk storage concerns
<hazmat> niemeyer, looks good thanks
<niemeyer> hazmat: You're welcome, glad we're pushing this
<jimbaker> also it looks much easier to construct a desired state in the system w/o having to munge workflows - just transition it as desired. nice for testing, maybe even for the repair case that's also motivating things
<hazmat> the api was the same, but the sketch makes the code much nicer, consolidating  extraneous methods.
<hazmat> bcsaller, jimbaker, niemeyer standup?
<bcsaller> can I have 10 minutes?
<hazmat> sure
<jimbaker> hazmat, bcsaller, that works for me
<niemeyer> I'm good with skipping it today in the name of pushing things forward
<niemeyer> I'm having some trouble updating the Ubuntu Go packages, and still want to clear up the review queue before the end of my day
<jimbaker> niemeyer, also good for me
<bcsaller> gustavo: yeah, fine for me as well
<hazmat> sounds good
<_mup_> ensemble/unit-status-remote r201 committed by kapil.thangavelu@canonical.com
<_mup_> refactor the internals of unit and unit relation workflows to make the implementation simpler, per review and suggestion by gustavo.
<_mup_> ensemble/unit-status-remote r202 committed by kapil.thangavelu@canonical.com
<_mup_> use a single workflowstateclient for both units and unit relations.
<jimbaker> hazmat, just tried your new branch
<jimbaker> i'm getting WorkflowStateClient object has no attribute _workflow, which makes sense since this class var is not being set
<_mup_> ensemble/unit-agent-formula-upgrade r224 committed by kapil.thangavelu@canonical.com
<_mup_> resolve merge conflict from unit-state-remote
<jimbaker> new *version* of branch
<niemeyer> hazmat: Do you mind to compress these class names?
<hazmat> niemeyer, you mean we dont want State everywhere ;-)
<niemeyer> hazmat: It doesn't feel like ZookeeperPersistentWorkflowStateBase is better than ZookeeperWorkflowState
<hazmat> niemeyer, sounds good
<niemeyer> hazmat: Thanks!
<_mup_> ensemble/unit-agent-formula-upgrade r225 committed by kapil.thangavelu@canonical.com
<_mup_> bring back unit workflow methods, missed in conflict resolution.
<jimbaker> hazmat, just setting this classvarible to anything ("foo") allows for the WorkflowStateClient to work
<hazmat> jimbaker, yeah.. i added that in the last sec
<jimbaker> hazmat, cool
<hazmat> jimbaker, i'll fix that up
<_mup_> ensemble/unit-status-remote r203 committed by kapil.thangavelu@canonical.com
<_mup_> loosen workflow assertion in workflowstate.
<hazmat> jimbaker, fixed
<_mup_> ensemble/status-workflow r205 committed by jim.baker@canonical.com
<_mup_> Change to support WorkflowStateClient
<_mup_> ensemble/status-workflow r206 committed by jim.baker@canonical.com
<_mup_> Merged upstream
<_mup_> ensemble/unit-status-remote r204 committed by kapil.thangavelu@canonical.com
<_mup_> simplify base classes names.
<hazmat> niemeyer, done
<_mup_> ensemble/status-workflow r207 committed by jim.baker@canonical.com
<_mup_> Resolved conflicts
<_mup_> ensemble/unit-agent-formula-upgrade r227 committed by kapil.thangavelu@canonical.com
<_mup_> pep8 cleanup
<jimbaker> that's odd, somehow my last merge pulled in trunk instead of kapil's branch. so my branch is very confused now
<jimbaker> time to recreate
<jimbaker> actually that's not quite what happened - it pulled in an earlier version of kapil's branch. even worse
<hazmat> jimbaker, those branches are current with regard to trunk fwiw.
<jimbaker> hazmat, the problem was that somehow the old version of the clients (+ supporting code) was merged into my branch when i tried merging in your new code
<jimbaker> weird
<jimbaker> anyway, i just rebuilt the branch, which was easy since there were no common files
<jimbaker> maybe it got confused when i did the intermediate fix. no idea
<_mup_> ensemble/status-workflow-client r205 committed by jim.baker@canonical.com
<_mup_> Rebuilt branch from status-workflow
<_mup_> ensemble/unit-status-remote r205 committed by kapil.thangavelu@canonical.com
<_mup_> additional doc strings, and sample usage for workflowstateclient.
<niemeyer> hazmat: I still don't see the reason for us to introduce the action_id concept in Transition
<niemeyer> hazmat: We already have a transition id which should uniquely identify the transition, which means we can address that transition unambiguously an an action method
<hazmat> niemeyer, we probably don't need it,  with the workflow / lifecycle factoring the savings is pretty minimal from it
<niemeyer> hazmat: Cool, I'll add a point there suggesting the removal then
<hazmat> niemeyer, it was there when i had bunch of loop transitions, and they all wanted to do the same action.
<hazmat> but those are gone now
<niemeyer> hazmat: Sweet, that sounds good too :)
<hazmat> niemeyer, the alias thing, i'll probably going to use for the ensemble resolved --retry
<hazmat> the sans retry case requires some more thought to add a no hook mode for the scope of a transition.
<niemeyer> hazmat: Cool, it looks nice
<niemeyer> hazmat: I think it's just another transition
<niemeyer> hazmat: A simpler one, actually
<hazmat> niemeyer, the retry_upgrade.. specifically needs to restart hook execution
<niemeyer> hazmat: Ah, sorry, I understood it the other way around
<hazmat> most of the bookeeping by the lifecycle.start/stop also still needs to happen, its just we want to avoid doing user hooks, just bookeeping/accounting for the state transition.
<hazmat> niemeyer, after ugprade and debug-hook, should i continue on to ensemble resolved, or start in on some of the useability items?
<niemeyer> hazmat: resolved sounds good.. you have the whole context in mind, so it should be easy to get through it
<hazmat> niemeyer, indeed.. i'll start in on it.
<niemeyer> hazmat: That sounds awesome, thank you!
<_mup_> ensemble/unit-agent-formula-upgrade r228 committed by kapil.thangavelu@canonical.com
<_mup_> add missing test_formula module
<_mup_> ensemble/unit-status-remote r206 committed by kapil.thangavelu@canonical.com
<_mup_> update unit agent signature
<_mup_> ensemble/trunk r196 committed by kapil.thangavelu@canonical.com
<_mup_> merge unit-status-remote [r=niemeyer][f=759981]
<_mup_> Refactors the unit and unit relation workflow state internals, and introduces
<_mup_> a WorkflowStateClient that can be used to retrieve workflow state for
<_mup_> units, or unit relations from the cli.
<_mup_> ensemble/state-machine-enhancements r212 committed by kapil.thangavelu@canonical.com
<_mup_> yank transition action_id support
<niemeyer> hazmat: Just had a full read on the unit-agent-formula-upgrade branch.. it looks very good.  I'm not going to provide a full review now because I'm getting a bit sleepy by now.  I'll read it over again and on Monday and get the review in place, if that's alright.
<hazmat> niemeyer, sounds good
<hazmat> niemeyer, i've got some missing docs i'm going to add the branch to update the upgrade spec.
<niemeyer> hazmat: Cool
<niemeyer> Alright, I'll step out and take a nap
<niemeyer> Have a good weekend!
<_mup_> ensemble/unit-agent-formula-upgrade r231 committed by kapil.thangavelu@canonical.com
<_mup_> doc fixes and move clearing the flag earlier in the upgrade operation sequence.
<_mup_> ensemble/status-workflow-client r206 committed by jim.baker@canonical.com
<_mup_> Merged trunk
#ubuntu-ensemble 2011-04-16
<_mup_> ensemble/status-workflow-client r207 committed by jim.baker@canonical.com
<_mup_> Set state in ZK for service units and relation service units
<_mup_> ensemble/status-workflow-client r208 committed by jim.baker@canonical.com
<_mup_> Handle case that relation service units do not exist and test codepath
<_mup_> ensemble/unit-agent-formula-upgrade r232 committed by kapil.thangavelu@canonical.com
<_mup_> a few additional tests, and fixes.
<_mup_> ensemble/yaml-state-node r187 committed by bcsaller@gmail.com
<_mup_> YAMLState as a more complete proxy for dict.
<_mup_> This version requires that you call sync prior to a first mutation of the dict.
<_mup_> >>> node = YAMLState(client, path)
<_mup_> >>> yield node.sync()
<_mup_> >>> node["key"] = "value"
<_mup_> >>> node.update(otherdict)
<_mup_> >>> node["key"]
<_mup_> "value"
<_mup_> >>> yield node.flush()
<_mup_> ensemble/yaml-state-node r188 committed by bcsaller@gmail.com
<_mup_> test multiple sync provide a consistent view of state
