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