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.

Note

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:

Prerequisites

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.

Note

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 10.10.10.10

# 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
API URL
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

Procedure

Source the environment.

$ source /etc/platform/openrc
~(keystone_admin)$

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
```
Note

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.

Apply the stx-openstack application.

For example:

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

Results

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.

Note

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.

Postrequisites

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.

Note

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.

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
network:
  dashboard:
    ingress:
      annotations:
        nginx.ingress.kubernetes.io/proxy-body-size: "3500m"
EOF
```

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

Apply the updated Horizon Helm chart overrides to the stx-openstack application
```
~(keystone_admin)$ system application-apply stx-openstack
```