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