Open Stack

Clint Byrum <clint at fewbar.com> wrote on 10/30/2013 01:42:53 PM:
> ...
> 
> The engine should store _all_ of its state in a distributed data store
> of some kind. Any engine should be aware of what is already happening
> with the stack from this state and act accordingly. That includes the
> engine currently working on actions. When viewed through this lense,
> to me, locking is a poor excuse for serializing the state of the engine
> scheduler.

I agree.  I reached a similar conclusion this spring when thinking through 
the multi-engine issue for my group's work.

> It feels like TaskFlow is the answer, with an eye for making sure
> TaskFlow can be made to work with distributed state. I am not well
> versed on TaskFlow's details though, so I may be wrong. It worries me
> that TaskFlow has existed a while and doesn't seem to be solving real
> problems, but maybe I'm wrong and it is actually in use already.

As Zane pointed out when I asked, there is a difference between 
orchestration and workflow: orchestration is about bringing two things 
into alignment, and can adapt to changes in one or both along the way; I 
think of a workflow as an ossified orchestration, it is not so inherently 
adaptable (unless you write a workflow that is really an orchestrator). 
Adaptability gets even more important when you add more agents driving 
change into the system.

Regards,
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131030/a59d9203/attachment-0001.html>