Open Stack

On 11/06/2015 12:45 PM, Chris Friesen wrote:
> On 11/05/2015 08:33 AM, Andrew Laski wrote:
>> On 11/05/15 at 01:28pm, Murray, Paul (HP Cloud) wrote:
>
>>> Or more specifically, the migrate and resize API actions both call 
>>> the resize
>>> function in the compute api. As Ed said, they are basically the same 
>>> behind
>>> the scenes. (But the API difference is important.)
>>
>> Can you be a little more specific on what API difference is important 
>> to you?
>> There are two differences currently between migrate and resize in the 
>> API:
>>
>> 1. There is a different policy check, but this only really protects 
>> the next bit.
>>
>> 2. Resize passes in a new flavor and migration does not.
>>
>> Both actions result in an instance being scheduled to a new host.  If 
>> they were
>> consolidated into a single action with a policy check to enforce that 
>> users
>> specified a new flavor and admins could leave that off would that be 
>> problematic
>> for you?
>
>
> To me, the fact that resize and cold migration share the same 
> implementation is just that, an implementation detail.
>
> From the outside they are different things...one is "take this 
> instance and move it somewhere else", and the other "take this 
> instance and change its resource profile".
>
> To me, the external API would make more sense as:
>
> 1) resize
>
> 2) migrate (with option of cold or live, and with option to specify a 
> destination, and with option to override the scheduler if the 
> specified destination doesn't pass filters)

OK. Conceptually speaking, only one case that resize could reuse 
migration code: the current host cannot match the resize condition.
And the VM should be migrated to another host, and do the resize.

So I don't think resize should be one type of migration.

May I understand it like this:  what we are talking about here is a 
3-level conception.

user API                nova service                 driver
migrate                  live-migration               o ff compute node 
storage---shared file system
resize                    cold-migration              o n compute node 
storage---shared file system
rebuild                                                       o n 
compute node storage---nonshared file system
evacuate

Indeed it is a implementation detail. If we can refactor the source code 
as above, maybe it is more clear.

>
>
> And while we're talking, I don't understand why 
> "allow_resize_to_same_host" defaults to False.  The comments in 
> https://bugs.launchpad.net/nova/+bug/1251266 say that it's not 
> intended to be used in production, but doesn't give a rationale for 
> that statement.  If you're using local storage and you just want to 
> add some more CPUs/RAM to the instance, wouldn't it be beneficial to 
> avoid the need to copy the rootfs?

I'm sorry I don't know why it is False by default. But if we can 
refactor the source code, and split resize and migrate conceptually, I 
think we don't need this option any more.

And another question about resize, shall we think about CPU/memory 
hotplug ?  AFAIK, Linux kerenl and qemu are now supporting memory 
hotplug. CPU hotplug in qemu is still being developed. I was thinking 
resize could use these functionalities.

Thanks.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151106/f19cb56b/attachment.html>