[openstack-dev] [Nova] Migration state machine proposal.
tangchen at cn.fujitsu.com
Thu Oct 22 02:13:13 UTC 2015
On 10/22/2015 05:17 AM, Joshua Harlow wrote:
> Question on some things seen in the below paste.
> What is with 'finished' -> 'reverted' and 'finished' -> 'confirmed'?
Let's take confirm as an example. Please refer to function confirm_resize().
Resize is one type of migration in the current implement. It needs some
confirmation, and should destroy the source VM after the migration finished.
I guess the 'finished' state means just the migration is finished. Not
resize process. Just my guess.
> Why does it jump over 'reverting' or 'confirming'? Should it?
Not sure. I think it is just the original design. The confirmation and
of the source VM may take some time. So it needs a state to indicate the
operation is on going.
> 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.
Yes, they are confusing. That is also why I raised this question.
About 'failed' and 'error', by reading the code, I think 'error' means
some known or defined exceptions, and we know how to handle it. 'failed'
unexpected exceptions happened.
And 'finished', 'completed', 'done' are just used by different types of
I cannot tell the difference. So I suggest to unify them.
> 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).
That is an idea. But I would prefer to have one single state machine for
because resize and evacuate are reusing migration. They can be in one
It would be very helpful if the designer of the migration process could
share his idea.
But if it is just some code modified by many people many times, I think
remove the confusing states and give a easier, better state machine.
> 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)
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev