Hi Joshua,
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
the whole
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
destroying
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
we caught
some known or defined exceptions, and we know how to handle it. 'failed'
means
unexpected exceptions happened.
And 'finished', 'completed', 'done' are just used by different types of
migrations.
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
migration,
because resize and evacuate are reusing migration. They can be in one
state machine.
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
we should
remove the confusing states and give a easier, better state machine.
Thanks.
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-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
