On 10/22/2015 11:13 AM, Tang Chen wrote:
On 10/22/2015 05:17 AM, Joshua Harlow wrote:
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.
Evacuate does *not* migrate/move anything. Evacuate *rebuilds* VMs from
their original source image.
I support Nikola in that I believe the different migration types should
have different state machines entirely (but be as consistent as possible
in the naming of terminal states like "finished" vs "done" etc)
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.
There isn't a designer of the migration process :( The original (crap,
IMHO) API from Rackspace Cloud Servers API was used for the resize
functionality in the compute API and it's been a source of confusion and
frustration ever since. Relying on a manual confirmation or revert input
from the user was and continues to be a horrible idea.
I believe strongly that we should deprecate the existing migrate,
resize, an live-migrate APIs in favor of a single consolidated,
consistent "move" REST API that would have the following characteristics:
* No manual or wait-input states in any FSM graph
* Removal of the term "resize" from the API entirely (the target
resource sizing is an attribute of the move operation, not a different
type of API operation in and of itself)
* Transition to a task-based API for poll-state requests. This means
that in order for a caller to determine the state of a VM the caller
would call something like GET /servers/<UUID>/tasks/<UUID> in order to
see the history of state changes or subtask operations for a particular
request to move a VM
Timofei Durakov (cc'd) has a blueprint for splitting the live-migration
types into separate task classes here:
https://review.openstack.org/#/c/225910/
I think there's a lot of good ideas in that proposal. Please do have a
look at it.
Best,
-jay
__________________________________________________________________________
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
