XMLWordPrintable

    • Configurable instance FQDNs
    • False
    • Hide

      None

      Show
      None
    • False
    • OSPRH-120Compute Engineering Backlog
    • Committed
    • Committed
    • To Do
    • OSPRH-120 - Compute Engineering Backlog
    • openstack-nova-27.1.1-18.0.20230930093334.a869ab1.el9ost
    • Committed
    • Committed
    • 0% To Do, 0% In Progress, 100% Done
    • Hide
      .Setting the hostname of the Compute service (nova) instance by using the Compute service API microversions 2.90 and 2.94

      This enhancement enables you to set the hostname of the Compute service (nova) instance by using the Compute service API microversions 2.90 and 2.94 that are now included in the 18.0 release of RHOSO.

      API microversion 2.90 enables you to specify an optional hostname when creating, updating, or rebuilding an instance. This is a short name (without periods), and it appears in the metadata available to the guest OS, either through the metadata API or on the configuration drive. If installed and configured in the guest, `cloud-init` uses this optional hostname to set the guest hostname.

      API microversion 2.94 extends microversion 2.90 by enabling you to specify fully qualified domain names (FQDN) wherever you specify the hostname. When using an FQDN as the instance hostname, you must set the `[api]dhcp_domain` configuration option to the empty string in order for the correct FQDN to appear in the hostname field in the metadata API.
      Show
      .Setting the hostname of the Compute service (nova) instance by using the Compute service API microversions 2.90 and 2.94 This enhancement enables you to set the hostname of the Compute service (nova) instance by using the Compute service API microversions 2.90 and 2.94 that are now included in the 18.0 release of RHOSO. API microversion 2.90 enables you to specify an optional hostname when creating, updating, or rebuilding an instance. This is a short name (without periods), and it appears in the metadata available to the guest OS, either through the metadata API or on the configuration drive. If installed and configured in the guest, `cloud-init` uses this optional hostname to set the guest hostname. API microversion 2.94 extends microversion 2.90 by enabling you to specify fully qualified domain names (FQDN) wherever you specify the hostname. When using an FQDN as the instance hostname, you must set the `[api]dhcp_domain` configuration option to the empty string in order for the correct FQDN to appear in the hostname field in the metadata API.
    • Enhancement
    • Done
    • Automated
    • OSPPlanningCycle3, 2023Q1
    • Compute
    • Approved
    • Red Hat OpenStack Services on OpenShift

      [Continued from https://bugzilla.redhat.com/show_bug.cgi?id=2050827]

      Description of problem:
      As a tenant, i would like to be able to create a nova instance and sepcifiy a hostname and domain in one command such that the instance can resolve it fqdn automatically.

      As a tenant I want nova to dynamically configure neutron port with the per port DNS host and domain name if neutron supports those extensions. all nova create ports should automatically be set with the name provide at boot and pre-created port should be updated if the values are not already set. This should provide a consistent view across nova and neutron with regards to the DNS records for an instance. the precedence should be port DNS values-> nova server create values -> neutron netork DNS domain and finally neutron config.

      As an operator that allows self-service VM creation but does not expose the neutron API to my users is want to allow tenants to configure the DNS name for a VM while not changing the name of existing instances.

      to that end I would like the display name, hostname and FQDN to be passed
      as part of the config drive and metadata API without requiring the use of dynamic/static vendor data. This should enable first boot tools such as cloud-init to statically configure the instance with the host and domain info.

      this feature should extend the recent introduction of a hostname parameter to the server create API to add parity for the domain name. collectively the hostname and domain name parameters when concatenated will form the instance canonical fully qualified domain name.

        There are no Sub-Tasks for this issue.

            grakausk@redhat.com Greg Rakauskas
            alifshit@redhat.com Artom Lifshitz
            rhos-dfg-compute
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: