Open Stack

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.

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