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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
