Open Stack

Andrew Laski wrote:
>
> On Tue, May 31, 2016, at 04:26 PM, Joshua Harlow wrote:
>> Timofei Durakov wrote:
>>> Hi team,
>>>
>>> there is blueprint[1] that was approved during Liberty and resubmitted
>>> to Newton(with spec[2]).
>>> 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
>>>      only
>> I think this is what could be called the ironic equivalent correct?
>>
>> In ironic @
>> https://github.com/openstack/ironic/blob/master/ironic/common/states.py
>> 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
> task_states.

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 
https://github.com/openstack/ironic/blob/master/ironic/common/states.py 
(which is combined into a state machine at 
https://github.com/openstack/ironic/blob/master/ironic/common/states.py#L197 
...); 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 [1] 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
>>>              rollbacks/retries/etc.
>>>        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.
>
>>> Timofey
>>>
>>> [1] -
>>> https://blueprints.launchpad.net/openstack/?searchtext=migration-state-machine
>>> [2] - https://review.openstack.org/#/c/320849/
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev