Open Stack

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
>>