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