Add host and hypervisor_hostname flag to create server
APIImpact Change-Id: I0a543214b975110bb323db48857d13818c299908 Blueprint: add-host-and-hypervisor-hostname-flag-to-create-server
This commit is contained in:
zhu.boxiang
@@ -0,0 +1,233 @@
|
||||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
======================================================
|
||||
Add host and hypervisor hostname flag to create server
|
||||
======================================================
|
||||
|
||||
https://blueprints.launchpad.net/nova/+spec/add-host-and-hypervisor-hostname-flag-to-create-server
|
||||
|
||||
When admin users specify the `forced_host/forced_node`_ to create servers,
|
||||
nova will bypass the scheduler filters. This spec proposes to add two new
|
||||
params ``host`` and ``hypervisor_hostname`` as specified host and/or node to
|
||||
create servers without bypassing the scheduler filters in a new REST API
|
||||
microversion.
|
||||
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
When admin users specify the `forced_host/forced_node`_ to create servers,
|
||||
nova will bypass the scheduler filters.
|
||||
|
||||
* Without scheduler filters, failure instances may waste effort trying to boot
|
||||
when failure is inevitable because of network provider, PCI device, NUMA
|
||||
topology, etc.
|
||||
* We could be trying to claim resources on the host that aren't available,
|
||||
and/or unintentionally over-subscribing the host because without running
|
||||
the filters we don't pass down any limits for the resource claim.
|
||||
|
||||
Use Cases
|
||||
---------
|
||||
|
||||
This change adds the following use case to the system:
|
||||
|
||||
* An admin wants to request that a server is created on a specified compute
|
||||
host and/or node and have the request validated by the scheduler filters
|
||||
rather than forced.
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
* Add ``host`` and ``hypervisor_hostname`` to the REST API ``POST /servers``.
|
||||
* Add a new policy ``os_compute_api:servers:create:requested_destination`` to
|
||||
limit ``host`` and ``hypervisor_hostname`` only for admin.
|
||||
* Translate ``host`` and ``hypervisor_hostname`` to a
|
||||
RequestSpec.requested_destination which still goes through the scheduler
|
||||
filters.
|
||||
|
||||
.. note::
|
||||
|
||||
We still leave the old mechanism ``az:host:node`` in this new microversion
|
||||
so users have the option of either forcing the target during server creates
|
||||
or requesting the target.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
There is a filter named `JsonFilter`_ which is not used by default. This
|
||||
filter allows simple JSON-based grammar for selecting hosts. If we want to
|
||||
specify the host named "openstack-node", we can add the params like this:
|
||||
``--hint query='["=","$host","openstack-node"]'``.
|
||||
|
||||
In addition to the warnings in the documentation for this filter, if it is
|
||||
configurable, it may not be present in all clouds and thus can not be
|
||||
guaranteed for interoperability.
|
||||
|
||||
There is a filter named `AggregateInstanceExtraSpecsFilter`_ which is not used
|
||||
by default. This filter checks that the aggregate metadata satisfies any extra
|
||||
specifications associated with the instance type (that have no scope or are
|
||||
scoped with ``aggregate_instance_extra_specs``). If we want to specify the
|
||||
host named "openstack-node", we can create a aggregate named "test-ag01"
|
||||
include host "openstack-node". Then we set metadata for this aggregate with
|
||||
``host=openstack-node``. At last, we create a flavor and set metadata for
|
||||
this flavor with ``aggregate_instance_extra_specs:host=openstack-node``. So
|
||||
when we choose the flavor to create instances, all will be on the host
|
||||
"openstack-node".
|
||||
|
||||
In this case, creating an aggregate and flavor pinned to that aggregate for
|
||||
every host/node in a large cloud is not manageable and would also potentially
|
||||
leak deployment details about the cloud, and also confuse users when we have
|
||||
so many availability zones to model those aggregates. It's just not a
|
||||
realistic option for this use case in a large cloud.
|
||||
|
||||
.. _JsonFilter: https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#jsonfilter
|
||||
.. _AggregateInstanceExtraSpecsFilter: https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#aggregateinstanceextraspecsfilter
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
||||
None
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
||||
In a new microversion add the ``host`` and ``hypervisor_hostname`` flag
|
||||
to the API, both of them are optional:
|
||||
|
||||
* POST /servers
|
||||
|
||||
::
|
||||
|
||||
{
|
||||
"server": {
|
||||
...
|
||||
"host": "openstack-node",
|
||||
"hypervisor_hostname": "openstack-node"
|
||||
}
|
||||
}
|
||||
|
||||
Only show new parameters' JSON schema definition for body data of ``server``:
|
||||
|
||||
::
|
||||
|
||||
'host': parameter_types.hostname
|
||||
'hypervisor_hostname': parameter_types.hostname
|
||||
|
||||
Depending on whether/how the ``host`` and ``hypervisor_hostname`` is set,
|
||||
the actions are as followed:
|
||||
|
||||
- If ``host`` is supplied in the request body, at first Compute API will check
|
||||
whether we can fetch a compute node for this ``host`` from DB. If not, an
|
||||
``HTTP 400 Bad Request`` will be returned to users.
|
||||
|
||||
- If ``hypervisor_hostname`` is supplied in the request body, at first
|
||||
Compute API will check whether we can fetch a compute node for this
|
||||
``hypervisor_hostname`` from DB. If not, an ``HTTP 400 Bad Request`` will
|
||||
be returned to users.
|
||||
|
||||
- If both ``host`` and ``hypervisor_hostname`` are supplied in the request
|
||||
body, at first Compute API will check whether we can fetch a compute node
|
||||
for ``host`` and ``hypervisor_hostname`` from DB. If not, an
|
||||
``HTTP 400 Bad Request`` will be returned to users.
|
||||
|
||||
.. note::
|
||||
|
||||
The new (``host`` and/or ``hypervisor_hostname``) and the old
|
||||
(``az:host:node``) mechanisms are mutually exclusive. If both are specified
|
||||
in the same request, the API will return an HTTP 400 Bad Request.
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
None
|
||||
|
||||
Notifications impact
|
||||
--------------------
|
||||
|
||||
None
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
|
||||
Update python-novaclient and python-openstackclient to support the new
|
||||
microversion.
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
None
|
||||
|
||||
Other deployer impact
|
||||
---------------------
|
||||
|
||||
None
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
None
|
||||
|
||||
Upgrade impact
|
||||
--------------
|
||||
|
||||
None
|
||||
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
|
||||
Primary assignee:
|
||||
Boxiang Zhu (zhu.boxiang@99cloud.net)
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
* Add new microversion for this change.
|
||||
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
None
|
||||
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
* Functional and unit test will be provided.
|
||||
* Some scenarios (Create a server on a requested host and/or node and then
|
||||
move it - live migrate, evacuate, cold migrate and unshelve - to make sure
|
||||
it moves to another host and isn't restricted to the original requested
|
||||
destination) will be provided.
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
* The API document should be changed to introduce this new feature.
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. _forced_host/forced_node: https://docs.openstack.org/nova/latest/admin/availability-zones.html
|
||||
|
||||
* Train PTG etherpad: https://etherpad.openstack.org/p/nova-ptg-train
|
||||
|
||||
|
||||
History
|
||||
=======
|
||||
|
||||
.. list-table:: Revisions
|
||||
:header-rows: 1
|
||||
|
||||
* - Release Name
|
||||
- Description
|
||||
* - Train
|
||||
- Introduced
|
||||
Reference in New Issue
Block a user