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

Jonathan D. Proulx jon at csail.mit.edu
Wed Nov 4 18:36:56 UTC 2015


On Wed, Nov 04, 2015 at 06:17:17PM +0000, Murray, Paul (HP Cloud) wrote:
:> From: Jay Pipes [mailto:jaypipes at gmail.com]
:> 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.
:
:
:Sorry I am so late to this - but this stuck out for me. 
:
:Resize is an operation that a cloud user would do to his VM. Usually the
:cloud user does not know what host the VM is running on so a resize does 
:not appear to be a move at all.
:
:Migrate is an operation that a cloud operator does to a VM that is not normally
:available to a cloud user. A cloud operator does not change the VM because 
:the operator just provides what the user asked for. He only choses where he is 
:going to put it.
:
:It seems clear to me that resize and migrate are very definitely different things,
:even if they are implemented using the same code path internally for convenience.
:At the very least I believe they need to be kept separate at the API so we can apply
:different policy to control access to them.

As an operator I'm with Paul on this.

By all means use the same code path becasue behind the scenes it *is*
the same thing.  

BUT, at the API level we do need the distinction particularly for access
control policy. The UX 'findablility' is important too, but if that
were the only issue a bit of syntactic sugar in the UI could take care
of it.

-Jon



More information about the OpenStack-dev mailing list