Open Stack

Yes, CONF.allow_resize_to_same_host exist, but the meaning is that the
current host have chance to be selected in nova-scheduler, the final chosen
host maybe not the current host, in this case, the instance will be
migrated from current host to chosen host and the image will be copied to
the chosen host even if the disk size remain the same.

2015-02-12 15:55 GMT+08:00 Jesse Pretorius <jesse.pretorius at gmail.com>:

> On Thursday, February 12, 2015, Rui Chen <chenrui.momo at gmail.com> wrote:
>>
>>     Currently, resizing instance cause migrating from the host that the
>> instance run on to other host, but maybe the current host is suitable for
>> new flavor. Migrating will lead to copy image between hosts if no shared
>> storage, it waste time.
>>     I think that priority resizing instance on the current host may be
>> better if the host is suitable.
>>     The logic like this:
>>
>> if CONF.allow_resize_to_same_host:
>>     filte current host
>>     if suitable:
>>        resize on current host
>>     else:
>>        select a host
>>        resize on the host
>>
>>     I don't know whether there have been some discussion about this
>> question. Please let me know what do you think. If the idea is no problem,
>> maybe I can register a blueprint to implement it.
>>
>
> But the nova.conf flag for that already exists?
>
> What I would suggest, however, is that some logic is put in to determine
> whether the disk size remains the same while the cpu/ram size is changing -
> if so, then resize the instance on the host without the disk snapshot and
> copy.
>
>
> --
> Jesse Pretorius
> mobile: +44 7586 906045
> email: jesse.pretorius at gmail.com
> skype: jesse.pretorius
>
>
> __________________________________________________________________________
> 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/20150212/231a7ff5/attachment.html>