#ubuntu-ensemble 2011-03-24
<niemeyer_dinner> Man..
<niemeyer_dinner> Several hours attempting to fill the US visa form..
<niemeyer_dinner> Worst system ever
<niemeyer_dinner> Hint: Needed a browser-debugger to finish the process
<SpamapS> niemeyer: thats just the way we make sure only the best web developers visit. :)
<niemeyer> SpamapS: Hehe :)
<SpamapS> niemeyer: about 90 legitimate hits on that presentation.pdf so far..
<SpamapS> grepping out bots.. :)
<niemeyer> SpamapS: Wow, quite impressive
 * niemeyer => bed for reals
<niemeyer> SpamapS: Night!
<_mup_> ensemble/relation-get-bythespec r171 committed by linda89@example.com
<_mup_> cleanup of tests to directly show invocation of [relation-* args] commands
<_mup_>     Because of repeated issues in the hooks being changed or out of sync with the tests I took the time to remove many of the hook scripts that existed only to capture the arguments or calling convention around a relation-get/set/list command. This makes the tests easier to read and verify.
<kim0> Morning everyone
<kapil> g'morning folks
<niemeyer> kapil: Morning
<_mup_> ensemble/environment-config--selected-ami r178 committed by linda89@example.com
<_mup_> document ec2 provider configuration options, allow image id/instance type to specified via config.
<kapil> niemeyer, what do you think about a preallocation option for some number of machines on bootstrap, as a cli/config option
<niemeyer> kapil: Sounds neat
<kapil> ie. a min machines in config
<kapil> niemeyer, i'm trying out tiny natty images atm, i think some preallocation might make initial service deploys a bit faster
<kapil> cool
<niemeyer> kapil: Yeah, definitely.. and there's no real issue with it that I can think of.  It's just increasing the pool
<_mup_> ensemble/relation-get-bythespec r172 committed by linda89@example.com
<_mup_> version of the invoker argument handling w/o attempt at argument parsing, using optional list
<kapil> yeah.. micro instances are working now
<SpamapS> I've had instance_type set to t1.micro for a while. :)
<SpamapS> they spin up about 2x as fast as m1.small
<SpamapS> and, given that they can be re-started as a bigger instance type.. they seem an ideal starting type. :)
<SpamapS> btw, it would be good to be able to specify a different ami for the bootsrap node and the others.. apparently LXC on lucid is fairly crackful.
<SpamapS> so the ability to say "bootstrap me on natty, but then run everything else on lucid" is desirable.
<niemeyer> OMGOMG
<niemeyer> Review Zero!
<niemeyer> (a new model based on Inbox Zero)
<niemeyer> SpamapS: We'll be moving to Natty after next week (beta FTW)
<kapil> SpamapS, yeah.. lxc was one the kicker for me on the move to natty.. i've been trying it out in maverick the last few days, via libvirt (the integration of which is broken even with openstack ppas).
<kapil> SpamapS, i'm in progress on making the ami configurable via environments.yaml
<SpamapS> I think its a common situation that bootstrap will have different machine providers and arguments..
<kapil> SpamapS, sure, the individual environments have configs.. although i think your suggesting bootstrap should only do one environment at a time?
<kapil> which all sounds good
<SpamapS> It would be good if it was easily overridable just for bootstrap is all.
<SpamapS> Like.. "bootstrap me in ec2, then use the lxc provider"
 * kapil lunches
