| === niemeyer_away is now known as niemeyer | ||
| niemeyer | Hi all! | 04:15 |
|---|---|---|
| jimbaker | niemeyer, hi | 04:15 |
| niemeyer | jimbaker: Hey man | 04:19 |
| jimbaker | niemeyer, hi. just working on algebra with my 10 year old daughter | 04:40 |
| jimbaker | (which incidentally is a lot of fun) | 04:42 |
| niemeyer | jimbaker: Nice, I can imagine | 04:45 |
| TeTeT | success! after adding a key with ssh-keygen as hazmat recommended, the bootstrap did succeed: http://pastebin.ubuntu.com/594364/ | 08:18 |
| 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? | 08:22 |
| TeTeT | ah, figure that machine: 2 refers to the list of instances ... | 08:23 |
| TeTeT | http://ec2-184-72-176-29.compute-1.amazonaws.com/?p=3 | 08:26 |
| TeTeT | there we go! | 08:26 |
| niemeyer | Good morning all | 13:34 |
| hazmat | niemeyer good morning | 13:47 |
| niemeyer | hazmat: Yo! | 13:51 |
| niemeyer | hazmat: How's... Shago!? Not sure that's the proper way to pronounce the name | 13:52 |
| 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. | 13:52 |
| niemeyer | hazmat: Ah, sweet, you're welcome | 13:53 |
| 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 :-) | 13:53 |
| niemeyer | hazmat: Re. the write up, thanks, looking forward to check it out | 13:54 |
| niemeyer | hazmat: Aha, ok | 13:54 |
| niemeyer | hazmat: Heard him barking the other day, and reminded of him | 13:54 |
| niemeyer | hazmat: It's actually quite amazing how motivated he really is, given his age | 13:55 |
| hazmat | niemeyer, indeed, he's pretty awesome, we started doing some regular short runs for him | 13:55 |
| hazmat | 0.5 miles | 13:56 |
| hazmat | or long walks | 13:57 |
| niemeyer | Neat, he must be enjoying it | 13:57 |
| niemeyer | hazmat: Btw, this is interesting: http://xph.us/2011/04/13/introducing-doozer.html | 14:01 |
| hazmat | niemeyer, interesting | 14:05 |
| 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..." | 14:11 |
| niemeyer | hazmat: It feels bad that the guy hasn't done a basic homework on ZooKeeper to understand how it works, though | 14:20 |
| hazmat | niemeyer, agreed | 14:21 |
| niemeyer | hazmat: Man, this is awesome: https://issues.apache.org/jira/browse/ZOOKEEPER-965 | 14:25 |
| niemeyer | It will make our life so much easier | 14:25 |
| hazmat | niemeyer, indeed, we could actually construct transactions for our interactions | 14:49 |
| hazmat | that would be awesome | 14:49 |
| hazmat | niemeyer, i'm wondering if we also need service level relation data.. along the lines of service-config, but for relations. | 14:58 |
| hazmat | i suppose we could say such is derived from the service-config | 14:59 |
| niemeyer | hazmat: In which sense? | 14:59 |
| hazmat | in the sense of making the relation between services take user defined config | 15:00 |
| niemeyer | hazmat: Yeah, this is a case we have to discuss more | 15:01 |
| 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 | 15:02 |
| niemeyer | hazmat: Use cases will tell, though | 15:02 |
| hazmat | niemeyer, yeah.. its not clear that we do.. i'm just brainstorming | 15:02 |
| hazmat | still trying to figure out some of the machine/policy configuration in writing | 15:02 |
| hazmat | going to take a walk around the block bbiab | 15:03 |
| niemeyer | hazmat: Enjoy | 15:05 |
| hazmat | niemeyer, that transaction stuff would be gold for the upgrade cli command, its piecemeal writing approach still makes me concerned about interruptions scenarios | 15:50 |
| niemeyer | hazmat: Yeah, definitely | 15:51 |
| niemeyer | hazmat: I don't think we have any real problems in terms of races, though | 15:51 |
| niemeyer | hazmat: At least I don't see a reason yet | 15:51 |
| === niemeyer is now known as niemeyer_lunch | ||
| _mup_ | ensemble/unit-agent-formula-upgrade r223 committed by kapil.thangavelu@canonical.com | 16:42 |
| _mup_ | resolve some merge conflicts | 16:42 |
| === niemeyer_lunch is now known as niemeyer | ||
| hazmat | hmm.. constructors with like 10 arguments are a little ugly.. | 17:42 |
| niemeyer | "a little" :) | 17:44 |
| jimbaker | there should be a pep | 17:47 |
| 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/ | 17:55 |
| niemeyer | Looking | 17:59 |
| jimbaker | hazmat, definitely a nicer separation at first look | 18:01 |
| 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 | 18:05 |
| hazmat | jimbaker, there's still a read only client there | 18:07 |
| hazmat | and it does have to no-op the store | 18:07 |
| jimbaker | hazmat, sure, that's what i need for the status | 18:08 |
| niemeyer | hazmat: I still don't understand why this is so complex, to be honest | 18:08 |
| jimbaker | what i'm describing is what is necessary for setup of testing for ensemble status | 18:08 |
| hazmat | yup.. it was there before.. main difference functionally now is that its using classmethod constructors | 18:08 |
| hazmat | before in that branch that is | 18:08 |
| 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 | 18:09 |
| niemeyer | hazmat: Conceptually, the problem is so simple | 18:09 |
| jimbaker | hazmat, but i would prefer to ignore storing to disk if possible | 18:09 |
| hazmat | niemeyer, indeed, there are four operations and two sets of parameters and we want to configure and combine the behaviors. | 18:10 |
| niemeyer | hazmat: Which four operations? | 18:10 |
| hazmat | jimbaker, sure.. the state client classes should do what you want, effectively just with UnitWorkflowStateClient.from_domain_object(client, unit) | 18:11 |
| hazmat | niemeyer, read state disk, write state disk, read state history, write state history, read zk state, write zk state. | 18:11 |
| niemeyer | hazmat: There are two operations: write and read | 18:12 |
| jimbaker | hazmat, yes, that also looks simpler | 18:12 |
| niemeyer | hazmat: and the "combine" is actually "doing something in addition to" | 18:12 |
| niemeyer | hazmat: Also, why is the state format different depending on where it's stored? | 18:12 |
| 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) | 18:13 |
| niemeyer | hazmat: No reason for the format to be different, even then | 18:13 |
| 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 | 18:13 |
| hazmat | niemeyer, its not differently stored | 18:14 |
| hazmat | niemeyer, each is a yaml serialization of the state dict | 18:14 |
| niemeyer | hazmat: It is | 18:14 |
| 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. | 18:14 |
| niemeyer | hazmat: Well, the behavior is different | 18:14 |
| niemeyer | hazmat: | 18:14 |
| niemeyer | content = self._read_state_file() | 18:15 |
| niemeyer | if content is None: | 18:15 |
| niemeyer | return {"state": None} | 18:15 |
| niemeyer | return yaml.load(content) | 18:15 |
| niemeyer | hazmat: It's write and read, really | 18:15 |
| niemeyer | hazmat: The difference is where the data comes from | 18:15 |
| hazmat | niemeyer, that same bit should be on the zk _load as well | 18:16 |
| niemeyer | hazmat: Let me try provide a sketch | 18:16 |
| hazmat | its not finished | 18:16 |
| niemeyer | hazmat: I won't code it.. I'll try to demonstrate what I mean with a non-functional sketch | 18:18 |
| hazmat | niemeyer, also out of curiosity did you see my mail to the list re async watchers and their creators? | 18:20 |
| niemeyer | hazmat: Yes, I've already read it.. still thinking about it | 18:21 |
| hazmat | i've been mucking with my outbound mail setup the last few days | 18:21 |
| hazmat | cool | 18:21 |
| niemeyer | hazmat: Re. what I said above, this is what I meant: | 18:21 |
| niemeyer | returnValue( | 18:21 |
| niemeyer | yaml.load(unit_data.get("workflow_state", {}).get( | 18:21 |
| niemeyer | self._zk_state_key, ""))) | 18:21 |
| niemeyer | The stored value is different.. it feels like it could be the same | 18:21 |
| hazmat | niemeyer, if i push workflow to a separate node sure | 18:22 |
| hazmat | for each domain object | 18:22 |
| niemeyer | hazmat: Or add the node to the other side | 18:22 |
| niemeyer | s/node/key | 18:22 |
| niemeyer | But that's minor I think | 18:22 |
| niemeyer | Let me finish the sketch | 18:22 |
| niemeyer | hazmat: http://paste.ubuntu.com/594567/ | 18:34 |
| hazmat | niemeyer, looks good | 18:36 |
| niemeyer | hazmat: It's probably broken, but I think it can be made to work along those lines | 18:36 |
| hazmat | niemeyer, yeah.. that cleans up the rest of the minor method dispatch | 18:37 |
| hazmat | s/minor/excessive | 18:38 |
| hazmat | niemeyer, the one part that's missing is picking up the state directory to construct the path for fs_workflow_identity | 18:40 |
| hazmat | but i can just pass in the directory as arg as it is now | 18:40 |
| _mup_ | ensemble/status-workflow r204 committed by jim.baker@canonical.com | 18:44 |
| _mup_ | Modified test setup in build_topology for test_status such that unit relation states are now created | 18:44 |
| niemeyer | hazmat: Yeah, to the constructor of Disk, specifically | 18:47 |
| jimbaker | hazmat, niemeyer, yes the proposed sketch looks even nicer to work with in terms of separating out disk storage concerns | 18:47 |
| hazmat | niemeyer, looks good thanks | 18:47 |
| niemeyer | hazmat: You're welcome, glad we're pushing this | 18:48 |
| 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 | 18:48 |
| hazmat | the api was the same, but the sketch makes the code much nicer, consolidating extraneous methods. | 18:48 |
| hazmat | bcsaller, jimbaker, niemeyer standup? | 19:02 |
| bcsaller | can I have 10 minutes? | 19:02 |
| hazmat | sure | 19:02 |
| jimbaker | hazmat, bcsaller, that works for me | 19:02 |
| niemeyer | I'm good with skipping it today in the name of pushing things forward | 19:05 |
| 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 | 19:05 |
| jimbaker | niemeyer, also good for me | 19:07 |
| bcsaller | gustavo: yeah, fine for me as well | 19:08 |
| hazmat | sounds good | 19:16 |
| _mup_ | ensemble/unit-status-remote r201 committed by kapil.thangavelu@canonical.com | 19:33 |
| _mup_ | refactor the internals of unit and unit relation workflows to make the implementation simpler, per review and suggestion by gustavo. | 19:33 |
| _mup_ | ensemble/unit-status-remote r202 committed by kapil.thangavelu@canonical.com | 19:43 |
| _mup_ | use a single workflowstateclient for both units and unit relations. | 19:43 |
| jimbaker | hazmat, just tried your new branch | 19:52 |
| jimbaker | i'm getting WorkflowStateClient object has no attribute _workflow, which makes sense since this class var is not being set | 19:53 |
| _mup_ | ensemble/unit-agent-formula-upgrade r224 committed by kapil.thangavelu@canonical.com | 19:53 |
| _mup_ | resolve merge conflict from unit-state-remote | 19:53 |
| jimbaker | new *version* of branch | 19:53 |
| niemeyer | hazmat: Do you mind to compress these class names? | 19:57 |
| hazmat | niemeyer, you mean we dont want State everywhere ;-) | 19:57 |
| niemeyer | hazmat: It doesn't feel like ZookeeperPersistentWorkflowStateBase is better than ZookeeperWorkflowState | 19:57 |
| hazmat | niemeyer, sounds good | 19:58 |
| niemeyer | hazmat: Thanks! | 19:58 |
| _mup_ | ensemble/unit-agent-formula-upgrade r225 committed by kapil.thangavelu@canonical.com | 19:59 |
| _mup_ | bring back unit workflow methods, missed in conflict resolution. | 19:59 |
| jimbaker | hazmat, just setting this classvarible to anything ("foo") allows for the WorkflowStateClient to work | 19:59 |
| hazmat | jimbaker, yeah.. i added that in the last sec | 19:59 |
| jimbaker | hazmat, cool | 20:00 |
| hazmat | jimbaker, i'll fix that up | 20:00 |
| _mup_ | ensemble/unit-status-remote r203 committed by kapil.thangavelu@canonical.com | 20:08 |
| _mup_ | loosen workflow assertion in workflowstate. | 20:08 |
| hazmat | jimbaker, fixed | 20:08 |
| _mup_ | ensemble/status-workflow r205 committed by jim.baker@canonical.com | 20:10 |
| _mup_ | Change to support WorkflowStateClient | 20:10 |
| _mup_ | ensemble/status-workflow r206 committed by jim.baker@canonical.com | 20:11 |
| _mup_ | Merged upstream | 20:11 |
| _mup_ | ensemble/unit-status-remote r204 committed by kapil.thangavelu@canonical.com | 20:11 |
| _mup_ | simplify base classes names. | 20:11 |
| hazmat | niemeyer, done | 20:11 |
| _mup_ | ensemble/status-workflow r207 committed by jim.baker@canonical.com | 20:15 |
| _mup_ | Resolved conflicts | 20:15 |
| _mup_ | ensemble/unit-agent-formula-upgrade r227 committed by kapil.thangavelu@canonical.com | 20:16 |
| _mup_ | pep8 cleanup | 20:16 |
| jimbaker | that's odd, somehow my last merge pulled in trunk instead of kapil's branch. so my branch is very confused now | 20:17 |
| jimbaker | time to recreate | 20:17 |
| jimbaker | actually that's not quite what happened - it pulled in an earlier version of kapil's branch. even worse | 20:17 |
| hazmat | jimbaker, those branches are current with regard to trunk fwiw. | 20:19 |
| 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 | 20:22 |
| jimbaker | weird | 20:22 |
| jimbaker | anyway, i just rebuilt the branch, which was easy since there were no common files | 20:23 |
| jimbaker | maybe it got confused when i did the intermediate fix. no idea | 20:24 |
| _mup_ | ensemble/status-workflow-client r205 committed by jim.baker@canonical.com | 20:24 |
| _mup_ | Rebuilt branch from status-workflow | 20:24 |
| _mup_ | ensemble/unit-status-remote r205 committed by kapil.thangavelu@canonical.com | 20:32 |
| _mup_ | additional doc strings, and sample usage for workflowstateclient. | 20:32 |
| niemeyer | hazmat: I still don't see the reason for us to introduce the action_id concept in Transition | 20:38 |
| 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 | 20:38 |
| hazmat | niemeyer, we probably don't need it, with the workflow / lifecycle factoring the savings is pretty minimal from it | 20:38 |
| niemeyer | hazmat: Cool, I'll add a point there suggesting the removal then | 20:39 |
| hazmat | niemeyer, it was there when i had bunch of loop transitions, and they all wanted to do the same action. | 20:39 |
| hazmat | but those are gone now | 20:39 |
| niemeyer | hazmat: Sweet, that sounds good too :) | 20:40 |
| hazmat | niemeyer, the alias thing, i'll probably going to use for the ensemble resolved --retry | 20:41 |
| hazmat | the sans retry case requires some more thought to add a no hook mode for the scope of a transition. | 20:42 |
| niemeyer | hazmat: Cool, it looks nice | 20:42 |
| niemeyer | hazmat: I think it's just another transition | 20:42 |
| niemeyer | hazmat: A simpler one, actually | 20:43 |
| hazmat | niemeyer, the retry_upgrade.. specifically needs to restart hook execution | 20:44 |
| niemeyer | hazmat: Ah, sorry, I understood it the other way around | 20:44 |
| 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. | 20:44 |
| hazmat | niemeyer, after ugprade and debug-hook, should i continue on to ensemble resolved, or start in on some of the useability items? | 20:46 |
| niemeyer | hazmat: resolved sounds good.. you have the whole context in mind, so it should be easy to get through it | 20:47 |
| hazmat | niemeyer, indeed.. i'll start in on it. | 20:47 |
| niemeyer | hazmat: That sounds awesome, thank you! | 20:49 |
| _mup_ | ensemble/unit-agent-formula-upgrade r228 committed by kapil.thangavelu@canonical.com | 20:53 |
| _mup_ | add missing test_formula module | 20:53 |
| _mup_ | ensemble/unit-status-remote r206 committed by kapil.thangavelu@canonical.com | 21:09 |
| _mup_ | update unit agent signature | 21:09 |
| _mup_ | ensemble/trunk r196 committed by kapil.thangavelu@canonical.com | 21:14 |
| _mup_ | merge unit-status-remote [r=niemeyer][f=759981] | 21:14 |
| _mup_ | Refactors the unit and unit relation workflow state internals, and introduces | 21:14 |
| _mup_ | a WorkflowStateClient that can be used to retrieve workflow state for | 21:14 |
| _mup_ | units, or unit relations from the cli. | 21:14 |
| _mup_ | ensemble/state-machine-enhancements r212 committed by kapil.thangavelu@canonical.com | 21:20 |
| _mup_ | yank transition action_id support | 21:20 |
| 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. | 21:30 |
| hazmat | niemeyer, sounds good | 21:30 |
| hazmat | niemeyer, i've got some missing docs i'm going to add the branch to update the upgrade spec. | 21:34 |
| niemeyer | hazmat: Cool | 21:42 |
| niemeyer | Alright, I'll step out and take a nap | 21:44 |
| niemeyer | Have a good weekend! | 21:44 |
| === niemeyer is now known as niemeyer_away | ||
| _mup_ | ensemble/unit-agent-formula-upgrade r231 committed by kapil.thangavelu@canonical.com | 23:13 |
| _mup_ | doc fixes and move clearing the flag earlier in the upgrade operation sequence. | 23:13 |
| _mup_ | ensemble/status-workflow-client r206 committed by jim.baker@canonical.com | 23:26 |
| _mup_ | Merged trunk | 23:26 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!