[openstack-dev] [Nova] State machines in Nova
harlowja at fastmail.com
Tue May 31 22:26:43 UTC 2016
Andrew Laski wrote:
> On Tue, May 31, 2016, at 04:26 PM, Joshua Harlow wrote:
>> Timofei Durakov wrote:
>>> Hi team,
>>> there is blueprint that was approved during Liberty and resubmitted
>>> to Newton(with spec).
>>> The idea is to define state machines for operations as live-migration,
>>> resize, etc. and to deal with them operation states.
>>> The spec PoC patches are overall good. At the same time I think is will
>>> be good to get agreement on the usage of state-machines in Nova.
>>> There are 2 options:
>>> * implement proposed change and use state machines to deal with states
>> I think this is what could be called the ironic equivalent correct?
>> In ironic @
>> the state machine here is used to ensure proper states are transitioned
>> over and no invalid/unexpected state transitions happen. The code though
>> itself still runs in a implicit fashion and afaik only interacts with
>> the state machine as a side-effect of actions occurring (instead of the
>> reverse where the state machine itself is 'driving' those actions to
>> happen/to completion).
> Yes. This exists in a limited form already in Nova for instances and
Right, I think I remember some attempts by some redhat folks to try to
extract that information (I think it was via some complex grep scripts)
into a state-table; don't quite think that ever got anywhere though
(that I think was trying to create an equivalent of
http://docs.openstack.org/developer/ironic/dev/states.html if I recall).
Maybe a first step to this all is to try to extract the task_states into
an official state machine, ending up with something like
(which is combined into a state machine at
...); then associate that machine with an instance and then in all prior
locations where something like 'instance.task_state=XYZ' was happening
change that to be instance.task_transition(new_task_state); that would
use the state-machine for validation for allowed transitions (and would
likely also help in centralizing what the valid states are, and as a
side-effect of doing that nova can produce a similar svg diagram as
ironic has when that is done).
Might be useful to find out some of the pros/cons from the ironic folks
as they have gone through option #1 already (not many projects, maybe
outside of heat, cue, octavia, .... ? from what I can tell have gone
with option #2 from the start, although I would have liked them to, ha).
>>> o procs:
>>> + could be implemented/merged right now
>>> + cleans up states for migrations
>>> o cons:
>>> + state machine only deal with states, and it will be hard to
>>> build on top of it task API, as bp  was designed for
>>> another thing.
>>> * use state machines in Task API(which I'm going to work on during
>>> next release):
>> So this would be the second model described above, where the state
>> machine (or set of state machines) itself (together could be formed into
>> a action plan, or action workflow or ...) would be the 'entity'
>> realizing a given action and ensuring that it is performed until
>> completed (or tracking where it was paused and such); is that correct?
>>> o procs:
>>> + Task API will orchestrate and deal with long running tasks
>>> + usage state-machines could help with actions
>>> o cons:
>>> + big amount of work
>>> + requires time.
>>> I'd like to discuss these options in this thread.
>> It seems like one could progress from the first model to the second one,
>> although that kind of progression would still be large (because if my
>> understanding is correct the control of who runs what has to be given
>> over to something else in the second model, similar to the control a
>> taskflow engine or mistral engine has over what it runs); said control
>> means that certain programming models may not map so well (from what I
>> have seen).
> I think working through this as a progression from the first model to
> the second one would be the best plan. Start with formalizing the states
> and their allowed transitions and add checking and error handling around
> that. Then work towards handing off control to an engine that could
> drive the operation.
>>>  -
>>>  - https://review.openstack.org/#/c/320849/
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> OpenStack Development Mailing List (not for usage questions)
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev