[00:01] <niemeyer> Starting to fade
[00:04] <niemeyer> I think signatures are fully working
[00:17] <_mup_> ensemble/unit-agent-resolved-part-two r269 committed by kapil.thangavelu@canonical.com
[00:17] <_mup_> unit agent resolving units.
[00:57] <_mup_> ensemble/unit-agent-resolved-part-two r270 committed by kapil.thangavelu@canonical.com
[00:57] <_mup_> fix a typo in the stop transition action
[01:08] <_mup_> ensemble/unit-agent-resolved-part-two r271 committed by kapil.thangavelu@canonical.com
[01:08] <_mup_> round out unit agent resolved test cases.
[01:11] <_mup_> Bug #776014 was filed: unit agent needs support for resolving units <Ensemble:In Progress by hazmat> < https://launchpad.net/bugs/776014 >
[01:14] <hazmat> okay.. that's the last branch of the resolved work.
[01:14]  * hazmat calls it a night
[03:20] <_mup_> ensemble/config-set r209 committed by bcsaller@gmail.com
[03:20] <_mup_> wip to show kapil
[03:29] <_mup_> ensemble/config-set r210 committed by bcsaller@gmail.com
[03:29] <_mup_> fix typo
[03:58] <hazmat> bcsaller, this is what i was thinking of for the test api https://pastebin.canonical.com/47020/
[04:00] <bcsaller> that looks like a good start
[05:44] <_mup_> ensemble/expose-provisioning r233 committed by jim.baker@canonical.com
[05:44] <_mup_> More work on testing cleanup and handling scenarios occurring at that time
[06:15] <_mup_> ensemble/expose-provisioning r234 committed by jim.baker@canonical.com
[06:15] <_mup_> Refactored callbacks
[06:15] <_mup_> ensemble/expose-provisioning r235 committed by jim.baker@canonical.com
[06:15] <_mup_> Refactored callbacks
[06:57] <_mup_> ensemble/config-state-manager r208 committed by bcsaller@gmail.com
[06:57] <_mup_> reapply expose stuff, shouldn't be here, but this fixes the issue
[06:59] <_mup_> ensemble/expose-provisioning r236 committed by jim.baker@canonical.com
[06:59] <_mup_> Properly expose services if provisioning agent restarts
[08:58] <kim0> Morning everyone
[09:54] <_mup_> ensemble/config-get r209 committed by bcsaller@gmail.com
[09:54] <_mup_> still dealing with bad merge from before, forward prop changes
[10:06] <_mup_> ensemble/config-set r212 committed by bcsaller@gmail.com
[10:06] <_mup_> check point config set
[13:57] <kim0> niemeyer: Morning o/ 
[14:02] <hazmat> g'morning folks
[14:03] <hazmat> niemeyer, i think that's the last branch for resolved in review
[14:11] <kim0> hmm why is it that my merges to other projects like https://code.launchpad.net/~ubuntu-branches/ubuntu/natty/logrotate/natty
[14:11] <kim0> appear with my name on them, while to ensemble, the reviwers name is put instead
[14:12] <kim0> not that I care much, but new members will probably be too excited seeing their own name besides their formulas and stuff
[14:19] <hazmat> kim0, did you commit the merge on the other projects?
[14:19] <kim0> hazmat: no I don't have upload rights
[14:19] <kim0> I think Daviey did for logrotate
[14:20] <hazmat> kim0, we have this commit message notation syntax for when doing merges on behalf of other users [a=kim0]... does seem a little strange
[14:21] <hazmat> that bzr would pull the commit as a merge in one case.. and pull the underlying commits in the otehr
[14:21] <kim0> yeah :/
[14:21] <hazmat> kim0, it looks like that was actually committed by a daemon, the committer and author metadata at the bzr level is different
[14:22] <hazmat> ah.. ic.. you can pass --author to bzr commit
[14:22] <hazmat> yeah.. we should start using that
[14:23] <kim0> hazmat: so that is something you guys would need to do, not the person creating the branch right
[14:23] <hazmat> kim0, yup.. in the case of that logrotate branch it looks like some automated process kicked in and did the merge after review
[14:24] <kim0> cool .. @everyone please do that then while merging :)
[14:24] <kim0> thanks hehe
[14:25] <kim0> Another thingie, I'm starting a new little doc on writing and contributing an Ensemble formula
[14:25] <kim0> for that, I need a simplistic "hello world" style formula
[14:26] <kim0> any suggestions ?
[14:26] <kim0> I think someone mentioned there could be some user formula for adding/deleting users .. that sounds simply enough, but not sure how it'd work
[14:27] <kim0> maybe a motd formula!
[14:27] <hazmat> kim0, that's machine config, not service deployment.
[14:28] <kim0> well yeah I understand .. mm
[14:30] <hazmat> kim0, i agree its something we should have some facilities for, machine level policies
[14:30] <kim0> I mean it can be done today right ?!
[14:30] <kim0> it's just that we don't want to huh
[14:31] <kim0> so if an admin wants to create users (or change motd) .. do we say ensemble is not for that 
[14:34] <niemeyer> hazmat, kim0: Good morning!
[14:34] <niemeyer> hazmat: That's awesome
[14:34] <niemeyer> hazmat: I'll have a full pass today
[14:34] <hazmat> niemeyer, great
[14:35] <niemeyer> Auth actually works, btw!
[14:35] <hazmat> niemeyer, i'm thinking i should do some work with ben on the service-config.. else i can dig back into the debug-hook stuff
[14:35] <niemeyer> hazmat: http://pastebin.ubuntu.com/602773/
[14:35] <niemeyer> hazmat: Sounds good, it feels like he'd benefit from a hand on the hooks part
[14:36] <hazmat> niemeyer, cool
[14:36] <hazmat> re auth
[14:37] <niemeyer> hazmat: Yeah, it turned out pretty neat.  This enables us to authenticate people in the repo
[14:38] <niemeyer> hazmat: Sending them back and forth to Launchpad for authentication
[14:38] <hazmat> kim0, they can add users as part of managing a service
[14:38] <hazmat> kim0, for example someone doing a heroku clone, might deploy a service formula per user, and the individual units could create a new user representing that customer on a machine for launching the appserver...
[14:39] <kim0> Yeah, got it .. so what's a good hello-world formula, that hopefully doesn't involve complex config files ..etc
[14:43] <hazmat> kim0, one that prints 'hello world'.. really though if you want to just have it add a user its fine.. just overkill
[14:43] <hazmat> kim0, i'd probably do one that uses a packaged service.. like take nginx or apache as an example.. as it provides enough functionality to grow the formula over multiple tutorial parts. 
[15:26] <_mup_> Bug #776426 was filed: Add debug hook cli flag for deploy and and add-unit. <Ensemble:New> < https://launchpad.net/bugs/776426 >
[15:53] <jimbaker> i should be available when there, but just in case i'm silent: i need to take my toyota to the dealer
[16:50] <hazmat> bcsaller, just sent you an email regarding the remaining stuff i could think of for service-config.. give me a ping when you've got a moment
[16:50] <hazmat> bzr cli parsing does seem a bit nicer than argparse
[16:56] <jimbaker> hazmat, i think subcommand support was never really completed in argparse. and that's where the comparison w/ bzr is pretty obvious
[16:57] <hazmat> jimbaker, subcommands are fine, its the help/output formatting usage and customization that's atrocious imo
[16:57] <jimbaker> hazmat, but that is part of what it should be - good help for subcommands
[16:59] <jimbaker> makes sense that in combining functionality - help + subcommands, for example - would should the most gaps in something like argparse
[17:49] <bcsaller> hazmat: I realized last night that some of the files on that branch were not commited. Hopefully you were able to pull them when you had a look this morning?
[17:50] <hazmat> bcsaller, i had a look and setup a pipeline, but there where a lot of conflicts with trunk
[17:50] <hazmat> bcsaller, any chance you could resolve those and push an updated version? i'd like to use a clean branch point to start with
[17:51] <bcsaller> I can try to remerge trunk in the last phase of the pipeline, sure. I didn't realize
[17:51] <bcsaller> there is no conceptual conflict so it doesn't make sense 
[17:53] <koolhead17> hi all
[17:54] <hazmat> bcsaller, i've found typically its better to merge at the start of the pipeline (i use a trunk-merge pipe) and then pump the changes through
[17:54] <bcsaller> yes, but the start of my pipeline was already merged 
[17:54] <bcsaller> I don't know if thats the source of the issues 
[17:54] <hazmat> bcsaller, you can add a secondary merge-trunk pipeline after that
[17:54] <bcsaller> ahh
[17:55] <bcsaller> I'm happy to try that 
[17:58] <hazmat> bcsaller, out of curiosity what's the name of the hook (for config-changed)?
[17:58] <bcsaller> config-changed
[17:59] <bcsaller> later part of the spec has it
[18:00] <hazmat> bcsaller, cool, i'm starting off with a fresh trunk branch for the moment
[18:00] <hazmat> bcsaller, what's that assessment of parts that are ready or almost ready accurate?
[18:00] <hazmat> s/was that
[18:01] <bcsaller> minus any of the merge issues they are fine, I'll try merging trunk again and seeing if it breaks things or not
[18:09] <_mup_> ensemble/service-config-unit-lifecycle r215 committed by kapil.thangavelu@canonical.com
[18:09] <_mup_> unit lifecycle.configure method for processing service configuration changes.
[18:12] <_mup_> ensemble/expose-provisioning r237 committed by jim.baker@canonical.com
[18:12] <_mup_> Comments and method rename to indicate (somewhat more) private api
[18:17] <hazmat> i'm not entirely clear what the error handling looks like for configure errors should look like.
[18:18] <hazmat> bcsaller, any thoughts on what that behavior should be?
[18:18] <_mup_> ensemble/expose-provisioning r238 committed by jim.baker@canonical.com
[18:18] <_mup_> Removed eventual consistency support for incorporation into a later branch
[18:18] <bcsaller> let me see if I covered that in the spec, one sec
[18:19] <bcsaller> " Errors in the config-changed hook force ensemble to
[18:19] <bcsaller> assume the service is no longer properly configured. If the service is
[18:19] <bcsaller> not already in a stopped state it will be stopped and taken out of
[18:19] <bcsaller> service"
[18:20] <hazmat> stopped and taken out of service are slightly different, but easy enough.. it will mean missed hook executions though for relations, if its brought back online
[18:28] <_mup_> ensemble/expose-provisioning r239 committed by jim.baker@canonical.com
[18:28] <_mup_> Test comments
[18:34] <_mup_> ensemble/config-get r210 committed by bcsaller@gmail.com
[18:34] <_mup_> better merge resolution, less juggling
[18:36] <jimbaker> this branch is finally getting into a good state for review. i am relieved
[18:36] <jimbaker> just need a few more tests...
[18:36] <_mup_> ensemble/service-config-unit-lifecycle r216 committed by kapil.thangavelu@canonical.com
[18:36] <_mup_> unit workflow support for service configuration
[18:38] <_mup_> ensemble/config-set r213 committed by bcsaller@gmail.com
[18:38] <_mup_> Better ptests in Makefile, sensitive to new files properly
[18:38] <_mup_> Bug #776596 was filed: unit workflow and lifecycle must support service configuration <Ensemble:New for hazmat> < https://launchpad.net/bugs/776596 >
[18:42] <hazmat> bcsaller, just pushed  the lifecycle/worfklow changes for review based on trunk, i'm going to switch tracks back to debug-hook, unless you'd like me to work on the watch_config_changed stuff?
[18:42] <bcsaller> you're fast
[18:43] <bcsaller> I'll look it over, but thats very helpful. Work on the debug hook
[18:43] <hazmat> bcsaller, practice makes perfect.. there's some work to be done wrt to resolved, but that should probably land first
[18:46] <_mup_> Bug #776605 was filed: Hooks need access to service options <Ensemble:New for bcsaller> < https://launchpad.net/bugs/776605 >
[19:00]  * hazmat bangs head against merge
[19:29]  * niemeyer switches to reviewing mode
[19:35] <niemeyer> > +class ServiceUnitRelationResolvedAlreadyEnabled(StateError):
[19:35] <niemeyer> > +    """The unit has already been marked resolved.
[19:35] <niemeyer> > Documentation needs updating.
[19:35] <niemeyer> how so?
[19:35] <niemeyer> hazmat: s/unit/relation/
[19:36] <niemeyer> hazmat:
[19:36] <niemeyer> """
[19:36] <niemeyer> It is actually making a request for the problem to be solved, not solving the 
[19:36] <niemeyer> problem directly, as there are behavioral aspects to transitions that need be 
[19:36] <niemeyer> done inside of the unit agent.
[19:36] <niemeyer> """
[19:36] <niemeyer> hazmat: That's not the case, last we spoke
[19:37] <niemeyer> hazmat: resolved means "I have resolved the problem." (hence the 'd')
[19:37] <niemeyer> hazmat: The problem as in "the reason why this hook failed"
[19:39] <niemeyer_> Argh..
[19:39] <niemeyer_> What was the last message I sent?
[19:46] <hazmat> niemeyer, failed."
[19:46] <niemeyer> hazmat: Ok, so it did went through, thanks
[19:46] <niemeyer> hazmat: I ended up just providing better organized comments in the merge proposal
[19:46] <niemeyer> hazmat: So feel free to ignore the IRC stuff
[19:46] <hazmat> niemeyer, resolved is a request to make something happen.. 
[19:47] <niemeyer> hazmat: Yes, to allow the relation/unit to go ahead
[19:47] <hazmat> its marking the unit as resolved, but the actual resolution happens on the agent
[19:47] <niemeyer> hazmat: It's a statement made by the user that the problem has been resolved
[19:47] <niemeyer> hazmat: No..
[19:47] <niemeyer> hazmat: The resolution has already happened
[19:47] <niemeyer> hazmat: We're simply telling the agent "go on"
[19:47] <hazmat> niemeyer, it hasn't till the agent processes the resolved request
[19:47] <niemeyer> hazmat: I hope one day we can make agents which resolve problems, though ;-)
[19:48] <niemeyer> hazmat: It has happened
[19:48] <niemeyer> hazmat: That's why the command is "resolved" and not "resolve"
[19:48] <hazmat> niemeyer, the request has been made, but not acted upon
[19:48] <niemeyer> hazmat: The request to go on, yes
[19:48] <hazmat> yes
[19:48] <niemeyer> hazmat: Not the request to resolve the problem which caused the script/hook to fail
[19:48] <hazmat> but till its processed by the agent, the goal is not accomplished.
[19:49] <niemeyer> hazmat: I'm banging on that because that's the idea we have to provide to users
[19:49] <niemeyer> hazmat: Agreed.. it's just terminology
[19:49] <niemeyer> hazmat: The goal of letting the agent continue normal operation
[19:49] <niemeyer> hazmat: Not the goal of resolving the problem.. that one must have been done already
[19:50] <niemeyer> hazmat: (out of band)
[19:50] <hazmat> right
[19:56] <niemeyer> Is it just me or Launchpad fonts seem to be a bit less readable lately?
[19:57] <niemeyer> Setting the font color to black and increasing them a bit does wonders
[19:58]  * niemeyer <= getting old
[19:59] <_mup_> ensemble/expose-provisioning r240 committed by jim.baker@canonical.com
[19:59] <_mup_> Tests for watch_service_states
[20:02] <_mup_> ensemble/unit-agent-resolved r269 committed by kapil.thangavelu@canonical.com
[20:02] <_mup_> update unit tests to use relation workflow accessor on lifecycle.
[20:03] <hazmat> niemeyer, the resolved branch is ready for review  (fixed the accessor issue)
[20:03] <niemeyer> hazmat: Sweet, thanks
[20:05] <niemeyer> Y.all("body")
[20:05] <niemeyer> EWINDOW
[20:15] <_mup_> ensemble/debug-hook-scope-guard r210 committed by kapil.thangavelu@canonical.com
[20:15] <_mup_> merge trunk and resolve conflict.
[20:20] <hazmat> niemeyer, regarding the relation resolved stuff, i realized that the retry flag argument to the unit relations doesn't have any real meaning, as it just places them back into an operational state, it doesn't rexecute a failed hook.
[20:20] <niemeyer> hazmat: Hmmm, good point
[20:21] <niemeyer> hazmat: Although, shouldn't it reexecute?
[20:22] <hazmat> niemeyer, it doesn't at the moment, we don't save enough contextual information regarding the hook to do so, nor do we have a means to populate it artificailly in the context.. we could if we want to enable it but i think  its probably future work for such.. for now i'd just raise an error if a unit rel with retry specified
[20:23] <niemeyer> hazmat: Sounds good
[20:23] <hazmat> niemeyer, also regarding the debug-hook stuff, i've looked it and looked over the review, i tried out the screen user multiplexing but it would require suid, the sudo implementation works well
[20:24] <hazmat> niemeyer, not sure that there's anything else to do for it.. 
[20:24] <hazmat> niemeyer, https://code.launchpad.net/~hazmat/ensemble/debug-hook-scope-guard/+merge/54433
[20:26] <hazmat> it will be nice to incorporate that functionality into other subcommands (deploy, add-unit, resolved --retry) with a --debug-hook option, also makes debugging install/start much easier.
[20:28] <niemeyer> hazmat: I'll check it out
[20:32] <niemeyer> bcsaller: I'm wondering a bit about the caching behavior of that get_config() method
[20:32] <niemeyer> bcsaller: Is this really what we want to do?
[20:32] <niemeyer> bcsaller: It means get_config() never updates the state read
[20:32] <niemeyer> bcsaller: I wonder if we should simply return a new YAMLState on every get_config()
[20:32] <niemeyer> bcsaller: How would that affect existing code?
[20:33] <niemeyer> hazmat: ^ You may have some input on this as well?
[20:33] <bcsaller> that was to provide a consistent view throughout hook execution
[20:33] <niemeyer> bcsaller: The consistent view is more than throughout hook execution.. it never updates
[20:33] <niemeyer> bcsaller: (remember, this is the ServiceState type)
[20:33] <bcsaller> but the lifetime of the service manager is scoped to the hook, if thats not the case then it should change 
[20:34] <hazmat> just stepping back in
[20:34] <bcsaller> my understanding is these managers are created as needed
[20:34] <niemeyer> bcsaller: So ServiceState.get_config() effectively returns the configuration of some arbitrary point in the past, when whoever first called it
[20:35] <hazmat> so we want it to update, but be cached in the hook context for hook execution
[20:35] <bcsaller> if the service manager always returns a new one thats fine, then the hook needs to cache it 
[20:35] <niemeyer> bcsaller: Creating a whole new manager to update the state of the config feels a bit like things are reversed
[20:35] <niemeyer> hazmat: Yeah, that's what it feels to me too
[20:35] <niemeyer> bcsaller: +1
[20:35] <niemeyer> bcsaller: Otherwise it really becomes random..
[20:35] <hazmat> ServiceState.get_config should do no caching
[20:35] <bcsaller> simple change
[20:35] <hazmat> cool
[20:35] <niemeyer> bcsaller: The hook itself can't know when it was first read
[20:36] <hazmat> we don't have any caching in our state apis
[20:36] <niemeyer> bcsaller: Maybe someone else called get_config() for whatever reason, and the "snapshot" becomes ancient even before it should
[20:36] <hazmat> minus the hook context
[20:36] <niemeyer> bcsaller: Please test that non-caching behavior
[20:37]  * hazmat wonders what to work on
[20:37] <niemeyer> bcsaller: +1, besides that
[20:37] <niemeyer> hazmat: Oh ho ho.. I has ideas..
[20:37] <niemeyer> hazmat: ;-)
[20:38] <hazmat> niemeyer, i thought you might, just looking over the milestone bugs atm
[20:38] <niemeyer> bcsaller: It feels like this branch is almost getting to a one-liner :-)
[20:38] <hazmat> niemeyer, i'm probably going to have some more to do, after the reviews land... but i think i might manage another small task
[20:39] <niemeyer> hazmat: Yeah, a small task might require some further thinking
[20:40] <hazmat> i've got a couple from the top of the milestone, cli beautification and bootstrap/shutdown with environmental awareness
[20:40] <hazmat> niemeyer, did you have one in particular in mind?
[20:40] <niemeyer> hazmat: Nah.. we already talked about them.. they're too large for this week
[20:41] <niemeyer> hazmat: Well.. hmmm
[20:41] <hazmat> yeah.. those require some thinking, i could at least tackle it for the simple case
[20:41] <niemeyer> hazmat: Here is an idea: implement an auto-dependency-resolution hack.
[20:41] <hazmat> and leave the lifecycle.start nested case for  post budapest
[20:41] <hazmat> niemeyer, i get to HACK?! :-)
[20:41] <hazmat> cool
[20:42] <niemeyer> hazmat: Yeah, like, totally simple and dirty
[20:42] <hazmat> i'll see what i can do there
[20:42] <niemeyer> hazmat: Something specific for UDS, which we remove afterwards
[20:42] <hazmat> niemeyer, sounds good
[20:47] <_mup_> ensemble/config-state-manager r209 committed by bcsaller@gmail.com
[20:47] <_mup_> get_config shouldn't cache inside service layer
[21:14] <_mup_> ensemble/config-get r212 committed by bcsaller@gmail.com
[21:14] <_mup_> added test verify cached copy is returned on get_config in hook
[21:18] <niemeyer> Hmmm
[21:19] <niemeyer> I have to run an errand.. will do that now that there's still sunlight and will be back to reviewing in 1.5h or so.
[21:21] <hazmat> niemeyer, cheers
[21:21] <hazmat> i'm gonna roll out in a few as well for 1.5hr
[21:29] <_mup_> ensemble/expose-provisioning r241 committed by jim.baker@canonical.com
[21:29] <_mup_> Tests for ServiceState.watch_service_units
[21:42] <hazmat> hasta luego
[22:02] <niemeyer> That was faster than expected
[23:19] <_mup_> ensemble/trunk r215 committed by bcsaller@gmail.com
[23:19] <_mup_> Service state changes supporting configuration options [r=niemeyer] [f=746695]
[23:19] <_mup_> Introduces get_config to ServiceState returning a YAMLState object.
[23:23] <hazmat>   
[23:23] <_mup_> ensemble/expose-provisioning r242 committed by jim.baker@canonical.com
[23:23] <_mup_> Test get_opened_ports, watch_opened_ports
[23:25] <hazmat> backs
[23:30] <hazmat> this auto dep stuff has one unforseen requirement.. i need to track the deps pairwise to do the relation work