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