filters should be applied to the list of hosts that are in ‘force_hosts’.

Yes, @Gray, it's my point.

Operator can live-migrate a instance to a specified host and skip filters,
 it's apposite and important, I agree with you.

But when we boot instance, we always want to launch a instance successfully
or get a clear failure reason, if the filters are applied for the force
host, operator maybe find out that he is doing something wrong at earlier
time. For example, he couldn't boot a pci instance on a force host that
don't own pci device.

and I don't think 'force_hosts' is operator action, the default value is
'is_admin:True' in policy.json, but in some case the value may be changed
so that the regular user can boot instance on specified host.

2015-02-12 17:44 GMT+08:00 Sylvain Bauza <sba...@redhat.com>:

>
> Le 12/02/2015 10:05, Rui Chen a écrit :
>
> Hi:
>
>     If we boot instance with 'force_hosts', the force host will skip all
> filters, looks like that it's intentional logic, but I don't know the
> reason.
>
>     I'm not sure that the skipping logic is apposite, I think we should
> remove the skipping logic, and the 'force_hosts' should work with the
> scheduler, test whether the force host is appropriate ASAP. Skipping
> filters and postponing the booting failure to nova-compute is not advisable.
>
>      On the other side, more and more options had been added into flavor,
> like NUMA, cpu pinning, pci and so on, forcing a suitable host is more and
> more difficult.
>
>
> 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.
>
> -Sylvain
>
>
>
>  Best Regards.
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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
>
>
__________________________________________________________________________
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

Reply via email to