[openstack-dev] [Nova] Migration state machine proposal.
jaypipes at gmail.com
Tue Oct 27 23:16:02 UTC 2015
On 10/27/2015 01:16 PM, Chris Friesen wrote:
> 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?
A fair point. However, I think that a generic update VM API, which would
allow changes to the resources consumed by the VM along with capabiities
like CPU model or local disk performance (SSD) is a better way to handle
this than a resize-specific API.
So, in other words, I'd support this:
with some corresponding request payload that would indicate the required
> 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.
I think you meant to say you don't think it makes sense to have three
separate external APIs for what is fundamentally the same operation
(move a VM), right?
>> * 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
> Sounds good.
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev