[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.
Thanks.
>
> 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