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