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:jaypi...@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-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
