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
andhypervisor_hostname
to the REST APIPOST /servers
.Add a new policy
os_compute_api:servers:create:requested_destination
to limithost
andhypervisor_hostname
only for admin.Translate
host
andhypervisor_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.
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 thishost
from DB. If not, anHTTP 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 thishypervisor_hostname
from DB. If not, anHTTP 400 Bad Request
will be returned to users.If both
host
andhypervisor_hostname
are supplied in the request body, at first Compute API will check whether we can fetch a compute node forhost
andhypervisor_hostname
from DB. If not, anHTTP 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¶
Train PTG etherpad: https://etherpad.openstack.org/p/nova-ptg-train
History¶
Release Name |
Description |
---|---|
Train |
Introduced |