doc: Clarify how to create your own filter

The filter-scheduler doc was pretty old and I was recently asked to give
some guidance on how to create a custom filter.
A doc is better than any chat, so let's make that better.

Change-Id: I64d24fb4337bb8c1e59a04818307b43f181e2ad2
This commit is contained in:
Sylvain Bauza
2018-02-15 11:21:32 +01:00
parent bf566adada
commit 9526802915

View File

@@ -325,14 +325,32 @@ would be available, and by default the |ComputeFilter|,
|ImagePropertiesFilter|, |ServerGroupAntiAffinityFilter|,
and |ServerGroupAffinityFilter| would be used.
Each filter selects hosts in a different way and has different costs. The order
of ``filter_scheduler.enabled_filters`` affects scheduling performance. The
general suggestion is to filter out invalid hosts as soon as possible to avoid
unnecessary costs. We can sort ``filter_scheduler.enabled_filters`` items by
their costs in reverse order. For example, ComputeFilter is better before any
resource calculating filters like RamFilter, CoreFilter.
In medium/large environments having AvailabilityZoneFilter before any
capability or resource calculating filters can be useful.
Writing Your Own Filter
-----------------------
To create **your own filter** you must inherit from
|BaseHostFilter| and implement one method:
``host_passes``. This method should return ``True`` if a host passes the filter. It
takes ``host_state`` (describing the host) and ``filter_properties`` dictionary as the
parameters.
|BaseHostFilter| and implement one method: ``host_passes``.
This method should return ``True`` if a host passes the filter and return
``False`` elsewhere.
It takes two parameters (named arbitrarily as ``host_state`` and ``spec_obj``):
* the ``HostState`` object allows to get attributes of the host.
* the ``RequestSpec`` object describes the user request, including the flavor,
the image and the scheduler hints.
For further details about each of those objects and their corresponding
attributes, please refer to the codebase (at least by looking at the other
filters code) or ask for help in the #openstack-nova IRC channel.
As an example, nova.conf could contain the following scheduler-related
settings:
@@ -353,16 +371,6 @@ driver. All of the standard nova filters and MyFilter are available to the
FilterScheduler, but just the RamFilter, ComputeFilter, and MyFilter will be
used on each request.
Each filter selects hosts in a different way and has different costs. The order
of ``filter_scheduler.enabled_filters`` affects scheduling performance. The
general suggestion is to filter out invalid hosts as soon as possible to avoid
unnecessary costs. We can sort ``filter_scheduler.enabled_filters`` items by
their costs in reverse order. For example, ComputeFilter is better before any
resource calculating filters like RamFilter, CoreFilter.
In medium/large environments having AvailabilityZoneFilter before any
capability or resource calculating filters can be useful.
Weights
-------