[openstack-dev] [State-Management] Meeting minutes.

Joshua Harlow harlowja at yahoo-inc.com
Fri May 24 00:53:25 UTC 2013


I reworked a little of the taskflow code and now its own tasks use
something like the undomanager.

https://github.com/yahoo/TaskFlow/blob/master/taskflow/utils.py (search
for RollbackAccumulator)

This class can then be used on its own if desired, or restructured to use
tasks which then also use it.

Thanks for inspiring me to adjust this to use that :-)

On 5/23/13 10:57 AM, "Joshua Harlow" <harlowja at yahoo-inc.com> wrote:

>Sounds like a plan :-)
>
>I think figuring out what the existing and the changed workflow is most
>(if not all) of the battle.
>
>Reworking code that doesn't have a strong concept of workflows into
>something that does will likely always be messy :)
>
>If we code up everything in one task that seems to just get us back to
>unstructured workflows, where now 1 big task is doing everything (which is
>similar to what we have in the current code-base). That’s why I (and I
>think others) think the structure is needed and appropriate since I think
>it helps if you think of actions as tasks and split up your code that way.
>This also helps in testing since you can test a individual task, helps in
>reviewing said task, altering said task... Yes it may not be easier than
>throwing everything in 1 function and declaring victory but hopefully the
>benefits out-way the initially restructuring drawbacks. The undo-manager
>and the taskflow stuff are similar imho, I would consider the taskflow
>stuff to be the next evolution of the undo-manager in a way.
>
>FYI tests are being done!
>
>Java-styleness I am trying to rid myself of, haha. Although I'm not so
>sure what that means, any inputs/changes would be great :-)
>
>On 5/23/13 2:33 AM, "John Garbutt" <john at johngarbutt.com> wrote:
>
>>Just trying to limit what is changing at any one time.
>>
>>Right now moving the code so the control flow is in a central
>>location, such that having tasks (or maybe later, a workflow) is
>>useful.
>>
>>In theory, dropping in that task library should then be fairly easy.
>>We can then deal with restarting services more gracefully, then deal
>>with more graceful error conditions, then looking at rollbacks,
>>restarts, cancels etc.
>>
>>My main concern about TaskFlow (beyond the lack of tests and
>>java-style code) is that I am not sure about the workflows of tasks. I
>>am hoping we will quite quickly get the code into a state where that
>>becomes more obvious (one way or the other). I get the task management
>>and tracking and claiming, but I get the feeling the workflow thing
>>might turn out being quite messy, and might be better coded up inside
>>each task, using things like the undo manager.
>>
>>John
>>
>>On 22 May 2013 22:30, Joshua Harlow <harlowja at yahoo-inc.com> wrote:
>>> Any reason why it couldn't be used from the start? Just not enough time
>>>or
>>> to complicated for now?
>>>
>>> If its to complicated, I'd like to know what the alternative is that is
>>> less complicated if you have any inputs. I see quite a bit of code
>>>moving
>>> around to accomplish the 'moving things' part and it seems like said
>>> moving around could at the same time break it into small pieces (which
>>> seems to make good sense from a coding, structure, design standpoint).
>>> Maybe that¹s to much for a initial move though, thoughts?
>>>
>>> On 5/22/13 3:28 AM, "John Garbutt" <john at johngarbutt.com> wrote:
>>>
>>>>On 22 May 2013 06:18, Karajgi, Rohit <Rohit.Karajgi at nttdata.com> wrote:
>>>>>> In terms of using TaskFlow, I am just starting to take a look at the
>>>>>>code.
>>>>>
>>>>> So are you planning to use this TaskFlow
>>>>>(https://github.com/yahoo/TaskFlow) library
>>>>> to implement the blueprint or just unify the code paths with
>>>>>conductor?
>>>>
>>>>My plan is to unify the code paths, moving things into the new compute
>>>>api section of the conductor.
>>>>
>>>>Once its there, the code should be in a position where we can look at
>>>>using TaskFlow to help manage running of that task, and using
>>>>workflows to split up the task into smaller pieces.
>>>>
>>>>John
>>>>
>>>>_______________________________________________
>>>>OpenStack-dev mailing list
>>>>OpenStack-dev at lists.openstack.org
>>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>



More information about the OpenStack-dev mailing list