[openstack-dev] [Nova] Migration state machine proposal.
jaypipes at gmail.com
Tue Oct 27 00:02:56 UTC 2015
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:
I think there's a lot of good ideas in that proposal. Please do have a
look at it.
More information about the OpenStack-dev