[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