Open Stack

On 25 April 2014 04:49, Chris Armstrong <chris.armstrong at rackspace.com> wrote:
> On April 23, 2014 at 7:47:37 PM, Robert Collins (robertc at robertcollins.net)
> wrote:
>
> Hi, we've got this summit session planned -
> http://summit.openstack.org/cfp/details/428 which is really about
> https://etherpad.openstack.org/p/heat-workflow-vs-convergence
>
> We'd love feedback and questions - this is a significant amount of
> work, but work I (and many others based on responses so far) believe
> it is needed to really take Heat to users and ops teams.
>
> Right now we're looking for both high and low level design and input.
>
> One thing I’m curious about is whether we would gain benefit from explicitly
> managing resources as state machines. I’m not very familiar with TaskFlow,
> but my impression is that it basically knows how to run a defined workflow
> through multiple steps until completion. Heat resources will, with this
> change, become objects that need to react to inputs at any point in time, so
> I wonder if it’s better to model them as a finite state machine instead of
> just with workflows.
>
> Granted, I’m pretty unfamiliar with TaskFlow, so I may be off the mark here.
> I would like to point out that a new very simple but concise FSM-modeling
> library was recently released called “Machinist”, and it may be worth taking
> a look at: https://github.com/hybridcluster/machinist

Directly writing the mgmt code in an FSM structure would be pretty
cool I think. It is also perhaps orthogonal, but well worth some
closer examination. Can you perhaps sketch something up for folk to
eyeball?

As far as I see TaskFlow for the current proposal - we're basically
getting 'run a function' as an action, so its a lot simpler in
concept.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud