Change select_destinations() to use request spec
Specification to change the `select_destinations()` scheduler RPC API method to use a `nova.objects.request_spec.RequestSpec` object instead of a nested dict. Co-Authored-By: Sylvain Bauza <sbauza@redhat.com> Change-Id: I9f9a5d48b1203c619b2e9033a9b65934811c996f Blueprint: sched-select-destinations-use-request-spec-object
This commit is contained in:
Jay Pipes
@@ -0,0 +1,209 @@
|
|||||||
|
..
|
||||||
|
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||||
|
License.
|
||||||
|
|
||||||
|
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||||
|
|
||||||
|
=========================================================================
|
||||||
|
select_destinations() scheduler RPC API method to pass RequestSpec object
|
||||||
|
=========================================================================
|
||||||
|
|
||||||
|
https://blueprints.launchpad.net/nova/+spec/sched-select-destinations-use-request-spec-object
|
||||||
|
|
||||||
|
Change the `select_destinations()` scheduler RPC API method to use a
|
||||||
|
`nova.objects.request_spec.RequestSpec` object instead of a nested dict.
|
||||||
|
|
||||||
|
Problem description
|
||||||
|
===================
|
||||||
|
|
||||||
|
The main interface into the scheduler, the `select_destinations()` method,
|
||||||
|
accepts a `request_spec` parameter and a filter_properties parameter that are
|
||||||
|
nested dict.
|
||||||
|
The nested `request_spec` dict is constructed in
|
||||||
|
`nova.scheduler.utils.build_request_spec()`, which is called by nova-conductor
|
||||||
|
before asking the scheduler to find compute nodes on which to put one or more
|
||||||
|
requested virtual machine instances.
|
||||||
|
The nested `filter_properties` dict is mainly built in the
|
||||||
|
`nova.compute.api._build_filter_properties()` method, which is called before
|
||||||
|
asking the scheduler to find compute nodes, but can also be built in other
|
||||||
|
places and needs consistency.
|
||||||
|
|
||||||
|
Previous blueprints have introduced a `nova.objects.request_spec.RequestSpec`
|
||||||
|
object that can model the entire request for multiple instance launches.
|
||||||
|
However, the scheduler RPC API has not been changed to use this new object.
|
||||||
|
Instead, nova-scheduler constructs the `RequestSpec` object in its
|
||||||
|
`_schedule()` method, populating the request spec attributes manually by
|
||||||
|
looking at the `request_spec` dictionary parameter.
|
||||||
|
|
||||||
|
Use Cases
|
||||||
|
----------
|
||||||
|
|
||||||
|
This is a pure refactoring effort for cleaning up all the interfaces in between
|
||||||
|
Nova and the scheduler so the scheduler could be split out by the next cycle.
|
||||||
|
|
||||||
|
Project Priority
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
This blueprint is part of a global effort around the 'scheduler' refactoring
|
||||||
|
for helping it to be split out. This has been defined as the 3rd priority for
|
||||||
|
this Kilo cycle.
|
||||||
|
|
||||||
|
Proposed change
|
||||||
|
===============
|
||||||
|
|
||||||
|
The RequestSpec object will be amended to add the filter_properties fields.
|
||||||
|
The `select_destinations()` scheduler RPC API method will be changed to consume
|
||||||
|
a `nova.objects.request_spec.RequestSpec` object instead of two nested
|
||||||
|
dictionaries. The RPC API will be incremented and translation code blocks will
|
||||||
|
be added to allow older nova-conductor workers to continue to transmit the
|
||||||
|
dictionary `request_spec` and `filter_properties` parameters.
|
||||||
|
|
||||||
|
Alternatives
|
||||||
|
------------
|
||||||
|
|
||||||
|
None.
|
||||||
|
|
||||||
|
Data model impact
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
None.
|
||||||
|
|
||||||
|
REST API impact
|
||||||
|
---------------
|
||||||
|
|
||||||
|
None.
|
||||||
|
|
||||||
|
Security impact
|
||||||
|
---------------
|
||||||
|
|
||||||
|
None.
|
||||||
|
|
||||||
|
Notifications impact
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
None.
|
||||||
|
|
||||||
|
Other end user impact
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
None.
|
||||||
|
|
||||||
|
Performance Impact
|
||||||
|
------------------
|
||||||
|
|
||||||
|
None.
|
||||||
|
|
||||||
|
Other deployer impact
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
None.
|
||||||
|
|
||||||
|
Developer impact
|
||||||
|
----------------
|
||||||
|
|
||||||
|
None, besides making the scheduler call interfaces gradually easier to read
|
||||||
|
and understand.
|
||||||
|
|
||||||
|
Implementation
|
||||||
|
==============
|
||||||
|
|
||||||
|
We will increment the version of the RequestSpec object by adding new fields
|
||||||
|
which were previously provided in the `filter_properties` dictionary. The new
|
||||||
|
RequestSpec object should look like :
|
||||||
|
|
||||||
|
.. code:: python
|
||||||
|
|
||||||
|
class RequestSpec(base.NovaObject):
|
||||||
|
|
||||||
|
"""Models the request to launch one or more instances in the cloud."""
|
||||||
|
|
||||||
|
VERSION = '1.1'
|
||||||
|
|
||||||
|
fields = {
|
||||||
|
'image': fields.DictOfStringsField(nullable=False),
|
||||||
|
# This should eventually be deconstructed into component parts
|
||||||
|
'instance_properties': fields.ObjectField('Instance'),
|
||||||
|
'instance_type': fields.ObjectField('Flavor', nullable=True),
|
||||||
|
'num_instances': fields.IntegerField(nullable=False, default=1),
|
||||||
|
'force_hosts': fields.StringField(nullable=True),
|
||||||
|
'force_nodes': fields.StringField(nullable=True),
|
||||||
|
'pci_requests': fields.ListOfObjectsField('PCIRequest', nullable=True),
|
||||||
|
'retry': fields.ObjectField('Retry', nullable=True),
|
||||||
|
'limits': fields.ObjectField('Limits', nullable=True),
|
||||||
|
'group': fields.ObjectField('GroupInfo', nullable=True),
|
||||||
|
'scheduler_hints': fields.DictOfStringsField(nullable=True)
|
||||||
|
|
||||||
|
}
|
||||||
|
|
||||||
|
PCIRequest, Retry, Limits and GroupInfo objects will be created accordingly.
|
||||||
|
|
||||||
|
We will increment the version of the scheduler RPC API and insert translation
|
||||||
|
blocks in the `select_destinations` method to handle an older nova-conductor
|
||||||
|
node sending the old-style dictionaries `request_spec` and `filter_properties`
|
||||||
|
parameters to a newer nova-scheduler node that expects a `RequestSpec` object.
|
||||||
|
|
||||||
|
The nova-conductor manager code will then be updated to construct a
|
||||||
|
`RequestSpec` object to pass to the `select_destinations()` scheduler RPC API
|
||||||
|
instead of calling `nova.scheduler.utils.build_request_spec()`. The
|
||||||
|
`build_request_spec()` method will then be removed.
|
||||||
|
|
||||||
|
All calls made for updating filter_properties dictionary will be replaced by
|
||||||
|
setting fields to the RequestSpec object attached.
|
||||||
|
|
||||||
|
The code added in the `request-spec-objects` blueprint that constructed a
|
||||||
|
`RequestSpec` object in the `FilterScheduler._schedule()` method will then be
|
||||||
|
removed, as it will no longer be needed since the `request_spec` parameter will
|
||||||
|
already be an object.
|
||||||
|
|
||||||
|
Assignee(s)
|
||||||
|
-----------
|
||||||
|
|
||||||
|
Primary assignee:
|
||||||
|
bauzas
|
||||||
|
|
||||||
|
Work Items
|
||||||
|
----------
|
||||||
|
|
||||||
|
- Increment RequestSpec object by adding new fields related to
|
||||||
|
`filter_properties`
|
||||||
|
|
||||||
|
- Increment the scheduler RPC API `select_destinations()` method to take a
|
||||||
|
`RequestSpec` object instead of a dictionary for the `request_spec`
|
||||||
|
parameter. In the same patch, modify the conductor manager to construct a
|
||||||
|
`RequestSpec` object and pass that to `select_destinations()` instead of
|
||||||
|
dict. Remove the code in filter_scheduler.FilterScheduler._schedule() that
|
||||||
|
constructs a `RequestSpec` object, since the object is now being passed to
|
||||||
|
`select_destinations()`
|
||||||
|
|
||||||
|
- Remove the `nova.scheduler.utils.build_request_spec` function.
|
||||||
|
|
||||||
|
Dependencies
|
||||||
|
============
|
||||||
|
|
||||||
|
This blueprint is dependent on the completion of the following blueprints:
|
||||||
|
|
||||||
|
- `request-spec-object`
|
||||||
|
|
||||||
|
Testing
|
||||||
|
=======
|
||||||
|
|
||||||
|
New unit tests for the request spec objects will be added. The existing unit
|
||||||
|
tests of the scheduler will be overhauled in the patch set that converts the
|
||||||
|
filters to use the new request_spec object model instead of its current
|
||||||
|
free-form `filter_properties` dictionary of things.
|
||||||
|
|
||||||
|
Documentation Impact
|
||||||
|
====================
|
||||||
|
|
||||||
|
Developer reference material that explains the new placement spec class
|
||||||
|
will be delivered as a part of this blueprint.
|
||||||
|
|
||||||
|
References
|
||||||
|
==========
|
||||||
|
|
||||||
|
This blueprint is part of an overall effort to clean up, version, and stabilize
|
||||||
|
the interfaces between the nova-api, nova-scheduler, nova-conductor and
|
||||||
|
nova-compute daemons that involve scheduling and resource decisions.
|
||||||
|
|
||||||
|
See https://wiki.openstack.org/wiki/Gantt/kilo#Tasks for the list of all
|
||||||
|
blueprints targeted for Kilo.
|
||||||
Reference in New Issue
Block a user