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

Chris Friesen chris.friesen at windriver.com
Tue Oct 27 04:16:52 UTC 2015


On 10/26/2015 06:02 PM, Jay Pipes wrote:

> 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

Sounds good.

> * 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)

I disagree on this one.

As an end-user, if my goal is to take an existing instance and give it bigger 
disks, my first instinct isn't going to be to look at the "move" operation.  I'm 
going to look for "scale", or "resize", or something like that.

And if an admin wants to migrate an instance away from its current host, why 
would they want to change its disk size in the process?

I do think it makes sense to combine the external APIs for live and cold 
migration.  Those two are fundamentally similar, logically separated only by 
whether the instance stays running or not.

And I'm perfectly fine with having the internal implementation of all three 
share a code path, I just don't think it makes sense for the *external* API.

> * 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
enstack.org/cgi-bin/mailman/listinfo/openstack-dev

Sounds good.

Chris



More information about the OpenStack-dev mailing list