<niemeyer> kapil: Enjoy
<niemeyer> I'm about to do the same
<kim0> Hi folks .. Letting you know Ubuntu Cloud Days starting in 10mins in #ubuntu-classroom .. You can discuss in #ubuntu-classroom-chat .. Thanks
<_mup_> ensemble/environment-config--selected-ami r179 committed by linda89@example.com
<_mup_> update with right distro name for natty
<kapil> i'm going to switch the default instance type to t1.micro unless anyone has an objection? jimbaker, bcsaller, niemeyer_lunch, SpamapS ?
<jimbaker> kapil, sounds like a great idea to me
<bcsaller> sounds good to me 
<niemeyer> kapil: +1 on experimenting with it
<niemeyer> kapil: I wonder a bit if they'll be too slow for any meaningful usage, but SpamapS seems happy, so let's give that a try
<kapil> niemeyer, it seems to work well enough to for the wordpress/mysql examples.
<kapil> and lowers the cost by 2/3
<kapil> sounds good
<_mup_> ensemble/environment-config--selected-ami r180 committed by linda89@example.com
<_mup_> on the ec2 provider, switch the default instance type to t1.micro
<_mup_> ensemble/relation-get-bythespec r173 committed by linda89@example.com
<_mup_> spelling of exception message
<kapil> on natty though some of the formulas look like they need fixing
<bcsaller> kapil: in what way? I'm curious what wasn't version generic
<kapil> niemeyer, on debug hook one problem i noted is that we can't easily set debug for install or service hooks, because we validate the unit name.. so we don't have much to get the debug setup before the hook executes, it probably should wait on the unit's existence with a few minutes for a timeout.
<kapil> bcsaller, not sure exactly.. i should try it in the debugger, the wordpress side didn't get a second db-relation-changed fired for the mysql modify was all i noticed. 
<niemeyer> kapil: Hmm.. how do we validate the name atm?
<kapil> niemeyer, we verify a the unit's service and unit name, so we can dereference to a machine
<niemeyer> kapil: Hmm
<niemeyer> kapil: But how do we debug a unit before we know its name?
<_mup_> Bug #741890 was filed: Better support for debugging install/start hooks <Ensemble:New> < https://launchpad.net/bugs/741890 >
<niemeyer> kapil: Or do I misunderstand what you mean?
<kapil> niemeyer, no.. i think you've got the underlying question here
<kapil> niemeyer, previously we had relatively determinstic ordering, with global ordering, its not predictable per se... well it is predictable but not nesc. obvious.
<kapil> er. global sequence on unit names
<niemeyer> kapil: I see
<kapil> so you do ensemble debug-hooks mysql/0  and ensemble deploy mysql
<niemeyer> kapil: But then, even if we were able to predict the unit name, it feels like a bad approach in general
<niemeyer> kapil: Like winning a typing race :)
<kapil> niemeyer, we can predict with fair certainty the next name of the unit internal to the api.
<kapil> so perhaps mysql/next 
<niemeyer> kapil: It feels like a much better approach would be to do that at deploy time
<niemeyer> kapil: ensemble deploy --debug-hooks ...
<kapil> as a unit name denoting debug the next unit of this service
<niemeyer> and then hook up
<niemeyer> "hook up" is an ideal term in that case, I guess ;-)
<kapil> niemeyer, hmm so deploy would drop into a debug shell after waiting for the machine startup?
<kapil> that sounds pretty nice
<niemeyer> kapil: No, it would only set a flag there
<niemeyer> kapil: We don't want to be copying everything over from debug-hooks I think
<kapil> niemeyer, i was just thinking calling out to some refactor in debug-hooks
<niemeyer> kapil: It'd put the unit in debug mode, and then we can run ensemble debug-hooks after the fact at our leisure
<kapil> well currently debug-hooks is ephemeral..
<niemeyer> kapil: Hmmm.. can we still an ephemeral node? :-)
<niemeyer> steal
<kapil> sort of
<kapil> we can steal the session id if we save it...
<niemeyer> Hmm.. that's full of edge cases IIRC
<kapil> and the time between the commands is less than session timeout
<kapil> niemeyer, yeah.. can of worms
<niemeyer> (from my gozk playing)
<kapil> much easier to call into a refactored debug-hooks from deploy
<kapil> hmmm
<kapil> although its gets a little messy when deploy could mean a whole suite of services and units... we should only debugthe top level one.. but then we start getting formula that specify min units >1 and get ambigious.
<niemeyer> Yeah
<kapil> niemeyer, the only alternative i can come up with is symbolic naming for units denoting a  temporal/state marker.. like mysql/next
<kapil> that could be consumed by debug-hooks
<kapil> but combining them sounds nice
<niemeyer> kapil: Hmmm!
<niemeyer> kapil: There may be an alternative
<niemeyer> kapil: We might make the node non-ephemeral in that specific case
<kapil> hmmm...
<niemeyer> kapil: So debug-hooks borrows ownership from it, and explicitly kills it when exiting
<kapil> niemeyer, perhaps.. i'm a little reluctant to give up the ephemeral safety blanket. that sort of change would work though. doesn't really get away from the ambiguity of doing it directly in deploy
<kapil> if we're going to set it in deploy, its not clear what we gain by not dropping the user directly into the debug shell they just requested when its ready
<niemeyer> kapil: Well, we're giving up on it purposefully.. the problem is precisely that we don't want to node to be removed when deploy exits
<niemeyer> kapil: and I don't see how there's any ambiguity in that case
<kapil> its a future ambiguity we can address latter.. but ignoring that for the moment, why not just drop them straight from deploy into the debug shell if they requested it.
<niemeyer> kapil: Because it's ambiguous would be one reason, but otherwise I can't think of any great reason not to either.
<kapil> niemeyer, i think i prefer that.. beyond the peristent debug node, we have to change debug-hooks to reconcile against existing state any new cli arguments
<kapil> hmm.. as a result of the perisstent
<niemeyer> kapil: Sounds good.  Just for curiosity sake, what do you mean regarding reconcile?
<kapil> niemeyer, the debug-hooks cli takes unit name hook-match-filter.. if the --debug-hooks  flag on deploy leaves a persistent node, then we have to reconcile current args vs. stored state.
<niemeyer> kapil: I see, ok
<kapil> probably just not accepting args in that case.. or just erroring out.. its syntax.. but its consistency too ;-)
<jimbaker> is something like this legal? relation-set port= 
<niemeyer> jimbaker: I have vague memories of defining that this would internally remove the variable
<kapil> jimbaker, i think so
<niemeyer> jimbaker: Either way, yeah, it sholud
<kapil> it won't kill the variable just an empty value for it
<kapil> i think we ended up loosing a good way to unset values atm
<niemeyer> kapil: This should probably remove the variable, at least as far as those command line tools are concerned
<kapil> there's a dictionary merge syntax on the hook context, but the api doesn't expose it
<niemeyer> kapil: Since "relation-get port" with it empty or unset is effectively equivalent
<kapil> niemeyer, what about  a magic unset variable?
<jimbaker> agreed on removing the variable, since that's the sh convention
<niemeyer> kapil: What about it? 8)
<kapil> either works.. i'm just wondering if there are cases where an empty but existant value is valid
<kapil> fair enough its simpler to do for now
<_mup_> Bug #741917 was filed: relation set with an empty value should delete the key from unit relation settings <Ensemble:New> < https://launchpad.net/bugs/741917 >
<_mup_> ensemble/environment-config--selected-ami r181 committed by linda89@example.com
<_mup_> remove some debugging in ensemble-make-image
<_mup_> ensemble/relation-set-empty-deletes r178 committed by linda89@example.com
<_mup_> relation-set with empty value deletes from the unit's relation settings.
<kapil> niemeyer, jimbaker, bcsaller standup?
<bcsaller> sure
<niemeyer> Yeah, let's do it
<jimbaker> sure
<niemeyer> I'm up
<SpamapS> sorry, in an interview
<niemeyer> bcsaller: self.create_hook("relation-get", "--format=json")
<_mup_> ensemble/relation-get-bythespec r174 committed by linda89@example.com
<_mup_> no args to invoker/create_hook call
<bcsaller> gustavo: pushed those changes
<niemeyer> bcsaller: Thanks!
<bcsaller> I have to go move the car (calls always run long on Thurs. when the street sweeper comes). 
<jimbaker> good insight on libvirt during standup - it prompted me to look at its firewall integration
<jimbaker> (via iptables)
<kapil> hmm.. it looks like there is already support for deleting if the value set is none, not clear if that's what's done though or if set to an empty string
<_mup_> ensemble/relation-set-empty-deletes r179 committed by linda89@example.com
<_mup_> add a new hook context state api delete, which sets the value to none for the context flush deletion detection.
<_mup_> ensemble/relation-set-empty-deletes r180 committed by linda89@example.com
<_mup_> test for the hook cli that set can delete if used with an empty value
<_mup_> ensemble/relation-set-empty-deletes r181 committed by linda89@example.com
<_mup_> simplify deletions, to just delegate to set_value with None, ensure that their only set for deletion if currently existing.
<kapil> bcsaller, fwiw re hook testing.. http://bazaar.launchpad.net/~hazmat/ensemble/relation-set-empty-deletes/revision/180
<bcsaller> kapil: thanks, already pushed a change 
<kapil> cool
<_mup_> ensemble/global-unit-name-uniqueness r180 committed by linda89@example.com
<_mup_> setup unit sequence topology key as per hyphenated convention.
<_mup_> ensemble/expose-services r182 committed by linda89@example.com
<_mup_> Edits in response to review
<_mup_> ensemble/trunk r179 committed by linda89@example.com
<_mup_> merge global-unit-name-uniqueness [r=niemeyer][f=731691]
<_mup_> Make unit names globally unique, even across incarnations
<_mup_> of a service with the same name.
<_mup_> This all tangentially addresses the deploying of units of a
<_mup_> reincarnated service onto a machine which previously held previously
<_mup_> held units of it.
<kapil> niemeyer, i had a question for you regarding https://code.launchpad.net/~hazmat/ensemble/formula-upgrades-spec/+merge/53898 #11
<kapil> so a service may have multiple relations and the formula not the name for all of them.. mysql for example, might have a dozen dbapp-relations.. 
<kapil> pointing to different services
<kapil> relation-list is designed to iterate over all units.. so relation-list dbapp-relation would list all units
<kapil> i'm just thinking it might make more sense to deal with those relations one by one, via iteration of the relations.
<_mup_> Bug #742046 was filed: Ensemble should sftp to/from units <Ensemble:New> < https://launchpad.net/bugs/742046 >
<niemeyer> kapil: Hmm
<niemeyer> kapil: I see.. that's a good point
<niemeyer> kapil: Not sure about a good interface to refer to these yet
<niemeyer> kapil: They are name-less ATM
<niemeyer> and are simply "buckets" of remote units
<niemeyer> We need to think about that some more.. we can probably postpone that entirely for the upgrade work, though
<_mup_> ensemble/expose-services r183 committed by linda89@example.com
<_mup_> Moved sections, plus edits
<kapil> niemeyer, sounds good re postponing relation inspection for upgrade
<_mup_> ensemble/expose-services r184 committed by linda89@example.com
<_mup_> Spell checked
 * niemeyer => nap!
