Spec: allocation candidates in tree
This patch proposes a spec to support for filtering allocation candidates by provider tree. Change-Id: I5f403af2e8c98e0804d29ec36dbe4465961b2d83 Blueprint: alloc-candidates-in-tree
This commit is contained in:
Tetsuro Nakamura
parent
d4be64cfab
commit
8ba67f6966
207
specs/stein/approved/alloc-candidates-in-tree.rst
Normal file
207
specs/stein/approved/alloc-candidates-in-tree.rst
Normal file
@ -0,0 +1,207 @@
|
||||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
=============================================
|
||||
Filter Allocation Candidates by Provider Tree
|
||||
=============================================
|
||||
|
||||
https://blueprints.launchpad.net/nova/+spec/alloc-candidates-in-tree
|
||||
|
||||
This blueprint proposes to support for filtering allocation candidates
|
||||
by provider tree.
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
Placement currently supports ``in_tree`` query parameters for the
|
||||
``GET /resource_providers`` endpoints. This parameter is a string representing
|
||||
a resource provider uuid, and when this is present, the response is limited to
|
||||
resource providers within the same tree of the provider indicated by the uuid.
|
||||
See `Nested Resource Providers`_ spec for details.
|
||||
|
||||
However, ``GET /allocation_candidates`` doesn't support the ``in_tree`` query
|
||||
parameter to filter the allocation candidates by resource tree. This results
|
||||
in inefficient post-processing in some cases where the caller has already
|
||||
selected the resource provider tree before calling that API.
|
||||
|
||||
Use Cases
|
||||
---------
|
||||
|
||||
This feature is useful when the caller of the ``GET /allocation_candidates``
|
||||
has already picked up resource providers they want to use.
|
||||
|
||||
As described in the `Bug#1777591`_, when an admin operator creates an instance
|
||||
on a specific host, nova now explicitly sets no limitation for getting
|
||||
allocation candidates to prevent placement from filtering out the
|
||||
pre-determined target resource provider by the random limitation. (For the
|
||||
limitation feature of the API, see the `Limiting Allocation Candidates`_
|
||||
spec)
|
||||
|
||||
Instead of issuing the inefficient request to placement, we can use ``in_tree``
|
||||
query with the pre-determined target host resource provider uuid calling the
|
||||
``GET /allocation_candidates`` API.
|
||||
|
||||
We would solve the same problem for cases of live migration to a specified
|
||||
host and rebuilding an instance on the same host.
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
The ``GET /allocation_candidates`` call will accept a new query parameter
|
||||
``in_tree``. This parameter is a string representing a resource provider uuid.
|
||||
When this is present, the response of the allocation candidates is limited to
|
||||
only allocation requests where at least one resource provider in the specified
|
||||
tree is involved.
|
||||
|
||||
In the following environments,
|
||||
|
||||
.. code::
|
||||
|
||||
+-----------------------+
|
||||
| sharing storage (ss1) |
|
||||
| DISK_GB: 1000 |
|
||||
+-----------+-----------+
|
||||
| Shared via an aggregate
|
||||
+-----------------+----------------+
|
||||
+--------------|---------------+ +--------------|--------------+
|
||||
| +------------+-------------+ | | +------------+------------+ |
|
||||
| | compute node (cn1) | | | |compute node (cn2) | |
|
||||
| | DISK_GB: 1000 | | | | DISK_GB: 1000 | |
|
||||
| +-----+-------------+------+ | | +----+-------------+------+ |
|
||||
| | nested | nested | | | nested | nested |
|
||||
| +-----+------+ +----+------+ | | +----+------+ +----+------+ |
|
||||
| | numa1_1 | | numa1_2 | | | | numa2_1 | | numa2_2 | |
|
||||
| | VCPU: 4 | | VCPU: 4 | | | | VCPU: 4 | | VCPU: 4 | |
|
||||
| +------------+ +-----------+ | | +-----------+ +-----------+ |
|
||||
+------------------------------+ +-----------------------------+
|
||||
|
||||
for example::
|
||||
|
||||
GET /allocation_candidates?resources=VCPU:1,DISK_GB:50&in_tree={cn1_uuid}
|
||||
|
||||
would return 4 combinations of allocation candidates.
|
||||
|
||||
1. numa1_1 (VCPU) + cn1 (DISK_GB)
|
||||
2. numa1_2 (VCPU) + cn1 (DISK_GB)
|
||||
3. numa1_1 (VCPU) + ss1 (DISK_GB)
|
||||
4. numa1_2 (VCPU) + ss1 (DISK_GB)
|
||||
|
||||
Note that candidates number 3 and 4 have "ss1", which is out of the specified
|
||||
tree. They are not excluded because candidates number 3 and 4 have at least
|
||||
one provider (numa1_1 and numa1_2 respectively) from the specified tree.
|
||||
|
||||
The specified tree can be a non-root provider::
|
||||
|
||||
GET /allocation_candidates?resources=VCPU:1,DISK_GB:50&in_tree={numa1_1_uuid}
|
||||
|
||||
would return the same result.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
We could have other query parameters like ``resource_provider_uuid`` or
|
||||
``root_provider_uuid``, but ``in_tree`` would be consistent with the similar
|
||||
``GET /resource_providers`` query parameter.
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
||||
None.
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
||||
A new microversion will be created to add the ``in_tree`` parameter to
|
||||
``GET /allocation_candidates`` API.
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
None.
|
||||
|
||||
Notifications impact
|
||||
--------------------
|
||||
|
||||
None.
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
|
||||
None.
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
If the callers of the ``GET /allocation_candidates`` has already picked up
|
||||
resource providers they want to use, they would get improved performance
|
||||
using this new ``in_tree`` query because we don't need to get all the
|
||||
candidates from the database.
|
||||
|
||||
Other deployer impact
|
||||
---------------------
|
||||
|
||||
This feature enables us to develop efficient query in nova for cases that is
|
||||
described in the `Use Cases`_ section.
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
None.
|
||||
|
||||
Upgrade impact
|
||||
--------------
|
||||
|
||||
None.
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
Tetsuro Nakamura (nakamura.tetsuro@lab.ntt.co.jp)
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
* Update the ``AllocationCandidates.get_by_requests`` method to change the
|
||||
database queries to filter on the specified provider tree.
|
||||
* Update the placement API handlers for ``GET /allocation_candidates`` in
|
||||
a new microversion to pass the new ``in_tree`` parameter to the methods
|
||||
changed in the steps above, including input validation adjustments.
|
||||
* Add functional tests of the modified database queries.
|
||||
* Add gabbi tests that express the new queries, both successful queries and
|
||||
those that should cause a 400 response.
|
||||
* Release note for the API change.
|
||||
* Update the microversion documents to indicate the new version.
|
||||
* Update placement-api-ref to show the new query handling.
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
None.
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
Normal functional and unit testing.
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
Document the REST API microversion in the appropriate reference docs.
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
* `Nested Resource Providers`_ spec
|
||||
* `Bug#1777591`_ reported in the launchpad
|
||||
* `Limiting Allocation Candidates`_ spec
|
||||
|
||||
.. _`Nested Resource Providers`: https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/nested-resource-providers.html
|
||||
.. _`Bug#1777591`: https://bugs.launchpad.net/nova/+bug/1777591
|
||||
.. _`Limiting Allocation Candidates`: https://specs.openstack.org/openstack/nova-specs/specs/queens/implemented/allocation-candidates-limit.html
|
||||
Loading…
Reference in New Issue
Block a user