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:sba...@redhat.com] 
Sent: 06 March 2015 15:19
To: OpenStack Development Mailing List (not for usage questions)
Cc: openstack-operat...@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-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