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
