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

John Garbutt john at johngarbutt.com
Thu May 23 09:33:36 UTC 2013


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