Update the Domain Name

Containerized OpenStack services in StarlingX OpenStack are deployed behind an ingress controller (nginx) that listens, by default, on either port 80 (HTTP) or port 443 (HTTPS).

About this task

The ingress controller routes packets to the specific OpenStack service, such as the Cinder service, or the Neutron service, by parsing the FQDN in the packet. For example, neutron.openstack.svc.cluster.local is for the Neutron service, cinder‐api.openstack.svc.cluster.local is for the Cinder service.

This routing requires that access to OpenStack REST APIs (directly or via remote OpenStack CLIs) must be via a FQDN. You cannot access OpenStack REST APIs using an IP address.

FQDNs (such as cinder‐api.openstack.svc.cluster.local) must be in a DNS server that is publicly accessible.


It is possible to wild‐card a set of FQDNs to the same IP address in a DNS server configuration so that you don’t need to update the DNS server every time an OpenStack service is added. Check your particular DNS server for details on how to wild-card a set of FQDNs.

In a “real” deployment, that is, not a lab scenario, you cannot use the default openstack.svc.cluster.local domain name externally. You must set a unique domain name for your StarlingX OpenStack system. Use the system service‐parameter-add command to configure and set the OpenStack domain name:


  • You must have an external DNS Server for which you have authority to add new domain name to IP address mappings (e.g. A, AAAA or CNAME records).

  • The DNS server must be added to your|prod-long| DNS list.

  • Your DNS server must have A, AAAA or CNAME records for the following domain names, representing the corresponding openstack services, defined as the OAM Floating IP address. Refer to the configuration manual for the particular DNS server you are using on how to make these updates for the domain you are using for the StarlingX OpenStack system.


    StarlingX recommends that you not define domain names for services you are not using.

    # define A record for general domain for StarlingX system
    <my-stx-domain> IN A
    # define alias for general domain for horizon dashboard REST API URL
    horizon.<my-stx-domain> IN CNAME <my-stx-domain>.<my-company>.com
    # define alias for general domain for keystone identity service REST
    API URLs
    keystone.<my-stx-domain> IN CNAME <my-stx-domain>.<my-company>.com
    keystone-api.<my-stx-domain> IN CNAME <my-stx-domain>.<my-company>.com
    # define alias for general domain for neutron networking REST API URL
    neutron.<my-stx-domain> IN CNAME <my-stx-domain>.<my-company>.com
    # define alias for general domain for nova compute provisioning REST
    API URLs
    nova.<my-stx-domain> IN CNAME <my-stx-domain>.<my-company>.com
    nova-api-internal.<my-stx-domain> IN CNAME <my-stx-domain>.<my-company>.com
    placement.<my-stx-domain> IN CNAME <my-stx-domain>.<my-company>.com
    rest-api.<my-stx-domain> IN CNAME <my-stx-domain>.<my-company>.com
    # define no vnc proxy alias for VM console access through Horizon REST
    novncproxy.<my-stx-domain> IN CNAME <my-stx-domain>.<my-company>.com
    # define alias for general domain for barbican secure storage REST API URL
    barbican.<my-stx-domain> IN CNAME <my-stx-domain>.<my-company>.com.
    # define alias for general domain for glance VM management REST API URL
    glance.<my-stx-domain> IN CNAME <my-stx-domain>.<my-company>.com.
    # define alias for general domain for cinder block storage REST API URL
    cinder.<my-stx-domain> IN CNAME <my-stx-domain>.<my-company>.com
    cinder2.<my-stx-domain> IN CNAME <my-stx-domain>.<my-company>.com
    cinder3.<my-stx-domain> IN CNAME <my-stx-domain>.<my-company>.com
    # define alias for general domain for heat orchestration REST API URLs
    heat.<my-stx-domain> IN CNAME <my-stx-domain>.<my-company>.com
    cloudformation.<my-stx-domain> IN CNAME my-stx-domain.<my-company>.com
    # define alias for general domain for starlingx REST API URLs
    # ( for fault, patching, service management, system and VIM )
    fm.<my-stx-domain> IN CNAME <my-stx-domain>.<my-company>.com
    patching.<my-stx-domain> IN CNAME <my-stx-domain>.<my-company>.com
    smapi.<my-stx-domain> IN CNAME <my-stx-domain>.<my-company>.com
    sysinv.<my-stx-domain> IN CNAME <my-stx-domain>.<my-company>.com
    vim.<my-stx-domain> IN CNAME <my-stx-domain>.<my-company>.com


  1. Source the environment.

    $ source /etc/platform/openrc
  2. To set a unique domain name, use the system service‐parameter-add command.

    The command has the following syntax.

    ~(keystone_admin)$ system service-parameter-add openstack helm endpoint_domain=<domain_name>

    <domain_name> should be a fully qualified domain name that you own, such that you can configure the DNS Server that owns <domain_name> with the OpenStack service names underneath the domain.

    See the prerequisites for a complete list of FQDNs.

    For example:

    ~(keystone_admin)$ system service-parameter-add openstack helm endpoint_domain=my-|prefix|-domain.mycompany.com


    If an error occurs, remove the following ingress parameters, nova-cluster-fqdn and nova-namespace-fqdn and reapply OpenStack using system application-apply stx-openstack.

  3. Apply the stx-openstack application.

    For example:

    ~(keystone_admin)$ system application-apply stx-openstack


The helm charts of all OpenStack services are updated and restarted. For example cinder‐api.openstack.svc.cluster.local would be changed to cinder‐api.my-stx-domain.mycompany.com, and so on for all OpenStack services.


OpenStack Horizon is also changed to listen on horizon.my-stx-domain.mycompany.com:80 (instead of the initial oam‐floating‐ip:31000), for example, horizon.my-wr-domain.mycompany.com:80.


After changing the StarlingX OpenStack Helm endpoint domain using the above procedure, OpenStack will switch from Kubernetes node_port controller to the nginx ingress controller, that adds a 2500 MiB size limit to all HTTP requests done using OpenStack Horizon Web Interface for security reasons.


For images that are larger than 2500 MiB in size, uploading the images using Horizon Web Interface will fail. Use the steps below to change the maximum image size supported by the Horizon ingress resource, by applying an override to the Horizon Helm chart.

  1. Create a horizon-overrides.yaml file using the following overrides, and change the value of the proxy-body-size to the new size. For example, to support uploads of images up to 3500 MiB in size using the Horizon Web Interface, update the following value:

    cat <<EOF > horizon-overrides.yaml
            nginx.ingress.kubernetes.io/proxy-body-size: "3500m"
  2. Use the system helm-override-update command to update the overrides for the Horizon Helm chart.

    ~(keystone_admin)]$ system helm-override-update stx-openstack horizon openstack --values=horizon-overrides.yaml
  3. Apply the updated Horizon Helm chart overrides to the stx-openstack application

    ~(keystone_admin)$ system application-apply stx-openstack