| niemeyer | Starting to fade | 00:01 |
|---|---|---|
| niemeyer | I think signatures are fully working | 00:04 |
| _mup_ | ensemble/unit-agent-resolved-part-two r269 committed by kapil.thangavelu@canonical.com | 00:17 |
| _mup_ | unit agent resolving units. | 00:17 |
| _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 | 00:57 |
| _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:08 |
| _mup_ | Bug #776014 was filed: unit agent needs support for resolving units <Ensemble:In Progress by hazmat> < https://launchpad.net/bugs/776014 > | 01:11 |
| hazmat | okay.. that's the last branch of the resolved work. | 01:14 |
| * hazmat calls it a night | 01:14 | |
| _mup_ | ensemble/config-set r209 committed by bcsaller@gmail.com | 03:20 |
| _mup_ | wip to show kapil | 03:20 |
| _mup_ | ensemble/config-set r210 committed by bcsaller@gmail.com | 03:29 |
| _mup_ | fix typo | 03:29 |
| hazmat | bcsaller, this is what i was thinking of for the test api https://pastebin.canonical.com/47020/ | 03:58 |
| bcsaller | that looks like a good start | 04:00 |
| _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 | 05:44 |
| _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:15 |
| _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:57 |
| _mup_ | ensemble/expose-provisioning r236 committed by jim.baker@canonical.com | 06:59 |
| _mup_ | Properly expose services if provisioning agent restarts | 06:59 |
| kim0 | Morning everyone | 08:58 |
| === TeTeT_ is now known as TeTeT | ||
| _mup_ | ensemble/config-get r209 committed by bcsaller@gmail.com | 09:54 |
| _mup_ | still dealing with bad merge from before, forward prop changes | 09:54 |
| _mup_ | ensemble/config-set r212 committed by bcsaller@gmail.com | 10:06 |
| _mup_ | check point config set | 10:06 |
| kim0 | niemeyer: Morning o/ | 13:57 |
| hazmat | g'morning folks | 14:02 |
| hazmat | niemeyer, i think that's the last branch for resolved in review | 14:03 |
| 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:11 |
| kim0 | not that I care much, but new members will probably be too excited seeing their own name besides their formulas and stuff | 14:12 |
| 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:19 |
| 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:20 |
| 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:21 |
| hazmat | ah.. ic.. you can pass --author to bzr commit | 14:22 |
| hazmat | yeah.. we should start using that | 14:22 |
| 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:23 |
| kim0 | cool .. @everyone please do that then while merging :) | 14:24 |
| kim0 | thanks hehe | 14:24 |
| 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:25 |
| 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:26 |
| kim0 | maybe a motd formula! | 14:27 |
| hazmat | kim0, that's machine config, not service deployment. | 14:27 |
| kim0 | well yeah I understand .. mm | 14:28 |
| 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:30 |
| kim0 | so if an admin wants to create users (or change motd) .. do we say ensemble is not for that | 14:31 |
| 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:34 |
| 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:35 |
| hazmat | niemeyer, cool | 14:36 |
| hazmat | re auth | 14:36 |
| niemeyer | hazmat: Yeah, it turned out pretty neat. This enables us to authenticate people in the repo | 14:37 |
| 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:38 |
| kim0 | Yeah, got it .. so what's a good hello-world formula, that hopefully doesn't involve complex config files ..etc | 14:39 |
| 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. | 14:43 |
| _mup_ | Bug #776426 was filed: Add debug hook cli flag for deploy and and add-unit. <Ensemble:New> < https://launchpad.net/bugs/776426 > | 15:26 |
| jimbaker | i should be available when there, but just in case i'm silent: i need to take my toyota to the dealer | 15:53 |
| === niemeyer is now known as niemeyer_lunch | ||
| 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:50 |
| jimbaker | hazmat, i think subcommand support was never really completed in argparse. and that's where the comparison w/ bzr is pretty obvious | 16:56 |
| 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:57 |
| jimbaker | makes sense that in combining functionality - help + subcommands, for example - would should the most gaps in something like argparse | 16:59 |
| === niemeyer_lunch is now known as niemeyer | ||
| 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:49 |
| 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:50 |
| 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:51 |
| koolhead17 | hi all | 17:53 |
| 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:54 |
| bcsaller | I'm happy to try that | 17:55 |
| hazmat | bcsaller, out of curiosity what's the name of the hook (for config-changed)? | 17:58 |
| bcsaller | config-changed | 17:58 |
| bcsaller | later part of the spec has it | 17:59 |
| 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:00 |
| 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:01 |
| _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:09 |
| _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:12 |
| hazmat | i'm not entirely clear what the error handling looks like for configure errors should look like. | 18:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| _mup_ | ensemble/expose-provisioning r239 committed by jim.baker@canonical.com | 18:28 |
| _mup_ | Test comments | 18:28 |
| _mup_ | ensemble/config-get r210 committed by bcsaller@gmail.com | 18:34 |
| _mup_ | better merge resolution, less juggling | 18:34 |
| 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:36 |
| _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:38 |
| 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:42 |
| 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:43 |
| _mup_ | Bug #776605 was filed: Hooks need access to service options <Ensemble:New for bcsaller> < https://launchpad.net/bugs/776605 > | 18:46 |
| * hazmat bangs head against merge | 19:00 | |
| === marrusl is now known as marrusl_afk | ||
| * niemeyer switches to reviewing mode | 19:29 | |
| 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:35 |
| 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:36 |
| 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:37 |
| niemeyer_ | Argh.. | 19:39 |
| niemeyer_ | What was the last message I sent? | 19:39 |
| === niemeyer_ is now known as niemeyer | ||
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| niemeyer | hazmat: (out of band) | 19:50 |
| hazmat | right | 19:50 |
| niemeyer | Is it just me or Launchpad fonts seem to be a bit less readable lately? | 19:56 |
| niemeyer | Setting the font color to black and increasing them a bit does wonders | 19:57 |
| * niemeyer <= getting old | 19:58 | |
| _mup_ | ensemble/expose-provisioning r240 committed by jim.baker@canonical.com | 19:59 |
| _mup_ | Tests for watch_service_states | 19:59 |
| _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:02 |
| hazmat | niemeyer, the resolved branch is ready for review (fixed the accessor issue) | 20:03 |
| niemeyer | hazmat: Sweet, thanks | 20:03 |
| niemeyer | Y.all("body") | 20:05 |
| niemeyer | EWINDOW | 20:05 |
| _mup_ | ensemble/debug-hook-scope-guard r210 committed by kapil.thangavelu@canonical.com | 20:15 |
| _mup_ | merge trunk and resolve conflict. | 20:15 |
| 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:20 |
| niemeyer | hazmat: Although, shouldn't it reexecute? | 20:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:26 |
| niemeyer | hazmat: I'll check it out | 20:28 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| * 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:37 |
| 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:38 |
| niemeyer | hazmat: Yeah, a small task might require some further thinking | 20:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| _mup_ | ensemble/config-state-manager r209 committed by bcsaller@gmail.com | 20:47 |
| _mup_ | get_config shouldn't cache inside service layer | 20:47 |
| _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:14 |
| niemeyer | Hmmm | 21:18 |
| 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:19 |
| hazmat | niemeyer, cheers | 21:21 |
| hazmat | i'm gonna roll out in a few as well for 1.5hr | 21:21 |
| _mup_ | ensemble/expose-provisioning r241 committed by jim.baker@canonical.com | 21:29 |
| _mup_ | Tests for ServiceState.watch_service_units | 21:29 |
| hazmat | hasta luego | 21:42 |
| niemeyer | That was faster than expected | 22:02 |
| _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:19 |
| 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:23 |
| hazmat | backs | 23:25 |
| hazmat | this auto dep stuff has one unforseen requirement.. i need to track the deps pairwise to do the relation work | 23:30 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!