<_mup_> ensemble/formula-upgrades-spec r180 committed by linda89@example.com
<_mup_> merge trunk
<_mup_> ensemble/formula-upgrades-spec r181 committed by linda89@example.com
<_mup_> post conflict resolve against trunk merge, remove empty specifications  directory.
<_mup_> ensemble/trunk r180 committed by linda89@example.com
<_mup_> [merge] Merge relation-get-args branch. [r=niemeyer] [f=719329]
<_mup_> * relation-get now follows the specification for argument ordering.
<_mup_>    The documented format is: 
<_mup_>   
<_mup_>     relation-get [setting_name] [unitname]
<_mup_>   
<_mup_>     '-' may be used for setting_name to indicate ALL relation settings.
<_mup_>     unitname may be ommited and now defaults to the remote unit of the relationship.
<_mup_> * many cleanups to the tests and removal of many testing hook files from the tree
<kapil> bcsaller, can you get multiple setting names in one line with that? or is it intended to just get all of them if  multiple are wanted?
<bcsaller> kapil: sorry missed that. I think currently its a case of getting them all 
#ubuntu-ensemble 2011-03-25
<SpamapS> wishlist: eval `relation-get --format sh`
<bcsaller> SpamapS: file a bug for it, simple to add later
<kapil> niemeyer_away, i'm wondering about the security implications of giving a root shell to an ubuntu user, and circumventing sudo access.. it seems preferrable to use sudo as security requirement vs. handing out a root shell..
<jimbaker> bcsaller, kapil - standup?
<kapil> jimbaker, sounds good
<kapil> bcsaller, jimbaker skype?
<jimbaker> looks like we are all on skype now
<bcsaller> sorry, was getting tea, back now
<jimbaker> funny, the recent security updates fix all of the ui programs currently running on my laptop except for xchat (emacs, firefox, skype...)
<jimbaker> spring time in colorado is pretty nice - fresh snow in the mountains, birds singing in the trees here. really puts the sound of music into me ;)
<_mup_> ensemble/debug-hook-scope-guard r203 committed by linda89@example.com
<_mup_> use mocker order to ensure correct activation sequence of screen multiuser mode.
<_mup_> ensemble/debug-hook-scope-guard r204 committed by linda89@example.com
<_mup_> wire in screen debug session into unit agent debug flag watch.
<_mup_> ensemble/debug-hook-scope-guard r205 committed by linda89@example.com
<_mup_> wire in waiting into the admin cli side of debug-hooks
<_mup_> ensemble/debug-hook-scope-guard r206 committed by linda89@example.com
<_mup_> ssh debugging remotely.. about to reverse since it requires suid root on screen...
<_mup_> ensemble/debug-hook-scope-guard r207 committed by linda89@example.com
<_mup_> revert changes back to previous implementation.
#ubuntu-ensemble 2011-03-26
<_mup_> ensemble/debug-hook-scope-guard r208 committed by linda89@example.com
<_mup_> remove any unix permission manipulation on the machine, in favor of debug requiring sudo.
<kapil> reallly.. allhands is built in java
<kapil> tomcat traceback.. jetspeed.. 
#ubuntu-ensemble 2011-03-28
<kapil> g'morning
<_mup_> ensemble/new-hook-semantics-departed r181 committed by linda89@example.com
<_mup_> Add -departed hook
<kapil> bcsaller, jimbaker standup?
<bcsaller> is there something we need to cover today? I'm finishing up stuff I didn't get to this weekend 
<kapil> bcsaller, nothing in particular.. i was just wanted to touch base and where we are on our tasks from last week, and what we're working on this week
<bcsaller> almost done with this darn spec, but we can do a quick call to cover it 
<kapil> bcsaller, great
<kapil> jimbaker, skype?
<jimbaker> kapil,  sounds good re skype
<kapil> jimbaker, just see your cell phone on skype
<jimbaker> kapil, that's probably because i'm not logged in :)
<jimbaker> hold on, super noisy here - i'm at coffee shop while car is being worked on
<jimbaker> kapil, i see bcsaller on skype but not yet you. split brain?
<kapil> jimbaker, cloud :-)
<kapil> jimbaker, not seeing you on skype
<kapil> jimbaker, or it fails constantly
<kapil> jimbaker, you should just be able to just modify unit relation lifecycle _execute change hook
<kapil> and switch the hook path based on change
<jimbaker> kapil, back now
<kapil> jimbaker, did you see my comments above about _execute_change_hook?
<jimbaker> kapil, yes
<kapil> cool, afaics that should be all that needs modification to support additional separate hooks for change, depart, join
<jimbaker> that's actually where i made the change
<jimbaker> so maybe i'm overanlyzing here then... i just want to ensure that niemeyer's plan of having the existing semantics co-exist with the new semantics can work
<kapil> a change there should do that
<kapil> and ditching the removal of the CHANGE env var
<kapil> also within that method could be done the expansion of join to include modify
<jimbaker> kapil, agreed on that
<jimbaker> so basically we can simply execute an arbitrary number of hook executions (seen with yield self._executor(...))
<jimbaker> although in this case, arbitrary means up to two
<kapil> jimbaker, generically.. yes. specifically we want two
<kapil> jimbaker, sounds good
<jimbaker> kapil, sounds good. i was getting worried this was getting too complicated. and i didn't want to change more unit tests than necessary for all the obvious reasons
<jimbaker> thanks
<kapil> jimbaker, np
<kapil> i'm going to meander and see i can find some lunch
<kapil> bbiab
<kapil> hmm.. looks like nova is almost done adding lxc support
<_mup_> ensemble/new-hook-semantics-departed r182 committed by linda89@example.com
<_mup_> Keep existing semantics for departed; make it possible to invoke multiple hooks for one change
<_mup_> ensemble/new-hook-semantics-remove-ensemble-change-env-var r186 committed by linda89@example.com
<_mup_> Modified examples for new hook semantics
#ubuntu-ensemble 2011-03-29
<_mup_> ensemble/new-hook-semantics-remove-ensemble-change-env-var r187 committed by linda89@example.com
<_mup_> Converted example to use revised relation-get
<_mup_> ensemble/new-hook-semantics-remove-ensemble-change-env-var r188 committed by linda89@example.com
<_mup_> Added new empty hooks for examples
<_mup_> Bug #744723 was filed: Introduce a -relation-joined hook <Ensemble:New> < https://launchpad.net/bugs/744723 >
<_mup_> Bug #744724 was filed: Stop running the <name>-relation-changed hook on the *departed* event <Ensemble:In Progress by jimbaker> < https://launchpad.net/bugs/744724 >
<jimbaker> well, that's annoying - i was trying to remember how to select the parent branch for a set of linked branches, and i got it wrong in launchpad
<jimbaker> changing it only gets me this right now: Oops!
<jimbaker> Sorry, something just went wrong in Launchpad.
<jimbaker> Weâve recorded what happened, and weâll fix it as soon as possible. Apologies for the inconvenience. 
<jimbaker> anyway, i suspect there's just one fix - recreate all of these branches and try again. tomorrow
<SpamapS> Hey so are you guys done mucking with the formula hooks? I want to update principia to "the new way" and then update the PPA.
<jimbaker> SpamapS, i just finished implementation work on the new hook semantics
<jimbaker> but i made the mistake of trying to do the merge proposals in launchpad relatively late at night
<jimbaker> so need to re-do
<SpamapS> dopamine fail
<jimbaker> drinking green tea is very good today
<_mup_> ensemble/new-hook-semantics-1-departed-hook r181 committed by linda89@example.com
<_mup_> Add support for multiple hooks per change, with specific support for departed hook
<_mup_> ensemble/new-hook-semantics-2-joined-hook r182 committed by linda89@example.com
<_mup_> Add support for <name>-relation-joined hook
<_mup_> ensemble/new-hook-semantics-3-remove-change-hook r183 committed by linda89@example.com
<_mup_> Remove calling of <name>-relation-changed upon departed event
<_mup_> ensemble/new-hook-semantics-4-remove-env-var r184 committed by linda89@example.com
<_mup_> Removed setting of ENSEMBLE_CHANGE; this includes corresponding changes in the example formulas
 * kapil yawns
