Sounds similar to https://review.openstack.org/#/c/224022/ (which is the
ironic version of expose state machine transitions over the REST API);
probably useful to read over the review commentary there and/or talk to
the ironic folks about that before doing much here (to learn some of the
pros/cons and such).
Andrew Laski wrote:
On Wed, Jun 1, 2016, at 05:51 AM, Miles Gould wrote:
On 31/05/16 21:03, Timofei Durakov wrote:
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.
+1 to introducing an explicit state machine - IME they make complex
logic much easier to reason about. However, think carefully about how
you'll make changes to that state machine later. In Ironic, this is an
ongoing problem: every time we change the state machine, we have to
decide whether to lie to older clients (and if so, what lie to tell
them), or whether to present them with the truth (and if so, how badly
they'll break). AIUI this would be a much smaller problem if we'd
considered this possibility carefully at the beginning.
This is a great point. I think most people have an implicit assumption
that the state machine will be exposed to end users via the API. I would
like to avoid that for exactly the reason you've mentioned. Of course
we'll want to expose something to users but whatever that is should be
loosely coupled with the internal states that actually drive the system.
Miles
__________________________________________________________________________
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
