[openstack-dev] [Nova] Migration state machine proposal.

John Garbutt john at johngarbutt.com
Thu Oct 22 13:10:39 UTC 2015


On 22 October 2015 at 10:20, Nikola Đipanov <ndipanov at redhat.com> 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.

+1
That feels like step one.

> So - we _do not_ want to change these. Think of them as information for
> human consumption.
>
> 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.

+1
Honestly, this feels very related to the Task related efforts.

Thanks,
John


>> Josh
>>
>> Tang Chen wrote:
>>> Hi,
>>>
>>> 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
>>> here.
>>> It is about what the new state machine will be.
>>>
>>> http://paste.openstack.org/show/476954/
>>>
>>> Thanks.
>>>
>>>
>>>
>>>
>>> __________________________________________________________________________
>>>
>>> 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
>
>
> __________________________________________________________________________
> 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



More information about the OpenStack-dev mailing list