<_mup_> ensemble/new-hook-semantics-4-remove-env-var r185 committed by linda89@example.com
<_mup_> Added missing departed and joined hooks for example formulas
<_mup_> ensemble/environment-config--selected-ami r182 committed by linda89@example.com
<_mup_> add a test to verify default image id and instance type
<_mup_> ensemble/new-hook-semantics-4-remove-env-var r186 committed by linda89@example.com
<_mup_> Added shebang to empty departed, joined hooks
<_mup_> ensemble/environment-config--selected-ami r183 committed by linda89@example.com
<_mup_> fix up provider documentation per review comments
<jimbaker> SpamapS, please take a look at lp:~jimbaker/ensemble/new-hook-semantics-4-remove-env-var, you can see the impact there of the new hook semantics, including removing ENSEMBLE_CHANGE
<_mup_> ensemble/trunk r181 committed by linda89@example.com
<_mup_> merge environment-config-selected-ami [r=niemeyer][f=737687]
<_mup_> Changes the default instance type to t1.micro, allow the EC2 AMI
<_mup_> to be configured via environments.yaml, add documentation of all
<_mup_> EC2 provider configuration options.
<jimbaker> kapil, that's a welcome change, good to see it in trunk now
<SpamapS> yeah I've been defaulted to t1.micro for a while. :)
<jimbaker> the need to add the shebang reminded me of this campy serial about shazam! - http://www.youtube.com/watch?v=7KfFx_UZ5ZU
<_mup_> ensemble/trunk r182 committed by linda89@example.com
<_mup_> merge relation-set-empty-deletes [r=niemeyer][f=741917]
<_mup_> Relation hooks can now utilize relation-set to delete values
<_mup_> from their relation settings by setting the key to an empty value.
<_mup_> ensemble/formula-upgrade r180 committed by linda89@example.com
<_mup_> merge trunk
<_mup_> ensemble/formula-upgrades-spec r182 committed by linda89@example.com
<_mup_> merge trunk
<kapil> jimbaker, SpamapS its also possible to reuse a machine now if you have a service with the same name
<kapil> jimbaker, just looking over your branches.. it wasn't clear why on depart its executing relation-change and then relation-depart?
<jimbaker> kapil, just following the procedure that niemeyer wanted - add -relation-depart, then remove -relation-changed
<jimbaker> i think the idea is that it enhances the visibility of what changes are occurring for these new hook semantics
<jimbaker> personally, i would have just one made branch for all of this work
<kapil> jimbaker, cool
<jimbaker> kapil, bcsaller - standup?
<kapil> jimbaker, sounds good
<kapil> jimbaker, don't see you on skype?
<jimbaker> kapil, i see you on skype, crazy assymmetry
<_mup_> ensemble/config-pipeline r179 committed by linda89@example.com
<_mup_> changes to config-spec, reworked document ordering
<jimbaker> bcsaller, i was just looking at your doc on config settings. one thing you should probably do is merge trunk because niemeyer changed the section layout
<jimbaker> (in particular the specifications dir is now gone)
<kapil> bounce, bounce
<jimbaker> kapil, is the opposite of yawning?
<jimbaker> is this the
<kapil> jimbaker, perhaps
<kapil> its an appropriate phrase for many situations approximating the opposite of yawning, but tis also appropriate in situations of yawning as an exit strategem
<bcsaller> jimbaker: trying to fix this merge now, I'll repush
<jimbaker> bcsaller, sounds good. i have some  editing suggestions that i'm putting together
<bcsaller> jimbaker: thanks
<kapil> jimbaker, per machine security groups are limited in number.
#ubuntu-ensemble 2011-03-30
<_mup_> ensemble/config-pipeline r180 committed by linda89@example.com
<_mup_> merge trunk
<_mup_> ensemble/rename-amp r181 committed by linda89@example.com
<_mup_> renaming of hook33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abget/set to hook33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abrelation_get/relation_set in anticipation of config_get
#ubuntu-ensemble 2011-03-31
<_mup_> ensemble/config-state-manager r182 committed by linda89@example.com
<_mup_> initial linda89@example.com.config_get/set
<_mup_> ensemble/config-state-manager r183 committed by linda89@example.com
<_mup_> basic config_get/set passing tests
<_mup_> Bug #746688 was filed: hook commands should be renamed from generic get/set to relation_get/set <Ensemble:New> < https://launchpad.net/bugs/746688 >
<_mup_> Bug #746695 was filed: service state should handle config settings <configuration> <Ensemble:In Progress by bcsaller> < https://launchpad.net/bugs/746695 >

{'channel': 'ubuntu-ensemble', 'month': 3}