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_name attribute 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 hostname attribute 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

History

Revisions

Release Name

Description

Wallaby

Introduced

Xena

Reproposed