Chiming in, I'd like taskflow to get into the state-machine area (it's been discussed for a while [1]). It also does the workflow through defined steps[2] until completion (which imho is a subset in a way of the fully changeable state-machine). It also tries to add more value since when u declaratively define what the 'work' should be (within limits) u can then have taskflow execute it (via [3]), making imho your code less complicated (although it at the same time does at a new layer in), and letting taskflow try to help make it reliable for u (helping u do things like resume from a crash, run your code remotely via workers). Of course the library is actively developed (jump on #openstack-state-management) so additions like this or something like in the mentioned machinist library, which seems like just the foundational state-machine classes, could be hooked in/added.
The trouble I've had and that will likely be had with a approach like this is imho the complexity of it (and how much structuring code will there be, aka boilerplate); even currently taskflow already imposes some boilerplate (task/flow/engines objects) and mindset changes to adopting projects. A state-machine would impose similar + more (the states u could think of as task objects, the transitions would have to be some type of table, the reactions would be ?? and so on). Going down this path imho has to be done carefully and with consideration (and nothing will likely be perfect). This has always made me hesitate a little, in that it seems to add a lot of complexity that if not done carefully will cause more pain than goodness (the yin and yang). This is where I'd rather carefully figure out what this state-machine looks like (machinst looks to be the raw state-machine building blocks) and how it will/could be used and what benefit will it be bringing short-term and long-term. But I guess the one way to do it is try & learn (if u don't try u will never learn). Certain other things that become interesting questions for taskflow and any type of state-machine (concepts that taskflow has that are being used that aren't typically thought about): 1. Persistence [4] (see how it is used) 2. What does undoing/reverting/resuming a state-machine even mean? [1] https://etherpad.openstack.org/p/CinderTaskFlowFSM [2] http://docs.openstack.org/developer/taskflow/states.html [3] http://docs.openstack.org/developer/taskflow/engines.html [4] http://docs.openstack.org/developer/taskflow/persistence.html Anyways just some thoughts. -Josh From: Chris Armstrong <chris.armstr...@rackspace.com<mailto:chris.armstr...@rackspace.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Thursday, April 24, 2014 at 9:49 AM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [Heat][Summit] Input wanted - real world heat spec On April 23, 2014 at 7:47:37 PM, Robert Collins (robe...@robertcollins.net<mailto:robe...@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 -- -- Christopher Armstrong IRC: radix
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
