Open Stack

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:

PATCH /servers/<UUID>

with some corresponding request payload that would indicate the required 
changes.

> 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?

Best,
-jay

>> * 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