[openstack-dev] [Nova] Migration state machine proposal.
harlowja at fastmail.com
Thu Oct 22 18:14:12 UTC 2015
Nikola Đipanov wrote:
> On 10/21/2015 10:17 PM, Joshua Harlow wrote:
>> Question on some things seen in the below paste.
>> What is with 'finished' -> 'reverted' and 'finished' -> 'confirmed'?
>> Why does it jump over 'reverting' or 'confirming'? Should it?
>> The other question is the difference between 'failed' and 'error' in the
>> first diagram, any idea on why/how these are semantically different? The
>> difference between 'done' and 'finished' are also in my mind
>> semantically confusing.
>> Overall I'm very much inclined to have three state machines (one for
>> each type), vs the mix-mash of all three into one state machine (which
>> causes the confusion around states in the first diagram in that paste).
> So the problem here is that they (as you point out) grew organically,
> and we are exposing these through the API. We need to keep them, and I
> see this BP as simply documenting them with automaton thrown in for it's
> validation and documenting features.
> So - we _do not_ want to change these. Think of them as information for
> human consumption.
Sure, I'm all for not changing them (right now), or changing them after
we have them explicitly defined and can easily understand what they are
(vs right now where it is implicit and not easily understandable); one
step at a time I guess :)
> What we may want to do is add an additional field (called state instead
> of status maybe), that we can use to re-boot states, and define better
> state machines that are easier to write tooling against. This is a
> separate effort, that will surely need a spec and a discussion to get
> the states right.
> That's what we (or at least I) were talking about.
>> Tang Chen wrote:
>>> Please help to take a look at this problem. I was trying to raise it in
>>> the spec discussion.
>>> But since we don't need a spec on this problem, so I want to discuss it
>>> It is about what the new state machine will be.
>>> OpenStack Development Mailing List (not for usage questions)
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev