[openstack-dev] [Nova] Migration state machine proposal.
tangchen at cn.fujitsu.com
Tue Oct 27 08:39:25 UTC 2015
On 10/27/2015 12: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?
This is also where I got confused before. So please refer to my previous
mail. I think to user, nova service, and driver, they are in 3 different
levels, and migration type may mean different things to them.
> 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.
Yes, this is in nova service level.
> 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
> Sounds good.
> OpenStack Development Mailing List (not for usage questions)
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev