Open Stack

Hi Sylvain,

The list of filters does not only determine what conditions are checked, it also specifies the order in which they are checked.

If I read the code right this change creates the worst case efficiency for this filter. Normally you would filter first on something that removes as many nodes as possible to cut down the list. It is not normal for large numbers of hosts to be disabled, so this filter should normally come low down the list. This change effectively puts it at the top. 

As an example, imagine you are using AvailabilityZoneFilter and ComputeFilter. Let's say you have three AZs and at any one time a small percentage of your nodes are disabled. These are realistic circumstances. In this case you would filter on the AvaiabilityZoneFilter first and ComputeFilter last. The AZ will cut the number of hosts being considered by two thirds with the ComputeFilter only being executed against the remaining third. If the order is reversed both filters are run against almost all nodes.

Note he following:
1: the default driver for the servicegroup api is db, so this adds a db lookup for every node that would otherwise only be called for remaining nodes after executing other filters.
2: if the driver uses a local in memory cache this is not so bad - but that's not the default

Even if this filter seems dumb, it is still a filtering operation, so why not leave it as a filter in the same model as all the others and under the operators control?

Paul

-----Original Message-----
From: Sylvain Bauza [mailto:sbauza at redhat.com] 
Sent: 06 March 2015 15:19
To: OpenStack Development Mailing List (not for usage questions)
Cc: openstack-operators at lists.openstack.org
Subject: [openstack-dev] [nova] Deprecation of ComputeFilter

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/

-Sylvain


__________________________________________________________________________
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