Append blueprint link: https://blueprints.launchpad.net/nova/+spec/verifiable-force-hosts
2015-02-13 10:48 GMT+08:00 Rui Chen <chenrui.m...@gmail.com>: > I agree with you @Chris > '--force' flag is a good idea, it keep backward compatibility and > flexibility. > We can select whether the filters was applied for force_hosts. > I will register blueprint to trace the feature. > > The 'force_hosts' feature is so age-old that I don't know how many users > had used it. > Like @Jay says. Removing it is once and for all idea, but I'm not sure > that it's a suitable occasion. > > 2015-02-12 23:10 GMT+08:00 Chris Friesen <chris.frie...@windriver.com>: > >> On 02/12/2015 03:44 AM, Sylvain Bauza wrote: >> >> Any action done by the operator is always more important than what the >>> Scheduler >>> could decide. So, in an emergency situation, the operator wants to force >>> a >>> migration to an host, we need to accept it and do it, even if it doesn't >>> match >>> what the Scheduler could decide (and could violate any policy) >>> >>> That's a *force* action, so please leave the operator decide. >>> >> >> Are we suggesting that the operator would/should only ever specify a >> specific host if the situation is an emergency? >> >> If not, then perhaps it would make sense to have it go through the >> scheduler filters even if a host is specified. We could then have a >> "--force" flag that would proceed anyways even if the filters don't match. >> >> There are some cases (provider networks or PCI passthrough for example) >> where it really makes no sense to try and run an instance on a compute node >> that wouldn't pass the scheduler filters. Maybe it would make the most >> sense to specify a list of which filters to override while still using the >> others. >> >> Chris >> >> >> ____________________________________________________________ >> ______________ >> 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