Open Stack

> -----Original Message-----
> From: Andrew Laski [mailto:andrew at lascii.com]
> Sent: 31 May 2016 22:34
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [Nova] State machines in Nova
> 
> 
> 
> 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]).

Do you mean the blueprint was approved - I think it was agreed there was no need for a spec then. There is a spec now because there is a minor API impact (if state names are changed to be cConsistent across types of migration).



> > > 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.p
> > y 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.
> 

I'm inclined to agree with Andrew. I don't see this as inconsistent with the tasks API approach although it may become redundant. The spec is actually pretty simple so why make it wait for something that may exist in the future.


> > >
> > > [1] -
> > > https://blueprints.launchpad.net/openstack/?searchtext=migration-sta
> > > te-machine [2] - https://review.openstack.org/#/c/320849/