Open Stack

On 11/05/2015 02:36 AM, Jonathan D. Proulx wrote:
> 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*

Hi Jonathan,

I'm sorry that I cannot understand why resize and migrate are the same 
thing behind.

I have some understanding of my own here, please help to review.
https://blueprints.launchpad.net/nova/+spec/migration-type-refactor

I'm not sure if I understand it right or wrong. In my understanding, 
resizing a VM doesn't need to migrate it.

Thanks.

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