Open Stack

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).

>       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).

>
> 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