Open Stack

Append blueprint link:
https://blueprints.launchpad.net/nova/+spec/verifiable-force-hosts

2015-02-13 10:48 GMT+08:00 Rui Chen <chenrui.momo at 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.friesen at 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-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/20150213/0b5cc6bb/attachment.html>