We're going to allow non-admin users to see 'OS-EXT-SRV-ATTR:hostname', since they can now configure this. Change-Id: Ice40f4ad60c9625b3f95c4bf429991412d183a8f Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
5.8 KiB
Configurable Instance Hostnames
https://blueprints.launchpad.net/nova/+spec/configurable-instance-hostnames
Allow users to specify an explicit hostname for their instance when creating instances.
Problem description
Nova publishes hostnames for instances via the metadata service and
config drives. This hostname is based on a sanitized version of the
instance display name combined with the domain value specified in
[api] dhcp_domain. As part of the discussion around bug 1581977, it
was noted that there is currently no way to explicitly specify a
hostname and decouple it from the display name. We use the instance's
hostname when DNS
integration is enabled in neutron, and this can result in a lack of
control over hostnames, preventing users doing reasonable things like
naming their instances based on the fully-qualified domain name that the
instance will eventually be available at.
Correct this gap by allowing users to specify an explicit hostname when creating instances.
Use Cases
As a user, I wish to specify an explicit hostname rather than relying on a (poorly) sanitized version of the display name.
Proposed change
Allow users to pass an additional hostname field when
creating new server(s) (POST /servers) and when updating an
existing server (PUT /servers/{id}). This
hostname attribute will have the following constraints:
- It must be 63 characters or less
- It must consist of alphanumeric characters and dashes
(
-). Periods, underscores, and other characters outside this set will be rejected - It cannot end in a dash
Where multiple instances are requested, hostnames will be suffixed
with -{idx}, where {idx} is a 1-based index.
If the combined name and suffix would exceed the 63 character limit, the
name will be rejected.
The OS-EXT-SRV-ATTR:hostname instance attribute, which
is currently admin-only, will now be shown for non-admin users, since it
doesn't make sense to allow users to configure the value but not see
it.
Alternatives
- Remove support for neutron's DNS integration features and require
users explicitly create and configure ports with the
dns_nameattribute before creating the instance. This places extra work on nova and will result in a worse user experience. - Forbid creation of multiple instances when the
hostnameattribute is provided, similar to how we forbid this when a port is provided. This is reasonable but will require a little more effort from users. - Start rejecting instance names that are not valid hostnames. This is a significant breaking change that will impact many users.
Data model impact
None. The Instance object and corresponding database
model and table already have a hostname field/column.
REST API impact
A new microversion will be introduced. When this microversion is
used, users will be able to pass an additional hostname
field when creating new server(s) (POST /servers) and when
updating an existing server (PUT /servers/{id}). This
hostname attribute will have the following constraints:
- It must be 63 characters or less
- It must consist of alphanumeric characters and dashes
(
-). Periods, underscores, and other characters outside this set will be rejected - It cannot end in a dash
Where multiple instances are requested, hostnames will be suffixed
with -{idx}, where {idx} is a 1-based index.
If the combined name and suffix would exceed the 63 character limit, the
name will be rejected.
When updating the hostname of an existing instance, the
dns_name attribute of the port(s) in neutron will be
updated, as will the hostname attribute exposed via the
metadata service.
The OS-EXT-SRV-ATTR:hostname instance attribute, which
is currently admin-only, will now be accessible by non-admin users.
Security impact
None. Hostnames will be validated by both the nova API and neutron to prevent invalid hostnames.
Notifications impact
None.
Other end user impact
The neutron documentation will need to be updated to reflect the changes in behavior.
Performance Impact
None.
Other deployer impact
None.
Developer impact
None.
Upgrade impact
None.
Implementation
Assignee(s)
- Primary assignee:
-
stephenfinucane
- Other contributors:
-
None
Feature Liaison
- Feature liaison:
-
stephenfinucane
Work Items
- Make necessary changes to nova
- Update neutron documentation
Dependencies
None.
Testing
This can be tested via Tempest tests, though this will likely require the designate-tempest-plugin package. The bulk of the lifting will be done with functional and unit tests.
Documentation Impact
Both nova and neutron's documentation will need to be updated to reference this functionality. The api-ref will be updated to document the new fields allowed in the API requests.
References
- https://bugs.launchpad.net/nova/+bug/1581977
- https://review.opendev.org/c/openstack/nova/+/764482
- http://lists.openstack.org/pipermail/openstack-discuss/2020-November/019113.html
History
| Release Name | Description |
|---|---|
| Wallaby | Introduced |