Open Stack

On 03/06/2015 07:19 AM, Sylvain Bauza wrote:
> Hi,
>
> First, sorry for cross-posting on both dev and operator MLs but I also
> would like to get operators feedback.
>
> So, I was reviewing the scheduler ComputeFilter and I was wondering why
> the logic should be in a filter.
> We indeed already have a check on the service information each time that
> a request is coming in, which is done by
> HostManager.get_all_host_states() - basically called by
> FilterScheduler._schedule()
>
> Instead, I think it is error-prone to leave that logic in a filter
> because it can easily be accidentally removed from the list of filters.
> Besides, the semantics of the filter is not well known and operators
> could not understand that it is filtering on a Service RPC status, not
> the real compute node behind it.
>
> In order to keep a possibility for operators to explicitely ask the
> FilterScheduler to also filter on disabled hosts, I propose to add a
> config option which would be self-explicit.
>
> So, I made a quick POC for showing how we could move the logic to
> HostManager [1]. Feel free to review it and share your thoughts both on
> the change and here, because I want to make sure that we get a consensus
> on the removal before really submitting anything.
>
>
> [1] https://review.openstack.org/#/c/162180/

As mentioned on the bug, I don't think there's a real reason to even 
deprecate the filter. Just remove it, IMHO. It doesn't do anything at all.

As for adding another CONF option, I'm -1 on that. I see no valid reason 
to schedule workloads to disabled hosts.

Best,
-jay