Nova Dynamic scheduler system

..

This work is licensed under a Creative Commons Attribution 3.0 Unported

License.

http://creativecommons.org/licenses/by/3.0/legalcode

====================================================================

Nova Dynamic scheduler system

====================================================================

The virtual machine (VM) scheduling system in Nova provides an interface for operators to create their own scheduler algorithms. The custom algorithms have to be coded in Python and added/configured in the Nova scheduler agent.

To enable a certain level of dynamism and flexibility which are intrinsic in a Cloud Computing environment, Nova has a JSON scheduler filter, which makes use of a scheduler hint called `query` with a JSON expression that enables one to create simple algorithm such as selecting a host with name "x" or some other host attribute. However, that forces cloud providers to build/use custom front end systems, which in some cases might not be practical.

Problem Description

===================

The JSON scheduler is an interesting approach providing flexibility to operators. That is quite useful when one uses a customer dashboard on top of OpenStack, and that portal can set these metadata when allocating virtual machines. However, for cloud systems that want to use only OpenStack without any other layer of abstraction that is not practical to persist/configure a scheduling algorithm for each VM.

Moreover, the JSON scheduler is limited to executing string matching with the attributes found in the host definition, and one cannot use data from the VM itself, such as project ID, name, flavor, and so on.

On the other hand, creating a new scheduler in Python might not be feasible for some operators as they are not that familiar with the language and processes.

Proposed Change

===============

With the presented context in mind, we look at Ceilometer dynamic pollsters sub-system [1], where a similar situation was faced. There (in Ceilometer), it was created an extension that enables operators to create pollsters using the YML syntax.

Therefore, we are proposing a similar solution for Nova schedulers, where operators can easily create their own rules via the YML syntax, and apply/combine these rules with data gathered from other contexts (not limited to Nova).

We are proposing a YML design with the following options:

- name (mandatory): the name of the dynamic scheduler that the YML defines
- skip_rules (optional): a set of rules (simple Python operations) that determine if the scheduler should be ignored. If one of the rules solves to ``True``, the scheduler is not executed. The previous skip evaluation can be obtained in the subsequent executions via the `value` variable (the initial value is `None`).
- backend_ops (optional): a set of rules (simple Python operations) that determine if the backend (Nova compute host) can/should be considered for the scheduling algorithm. If no rule is created, the default is ``True``.
- scheduling_ops (optional): a set of rules (simple Python operations) that determine which backends (Nova compute host) can/should be considered for the scheduling algorithm. If no rule is created, the default is ``True``. This process is executed with the resulting list of ``backend_ops``. Therefore, at this step, we can see all resulting backends, and decide which one should be kept, and even sort them in our preferred order together while filtering the elements for the other scheduling filters that might be enabled.
- endpoint_type (optional): defines the endpoint type that is used to discover the base URL of the component where we gather metadata to feed in the scheduling algorithm; for Keystone, one can use ``identity``. Other values are accepted such as volume for cinder endpoints, object-store for swift, and so on. If this option is not configured, extra metadata are not captured. Once a URL is configured, the response is loaded into a variable called ``extra_scheduling_metadata``;
- url_path (optional): defines the path of the request that we execute on the endpoint to gather data. For example, to gather data from Keystone, regarding users, one can use ``/v3/users``;
- next_sample_url (optional): if the consumed API returns a linked response that contains a link to the next response set (page), the system can be configured to follow these links and join all linked responses into a single one. Similarly to ``scheduling_ops`` , ``backend_ops``, and ``skip_rules``, operators can use this option to generate the next sample URL path to execute the next request to handle paged responses. If the rules here return ``None``, or if the option is not configured, we assume that there is no next page to execute requests to;
- headers (optional): it is a map of ``key`` and ``value`` that can be used to customize the header of the request that is executed against the URL.

Database changes
================
None

REST API
========
None

Workflows
=========

The dynamic filters, when enabled, execute the following process:
- Load the YML configuration that describes all of the dynamic schedulers that are configured in the Nova scheduler;
- For each scheduler defined in the YML, we execute the process serially; reading from top to bottom of the file, the result of the first dynamic scheduler will be used to feed the next one, and so on. Then, after the dynamic scheduling is finished, its result is returned to the scheduling system to proceed with the other schedulers, if configured;
- For each scheduler, we check if there are the ``endpoint_type`` and ``url_path``configured. If there is none, we move on to the next step. If there is a configuration, we execute the request and store its output. After the first response is retrieved, if there is ``next_sample_url``, we use it to generate the next URL to call. If there is, we merge their responses.
- After loading the metadata, we proceed to the scheduling part. We first call ``backend_ops`` to filter the backends that should be considered for the scheduling;
- After filtering all backends, we move on with the global scheduling algorithm, where one can execute the scheduling with a global perspective on the parameters, all available backends, the request specification to allocate the resource, and some metadata allocated;
- The result is returned to the scheduling manager.

Alternatives
------------
Create hard-coded scheduling algorithms in Python.

Data model impact
-----------------
None

REST API impact
--------------
None

Security Impact
---------------

None

Notifications Impact
--------------------
None

End-user impact
---------------------
None

Performance Impact
------------------
It will depend on the algorithm created by the operators.

Deployer impact
---------------------
Needs to handle the dynamic scheduling system YML file, if one wants to use this feature.

Developer impact
----------------
None

Primary assignee:
- Rafael Weingärtner <email address hidden>

Dependencies
============
None

Testing
=======
Unit tested

Documentation Impact
====================
Need to document this scheduling sub-system and its features. Similar to what we did in [1].

References
==========

[1] https://docs.openstack.org/ceilometer/latest/admin/telemetry-dynamic-pollster.html