@Manickam, thank you for the information :) +1 for the use case -1 for the approach in patch https://review.openstack.org/#/c/117116/
I think we should try to filter the current host and auto fallback to select a host in nova-scheduler if the current host is no suitable. 2015-02-12 16:17 GMT+08:00 Manickam, Kanagaraj <[email protected]>: > Hi, > > > > There is a patch on resize https://review.openstack.org/#/c/117116/ > > To address the resize, there are some suggestions and please refer the > review comments on this patch. > > > > Regards > > Kanagaraj M > > > > *From:* Jesse Pretorius [mailto:[email protected]] > *Sent:* Thursday, February 12, 2015 1:25 PM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [nova] Priority resizing instance on same > host > > > > On Thursday, February 12, 2015, Rui Chen <[email protected]> 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: [email protected] > skype: jesse.pretorius > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
