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

Tang Chen tangchen at cn.fujitsu.com
Tue Oct 27 08:39:25 UTC 2015

Hi Chris,

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
> enstack.org/cgi-bin/mailman/listinfo/openstack-dev
> Sounds good.
> Chris
> __________________________________________________________________________ 
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list