Configuring DNS as a service

1. Enable the Redis instance.
2. Deploy the DNS service.

Procedure

1. Open your OpenStackControlPlane CR file on your workstation, and enable Redis and add the designate-redis instance to the templates parameter by adding the following:

   ...
     redis:
       enabled: true
       templates:
         designate-redis:
           replicas: 1

   Note

   It is not necessary to remove any other Redis instances that are already defined.

2. Update the OpenStackControlPlane custom resource with the required values for the DNS service.

   Example

   $ oc apply -f openstack_control_plane.yaml -n openstack

Verification

1. Wait until RHOCP creates the DNS service resources related to the OpenStackControlPlane CR. Run the following command to check the status:

   Example

   $ oc get openstackcontrolplane -n openstack

   Sample output

   NAME                      STATUS    MESSAGE
   openstack-control-plane 	Unknown 	Setup started

   The OpenStackControlPlane resources are created when the status is "Setup complete".

   Tip

   Append the -w option to the end of the get command to track deployment progress.

2. Confirm that the Redis instance is running before continuing.

   Example

   $ oc wait --for=condition=ready --timeout=10s \
   pod/designate-redis-redis-0

   Sample output

   pod/designate-redis-redis-0 condition met

1. In the OpenStackControlPlane custom resource (CR) file, enable the DNS service and add the desired designate service configurations and customizations.
2. Update the OpenStackControlPlane CR with the required values for the DNS service.

Procedure

1. Open your OpenStackControlPlane CR file on your workstation, and enable the DNS service (designate) by adding the following:

   designate:
     apiOverride:
       route: {}
     enabled: true
     template:
       nsRecords:
         - hostname: ns1.example.org.
           priority: 1
         - hostname: ns2.example.org.
           priority: 2
   ...

2. Also in the OpenStackControlPlane CR file, add the following designate services configurations:

   designateAPI

   ...
       designateAPI:
         networkAttachments:
         - internalapi
         override:
           service:
             internal:
               metadata:
                 annotations:
                   metallb.universe.tf/address-pool: internalapi
                   metallb.universe.tf/allow-shared-ip: internalapi
                   metallb.universe.tf/loadBalancerIPs: 172.17.0.80
               spec:
                 type: LoadBalancer
   ...

   Note

   Ensure that the annotation values for designateAPI match the annotation values used for the other API services in the current OpenstackControlPlane CR.

   designateBackendbind9

   ...
       designateBackendbind9:
         controlNetworkName: designate
         networkAttachments:
           - designate
         override:
           services:
             - metadata:
                 annotations:
                   metallb.universe.tf/address-pool: designateext
                   metallb.universe.tf/allow-shared-ip: designateext
                   metallb.universe.tf/loadBalancerIPs: 172.34.0.80
               spec:
                 type: LoadBalancer
             - metadata:
                 annotations:
                   metallb.universe.tf/address-pool: designateext
                   metallb.universe.tf/allow-shared-ip: designateext
                   metallb.universe.tf/loadBalancerIPs: 172.34.0.81
               spec:
                 type: LoadBalancer
             - metadata:
                 annotations:
                   metallb.universe.tf/address-pool: designateext
                   metallb.universe.tf/allow-shared-ip: designateext
                   metallb.universe.tf/loadBalancerIPs: 172.34.0.82
               spec:
                 type: LoadBalancer
         replicas: 3
         resources: {}
         serviceUser: designate
         storageClass: local-storage
         storageRequest: 10G
   ...

   Note

   Use a services override for each replica. In the above example, the replica count is 3 so there are 3 services defined. The network attachments might differ in a production system if an additional dedicated network is used to reach the BIND 9 servers.

   designateCentral

   ...
       designateCentral:
         replicas: 3
   ...

   designateMdns

   ...
       designateMdns:
         networkAttachments:
           - designate
         replicas: 3
   ...

   designateProducer

   ...
       designateProducer:
         replicas: 3
   ...

   designateUnbound

   ...
       designateUnbound:
         defaultConfigOverwrite:
           forwarders.conf: |
             forward-zone:
               name: "."
               forward-addr: 172.11.5.155
               forward-addr: 172.12.5.155
         networkAttachments:
           - designate
         override:
           services:
             - metadata:
                 annotations:
                   metallb.universe.tf/address-pool: designateext
                   metallb.universe.tf/allow-shared-ip: designateext
                   metallb.universe.tf/loadBalancerIPs: 172.34.0.90
               spec:
                 type: LoadBalancer
             - metadata:
                 annotations:
                   metallb.universe.tf/address-pool: designateext
                   metallb.universe.tf/allow-shared-ip: designateext
                   metallb.universe.tf/loadBalancerIPs: 172.34.0.91
               spec:
                 type: LoadBalancer
             - metadata:
                 annotations:
                   metallb.universe.tf/address-pool: designateext
                   metallb.universe.tf/allow-shared-ip: designateext
                   metallb.universe.tf/loadBalancerIPs: 172.34.0.93
               spec:
                 type: LoadBalancer
         replicas: 3
         resources: {}
         stubZones:
           - name: example.org
           - name: anotherexample.org
   ...

   • name: Name of the forward zone. This is the full domain name of the zone.
   • forward-addr: <IP_address>: The IP address of the server to forward to. You can use an IP address in either IPv4 or IPv6 format. To use a non-default port for DNS communication, append an @ followed by the port number.
   • replicas - Use a services override for each replica. In the earlier example, the replica count is 3 so there are 3 services defined. The network attachments might differ in a production system if an additional dedicated network is used to reach the Unbound servers.
   • stubZones - An optional section in which you add zone names for the OpenStack Operator to automatically create stub zone records.

   designateWorker

   ...
       designateWorker:
         databaseAccount: designate
         networkAttachments:
           - designate
         replicas: 3
   ...

3. Optional: if you want to configure integration between the Networking service (neutron) and the DNS service, perform the following steps.

   For more information, see Using an integrated DNS service.

   1. Locate the service definition for neutron, and add a customServiceConfig section:

        neutron:
          customServiceConfig: |

   2. Under the customServiceConfig section, add a [DEFAULT] sub-section where you add the domain for your site.

      Example

      In this example, the DNS domain is example.org.. Change this value to the domain appropriate for your site. The value for external_dns_driver in most cases is designate:

        neutron:
          customServiceConfig: |
            [DEFAULT]
            dns_domain = example.org.
            external_dns_driver = designate

   3. Add an [ml2] sub-section and include dns_domain_keywords to the list of neutron extension drivers:

        neutron:
          customServiceConfig: |
            [DEFAULT]
            dns_domain = example.org.
            external_dns_driver = designate
            [ml2]
            extension_drivers=qos,port_security,dns_domain_keywords

   4. Add a [designate] sub-section to customServiceConfig section.

      Example

        neutron:
          customServiceConfig: |
            [DEFAULT]
            dns_domain = example.org.
            external_dns_driver = designate
            [ml2]
            extension_drivers=subnet_dns_publish_fixed_ip
            [designate]
            url = https://designate-internal.openstack.svc:9001/v2
            auth_type = password
            auth_url = {{ .KeystoneInternalURL }}
            username = {{ .ServiceUser }}
            password = {{ .ServicePassword }}
            project_name = service
            project_domain_name = Default
            user_domain_name = Default
            allow_reverse_dns_lookup = true
            ipv4_ptr_zone_prefix_size = 24
            ipv6_ptr_zone_prefix_size = 116
            ptr_zone_email = admin@example.org

      • url: the OpenStack DNS service public endpoint URL with the current version, v2.
      • auth_type: the authorization plug-in to use, either password or token.
      • auth_url: the Identity service (keystone) authorization endpoint URL. The Networking service uses this endpoint to authenticate as a user to create and update reverse lookup zones.
      • username: the username the Networking service uses to create and update reverse lookup zones.
      • password: the password of the user that the Networking service uses to create and update reverse lookup zones.
      • project_name: the name of the project that the Networking service uses to create and update reverse lookup zones.
      • project_domain_name: the name of the domain for the project that the Networking service uses to create and update reverse lookup zones.
      • user_domain_name: the name of the domain for the user that the Networking service uses to create and update reverse lookup zones.
      • allow_reverse_dns_lookup: when true, enables the creation of reverse lookup records.
      • ipv4_ptr_zone_prefix_size: the size in bits of the prefix for the IPv4 reverse lookup zones.
      • ipv6_ptr_zone_prefix_size: the size in bits of the prefix for the IPv6 reverse lookup zones.
      • ptr_zone_email: the email address that the DNS service uses when creating new reverse lookup zones. The default is admin@<dns_domain> where <dns_domain> is the domain for the first record being created in that zone.

4. Update the OpenStackControlPlane custom resource with the required values for the DNS service.

   Example

   $ oc apply -f openstack_control_plane.yaml -n openstack

Verification

1. Wait until RHOCP creates the DNS service resources. Run the following command to check the status:

   $ oc wait designate designate --for condition=Ready

   Sample output

   designate.designate.openstack.org/designate condition met

2. Confirm that the DNS service pods are running:

   $ oc -n openstack get pods | grep -iE "(designate)"

   Sample output

   You should see output similar to the following:

   designate-api-7d8447bc98-cfl22           1/1     Running     0          10s
   designate-backendbind9-0                 1/1     Running     0          15s
   designate-backendbind9-1                 1/1     Running     0          20s
   designate-backendbind9-2                 1/1     Running     0          22s
   designate-central-86c558fb98-82bn2       1/1     Running     0          12s
   designate-central-86c558fb98-0cxz1       1/1     Running     0          19s
   designate-central-86c558fb98-vkj72       1/1     Running     0          12s
   designate-mdns-0                         1/1     Running     0          13s
   designate-mdns-1                         1/1     Running     0          11s
   designate-mdns-2                         1/1     Running     0          15s
   designate-producer-7f69498d75-6wlr8      1/1     Running     0          12s
   designate-producer-7f69498d75-3sd55      1/1     Running     0          10s
   designate-producer-7f69498d75-tvmr9      1/1     Running     0          12s
   designate-redis-redis-0                  2/2     Running     0          11d
   designate-unbound-0                      1/1     Running     0          18d
   designate-unbound-1                      1/1     Running     0          11d
   designate-unbound-2                      1/1     Running     0          16d
   designate-worker-85596d67b6-7sbgw        1/1     Running     0          14d
   designate-worker-85596d67b6-xkg49        1/1     Running     0          12d
   designate-worker-85596d67b6-5ckje        1/1     Running     0          10d

Procedure

1. Access the remote shell for the OpenStackClient pod from your workstation:

   $ oc rsh -n openstack openstackclient

2. Create the zone that you want users in a particular project to create DNS entries with.

   Example

   In this example, the cloud administrator creates a zone called example.com. and specifies that users in the project ID, f75ec24a-d361-ab86-54c0-dfe6093245a3, have permission to add record sets to the zone:

   $ openstack zone create --email example@example.com example.com. --sudo-project-id f75ec24a-d361-ab86-54c0-dfe6093245a3

   Note

   The DNS domain must always be a fully qualified domain name (FQDN), meaning it will always end with a period.

3. Create the network that you want users in a particular project to create DNS entries with.

   Example

   In this example, the cloud administrator creates a network, example-network, that uses the earlier created zone, example.com., and a segmentation ID, 2017, that is outside of the range defined in ml2_conf.ini:

   $ openstack network create --dns-domain example.com. \
   --provider-segment 2017 --provider-network-type geneve \
   example-network

4. On the network, create a subnet.

   Example

   In this example, the cloud administrator creates a subnet, example-subnet, on the network, example-network:

   $ openstack subnet create \
     --allocation-pool start=192.0.2.10,end=192.0.2.200 \
     --network example-network \
     --subnet-range 192.0.2.0/24 \
     example-subnet

5. Instruct the cloud users in the project to use the zone and network you have created when they add instances, ports, and floating IPs.

   Warning

   If the user creating the instance, port, or floating IP does not have permission to create record sets in the zone, or if the zone does not exist in the DNS service, the Networking service does the following:

   • creates the port with the dns_assignment field populated using the dns_domain provided.
   • does not create a record set in the DNS service.
   • logs the error, "Error publishing port data in external DNS service.".

Procedure

1. Confirm that the system OS_CLOUD variable is set for your cloud:

   $ echo $OS_CLOUD
   my_cloud

   Reset the variable if necessary:

   $ export OS_CLOUD=my_other_cloud

   As an alternative, you can specify the cloud name by adding the --os-cloud <cloud_name> option each time you run an openstack command.

2. Using the network that your cloud administrator has provided, create an instance.

   Example

   In this example, using the network created in the previous section, the cloud user creates an instance named my_vm:

   $ openstack server create --image cirros-0.5.2-x86_64-disk --flavor m1.micro --nic net-id=example-network my_vm

Procedure

1. Confirm that the system OS_CLOUD variable is set for your cloud:

   $ echo $OS_CLOUD
   my_cloud

   Reset the variable if necessary:

   $ export OS_CLOUD=my_other_cloud

   As an alternative, you can specify the cloud name by adding the --os-cloud <cloud_name> option each time you run an openstack command.

2. Using the zone and network that your cloud administrator has provided, create a port.

   Example

   In this example, the cloud user creates a port, my-port, with a DNS name of example-port in the network, example-network:

   $ openstack port create --network example-network \
   --dns-name example-port \
   my-port

Procedure

1. Confirm that the system OS_CLOUD variable is set for your cloud:

   $ echo $OS_CLOUD
   my_cloud

   Reset the variable if necessary:

   $ export OS_CLOUD=my_other_cloud

   As an alternative, you can specify the cloud name by adding the --os-cloud <cloud_name> option each time you run an openstack command.

2. Using the zone and the external network that your cloud administrator has provided, create a floating IP.

   Example

   In this example, the cloud user creates a floating IP with a DNS name, example-fip, in the network, public:

   $ openstack floating ip create --dns-name example-fip \
   --dns-domain example.com. \
   public

Procedure

1. Access the remote shell for the OpenStackClient pod from your workstation:

   $ oc rsh -n openstack openstackclient

2. You create a TLD by running the openstack tld create command.

   Example

   For example, if you want to require that users create zones ending in .com, you can create a single .com TLD:

   $ openstack tld create --name com

   Sample output

Procedure

1. Access the remote shell for the OpenStackClient pod from your workstation:

   $ oc rsh -n openstack openstackclient

2. Use the following command to list all of the TLDs in the DNS service database:

   $ openstack tld list

3. Use the openstack tld show <TLD_NAME_or_ID> command to display the properties for a particular TLD.

   Example

   $ openstack tld show com

Procedure

1. Access the remote shell for the OpenStackClient pod from your workstation:

   $ oc rsh -n openstack openstackclient

2. You can modify a TLD in various ways by using the following command options:

   openstack tld set [--name NAME] \
                     [--description DESCRIPTION | --no-description] \
                     [TLD_ID | TLD_NAME]

   Note

   The earlier syntax diagram does not show the various formatting options for the openstack tld set command. For the list of all the command options, see the link in "Additional resources," later.

   In this example, the openstack tld set command renames the org TLD to example.net:

   Example

   $ openstack tld set org --name example.net

   Sample output

Procedure

1. Access the remote shell for the OpenStackClient pod from your workstation:

   $ oc rsh -n openstack openstackclient

2. Obtain the ID or the name for the TLD that you want to delete, by running the following command:

   $ openstack tld list

3. Using either the name or the ID from the previous step, enter the following command:

   $ openstack tld delete <TLD_NAME_or_ID>

   There is no output when this command is successful.

Procedure

1. Access the remote shell for the OpenStackClient pod from your workstation:

   $ oc rsh -n openstack openstackclient

2. Use the openstack zone blacklist create command to create a denylist.

   In this example, the domain example.com. and all of its subdomains are added to a denylist.

   Example

   $ openstack zone blacklist create --pattern ".*example.com."

   Sample output

   +-------------+--------------------------------------+
   | Field       | Value                                |
   +-------------+--------------------------------------+
   | created_at  | 2021-10-20T16:15:18.000000           |
   | description | None                                 |
   | id          | 7622e241-8c3d-4c03-a692-8747e3cf2658 |
   | pattern     | .*example.com.                       |
   | updated_at  | None                                 |
   +-------------+--------------------------------------+

Procedure

1. Confirm that the system OS_CLOUD variable is set for your cloud:

   $ echo $OS_CLOUD
   my_cloud

   Reset the variable if necessary:

   $ export OS_CLOUD=my_other_cloud

   As an alternative, you can specify the cloud name by adding the --os-cloud <cloud_name> option each time you run an openstack command.

2. Use the following command to list the denylists in the DNS service database:

   $ openstack zone blacklist list

   • With the denylist ID obtained in the previous step, use the openstack zone blacklist show <denylist_ID> command to display properties for a particular denylist.

     Example

     $ openstack zone blacklist show 7622e241-8c3d-4c03-a692-8747e3cf2658

Procedure

1. Access the remote shell for the OpenStackClient pod from your workstation:

   $ oc rsh -n openstack openstackclient

2. Obtain the ID for the denylist that you want to modify, by running the following command:

   $ openstack zone blacklist list

3. You can modify a denylist in various ways by using the following command options:

   $ openstack zone blacklist set \
   [--description DESCRIPTION | --no-description] denylist_ID

   Note

   The earlier syntax diagram does not show the various formatting options for the openstack zone blacklist set command. For the list of all the command options, see the link in "Additional resources," later.

   In this example, the regular expression (regex) is changed to allow the web.example.com domain:

   Example

   $ openstack zone blacklist set 81fbfe02-6bf9-4812-a40e-1522ab6862ca \
   --pattern ".*web.example.com"

   Sample output

   +-------------+--------------------------------------+
   | Field       | Value                                |
   +-------------+--------------------------------------+
   | created_at  | 2022-01-08T09:11:43.000000           |
   | description | None                                 |
   | id          | 81fbfe02-6bf9-4812-a40e-1522ab6862ca |
   | pattern     | .*web.example.com                    |
   | updated_at  | 2022-01-15T14:26:18.000000           |
   +-------------+--------------------------------------+

Procedure

1. Access the remote shell for the OpenStackClient pod from your workstation:

   $ oc rsh -n openstack openstackclient

2. Obtain the ID for the denylist that you want to delete, by running the following command:

   $ openstack zone blacklist list

3. Using the ID from the previous step, enter the following command:

   $ openstack zone blacklist delete <denylist_ID>

   There is no output when this command is successful.

Procedure

1. Confirm that the system OS_CLOUD variable is set for your cloud:

   $ echo $OS_CLOUD
   my_cloud

   Reset the variable if necessary:

   $ export OS_CLOUD=my_other_cloud

   As an alternative, you can specify the cloud name by adding the --os-cloud <cloud_name> option each time you run an openstack command.

2. View the DNS resource quotas set for your project:

   $ openstack dns quota list

   Sample output

   +-------------------+-------+
   | Field             | Value |
   +-------------------+-------+
   | api_export_size   | 1000  |
   | recordset_records | 20    |
   | zone_records      | 500   |
   | zone_recordsets   | 500   |
   | zones             | 10    |
   +-------------------+-------+

3. A RHOSO user with the admin role can query the quotas for other projects:

   1. Obtain the ID for the project whose quotas you want to modify.

      Remember the ID, because you need it for a later step.

      $ openstack project list

   2. Using the project ID, view the DNS resource quotas set for the project.

      Example

      In this example, the DNS quotas for project ID ecd4341280d645e5959d32a4b7659da1 are displayed:

      $ openstack dns quota list --project-id ecd4341280d645e5959d32a4b7659da1

      Sample output

      +-------------------+-------+
      | Field             | Value |
      +-------------------+-------+
      | api_export_size   | 2500  |
      | recordset_records | 25    |
      | zone_records      | 750   |
      | zone_recordsets   | 750   |
      | zones             | 25    |
      +-------------------+-------+

Procedure

1. Access the remote shell for the OpenStackClient pod from your workstation:

   $ oc rsh -n openstack openstackclient

2. Obtain the ID for the project whose quotas you want to modify.

   Remember the ID, because you need it for a later step.

   $ openstack project list

3. Using the project ID, modify a DNS resource quota for a project. For a list of available quotas, see Section 6.4, “DNS service quotas and their default values”.

   Example

   In this example, the zones quota has been modified. The total number of zones that project ID ecd4341280d645e5959d32a4b7659da1 can contain is 30:

   $ openstack dns quota set --project-id ecd4341280d645e5959d32a4b7659da1 --zones 30

   Sample output

   +-------------------+-------+
   | Field             | Value |
   +-------------------+-------+
   | api_export_size   | 1000  |
   | recordset_records | 20    |
   | zone_records      | 500   |
   | zone_recordsets   | 500   |
   | zones             | 30    |
   +-------------------+-------+

Procedure

1. Access the remote shell for the OpenStackClient pod from your workstation:

   $ oc rsh -n openstack openstackclient

2. Obtain the ID for the project whose quotas you want to reset.

   Remember the ID, because you need it for a later step.

   $ openstack project list

3. Using the project ID, reset the DNS resource quotas for a project.

   Example

   In this example, the quotas for a project whose ID is ecd4341280d645e5959d32a4b7659da1 are being reset to the default values:

   $ openstack dns quota reset \
   --project-id ecd4341280d645e5959d32a4b7659da1

   There is no output from a successful openstack dns quota reset command.

Procedure

1. Confirm that the system OS_CLOUD variable is set for your cloud:

   $ echo $OS_CLOUD
   my_cloud

   Reset the variable if necessary:

   $ export OS_CLOUD=my_other_cloud

   As an alternative, you can specify the cloud name by adding the --os-cloud <cloud_name> option each time you run an openstack command.

2. Create a zone by specifying a name for the zone and an email address of the person responsible for the zone.

   Example

   $ openstack zone create --email dnsprimary@example.com example.com.

   When you create a zone, the DNS service automatically creates two record sets: an SOA record and an NS record.

Procedure

1. Confirm that the system OS_CLOUD variable is set for your cloud:

   $ echo $OS_CLOUD
   my_cloud

   Reset the variable if necessary:

   $ export OS_CLOUD=my_other_cloud

   As an alternative, you can specify the cloud name by adding the --os-cloud <cloud_name> option each time you run an openstack command.

2. Modify the zone by specifying the name of the zone and the zone attributes that you want to change:

   --email <email_address>

   a valid email address for the person responsible (owner) for the zone.

   --ttl <seconds>

   (Time To Live) the duration, in seconds, that a DNS client—​for example, a resolver, a browser, an operating system—​can cache a record before checking to see if it has updated.

   --description <string> | --no-description

   a string that describes the purpose of the zone.

   --masters <dns-server> [<dns-server> ...]

   the fully qualified domain name for the DNS server that is the primary instance—​the instance that other DNS servers can sync from to become secondary servers.

   Example

   $ openstack zone set example.com. --ttl 3000

Procedure

1. Confirm that the system OS_CLOUD variable is set for your cloud:

   $ echo $OS_CLOUD
   my_cloud

   Reset the variable if necessary:

   $ export OS_CLOUD=my_other_cloud

   As an alternative, you can specify the cloud name by adding the --os-cloud <cloud_name> option each time you run an openstack command.

2. Delete the zone.

   Example

   $ openstack zone delete example.com.

Procedure

1. Confirm that the system OS_CLOUD variable is set for your cloud:

   $ echo $OS_CLOUD
   my_cloud

   Reset the variable if necessary:

   $ export OS_CLOUD=my_other_cloud

   As an alternative, you can specify the cloud name by adding the --os-cloud <cloud_name> option each time you run an openstack command.

2. Export the zone.

   Example

   $ openstack zone export create example.com.

   Sample output

   +------------+--------------------------------------+
   | Field      | Value                                |
   +------------+--------------------------------------+
   | created_at | 2022-02-11T02:01:30.000000           |
   | id         | e75aef2c-b562-4cd9-a426-4a73f6cb82be |
   | location   | None                                 |
   | message    | None                                 |
   | project_id | cf5a8f5cc5834d2dacd1d54cd0a354b7     |
   | status     | PENDING                              |
   | updated_at | None                                 |
   | version    | 1                                    |
   | zone_id    | d8f81db6-937b-4388-bfb3-ba620e6c09fb |
   +------------+--------------------------------------+

   Important

   After you create a zone export resource, the DNS service continues to update the resource with any later changes that are made to the zone.

3. Record the zone export ID (e75aef2c-b562-4cd9-a426-4a73f6cb82be), because you must use it to verify your zone export, and to access the zone export data.

Verification

1. Confirm that the DNS service successfully created a zone export resource.

   Example

   $ openstack zone export show e75aef2c-b562-4cd9-a426-4a73f6cb82be

   Sample output

   +------------+--------------------------------------------------------------------------------+
   | Field      | Value                                                                          |
   +------------+--------------------------------------------------------------------------------+
   | created_at | 2022-02-11T02:01:30.000000                                                     |
   | id         | e75aef2c-b562-4cd9-a426-4a73f6cb82be                                           |
   | location   | designate://v2/zones/tasks/exports/e75aef2c-b562-4cd9-a426-4a73f6cb82be/export |
   | message    | None                                                                           |
   | project_id | cf5a8f5cc5834d2dacd1d54cd0a354b7                                               |
   | status     | COMPLETE                                                                       |
   | updated_at | 2022-02-11T02:01:30.000000                                                     |
   | version    | 2                                                                              |
   | zone_id    | d8f81db6-937b-4388-bfb3-ba620e6c09fb                                           |
   +------------+--------------------------------------------------------------------------------+

   The zone export create command creates a resource that the DNS service stores internally by default.

2. Access the contents of the zone export file, by using the zone export ID that you obtained earlier.

   Tip

   Using the -f value option prints the contents of the zone file without any tabulation. You can also redirect the contents to a local text file, which can be useful if you want to modify the exported zone file locally and then import it back into the DNS service to update the zone.

   Example

   $ openstack zone export showfile e75aef2c-b562-4cd9-a426-4a73f6cb82be -f value

   Sample output

   $ORIGIN example.com.
   $TTL 3600
   
   example.com.  IN NS ns1.example.com.
   example.com.  IN SOA ns1.example.com. admin.example.com. 1624414033 3583 600 86400 3600
   
   www.example.com.  IN A 192.0.2.2
   www.example.com.  IN A 192.0.2.1

Procedure

1. Confirm that the system OS_CLOUD variable is set for your cloud:

   $ echo $OS_CLOUD
   my_cloud

   Reset the variable if necessary:

   $ export OS_CLOUD=my_other_cloud

   As an alternative, you can specify the cloud name by adding the --os-cloud <cloud_name> option each time you run an openstack command.

2. List the zones on your system:

   $ openstack zone list

3. If a the zone that you want to import already exists, you must delete it first by running the openstack zone delete command.

   Example

   $ openstack zone delete example.com.

4. Confirm that your zone no longer exists by listing the zones on your system:

   $ openstack zone list

5. Confirm that the zone data you are planning to import contains a zone TTL value.

   Example

   $ cat /home/stack/zone_file

   Sample output

   $ORIGIN example.com.
   $TTL 3000
   
   example.com.  IN NS test.example.com.
   example.com.  IN SOA test.example.com. admin.example.com. 1624415706 9000 500 86000 5000
   www.example.com.  IN A 192.0.2.2
   test.example.com.  IN NS test.example.com.

6. Import a valid zone data file.

   Example

   $ openstack zone import create /home/stack/zone_file

Procedure

1. Confirm that the system OS_CLOUD variable is set for your cloud:

   $ echo $OS_CLOUD
   my_cloud

   Reset the variable if necessary:

   $ export OS_CLOUD=my_other_cloud

   As an alternative, you can specify the cloud name by adding the --os-cloud <cloud_name> option each time you run an openstack command.

2. Obtain the ID for the project to which you want to transfer ownership of the zone.

   Example

   $ openstack project list

   Sample output

   +----------------------------------+---------+
   | ID                               | Name    |
   +----------------------------------+---------+
   | 7af0acba0486472da2447ff55df4a26d | Finance |
   | 1d12e87fad0d437286c2873b36a12316 | Sales   |
   +----------------------------------+---------+

3. Using the project ID obtained in the previous step, create a zone transfer request for the zone that you want to transfer.

   Note

   When using a target project ID, no other project can accept the zone transfer. If you do not provide a target project ID, then any project that has the transfer request ID and its key can receive the zone transfer.

   Example

   To transfer the zone wow.example.com. to project 1d12e87fad0d437286c2873b36a12316, you run:

   $ openstack zone transfer request create \
   --target-project-id 1d12e87fad0d437286c2873b36a12316 wow.example.com.

   Sample output

   +-------------------+-----------------------------------------------------+
   | Field             | Value                                               |
   +-------------------+-----------------------------------------------------+
   | created_at        | 2022-05-26T22:06:39.000000                          |
   | description       | None                                                |
   | id                | 63cab5e5-65fa-4480-b26c-c16c267c44b2                |
   | key               | BIFJIQWH                                            |
   | links             | {'self': 'http://127.0.0.1:60053/v2/zones/tasks/tra |
   |                   | nsfer_requests/63cab5e5-65fa-4480-b26c-c16c267c44b2 |
   |                   | '}                                                  |
   | project_id        | 6265985fc493465db6a978b318a01996                    |
   | status            | ACTIVE                                              |
   | target_project_id | 1d12e87fad0d437286c2873b36a12316                    |
   | updated_at        | None                                                |
   | zone_id           | 962f08b4-b671-4096-bf24-8908c9d4af0c                |
   | zone_name         | wow.example.com.                                    |
   +-------------------+-----------------------------------------------------+

4. Obtain the zone transfer request ID and its key.

   Example

   $ openstack zone transfer request list -c id -c zone_name -c key

   Sample output

   +--------------------------------------+------------------+----------+
   | id                                   | zone_name        | key      |
   +--------------------------------------+------------------+----------+
   | 63cab5e5-65fa-4480-b26c-c16c267c44b2 | wow.example.com. | BIFJIQWH |
   +--------------------------------------+------------------+----------+

5. Provide the zone transfer request ID and its key to a member of the receiving project.

6. A member of the receiving project logs in to the receiving project, and sources his or her credentials file.

   Example

   $ source ~/overcloudrc

7. Using the zone transfer request ID and its key, accept the zone transfer.

   Example

   $ openstack zone transfer accept request \
   --transfer-id 63cab5e5-65fa-4480-b26c-c16c267c44b2 --key BIFJIQWH

   Sample output

   +--------------------------+----------------------------------------------+
   | Field                    | Value                                        |
   +--------------------------+----------------------------------------------+
   | created_at               | 2022-05-27T21:37:43.000000                   |
   | id                       | a4c4f872-c98c-411b-a787-58ed0e2dce11         |
   | key                      | BIFJIQWH                                     |
   | links                    | {'self': 'http://127.0.0.1:60053/v2/zones/ta |
   |                          | sks/transfer_accepts/a4c4f872-c98c-411b-a787 |
   |                          | -58ed0e2dce11', 'zone': 'http://127.0.0.1:60 |
   |                          | 053/v2/zones/962f08b4-b671-4096-bf24-8908c9d |
   |                          | 4af0c'}                                      |
   | project_id               | 1d12e87fad0d437286c2873b36a12316             |
   | status                   | COMPLETE                                     |
   | updated_at               | 2022-05-27T21:37:43.000000                   |
   | zone_id                  | 962f08b4-b671-4096-bf24-8908c9d4af0c         |
   | zone_transfer_request_id | 63cab5e5-65fa-4480-b26c-c16c267c44b2         |
   +--------------------------+----------------------------------------------+

Procedure

1. Confirm that the system OS_CLOUD variable is set for your cloud:

   $ echo $OS_CLOUD
   my_cloud

   Reset the variable if necessary:

   $ export OS_CLOUD=my_other_cloud

   As an alternative, you can specify the cloud name by adding the --os-cloud <cloud_name> option each time you run an openstack command.

2. Obtain the ID for the zone transfer request you are modifying.

   Example

   $ openstack zone transfer request list -c id -c zone_name

   Sample output

   +--------------------------------------+------------------+
   | id                                   | zone_name        |
   +--------------------------------------+------------------+
   | 63cab5e5-65fa-4480-b26c-c16c267c44b2 | wow.example.com. |
   +--------------------------------------+------------------+

3. Using the zone transfer request ID obtained in the previous step, you can update a limited set of fields on zone transfer requests, such as the description and target project ID.

   Example

   $ openstack zone transfer request set --description "wow zone transfer" \
   63cab5e5-65fa-4480-b26c-c16c267c44b2

   Sample output

   +-------------------+-----------------------------------------------------+
   | Field             | Value                                               |
   +-------------------+-----------------------------------------------------+
   | created_at        | 2022-05-26T22:06:39.000000                          |
   | description       | wow zone transfer                                   |
   | id                | 63cab5e5-65fa-4480-b26c-c16c267c44b2                |
   | key               | BIFJIQWH                                            |
   | links             | {'self': 'http://127.0.0.1:60053/v2/zones/tasks/tra |
   |                   | nsfer_requests/63cab5e5-65fa-4480-b26c-c16c267c44b2 |
   |                   | '}                                                  |
   | project_id        | 6265985fc493465db6a978b318a01996                    |
   | status            | ACTIVE                                              |
   | target_project_id | 1d12e87fad0d437286c2873b36a12316                    |
   | updated_at        | 2022-05-27T20:52:08.000000                          |
   | zone_id           | 962f08b4-b671-4096-bf24-8908c9d4af0c                |
   | zone_name         | wow.example.com.                                    |
   +-------------------+-----------------------------------------------------+

4. Using the zone transfer request ID obtained in step 2, you can cancel a pending zone transfer, by deleting its zone transfer request.

   Example

   $ openstack zone transfer request delete 63cab5e5-65fa-4480-b26c-c16c267c44b2

   There is no output from the zone transfer request delete command. Confirm that the zone transfer request is removed by running the zone transfer request list command.

Procedure

1. Confirm that the system OS_CLOUD variable is set for your cloud:

   $ echo $OS_CLOUD
   my_cloud

   Reset the variable if necessary:

   $ export OS_CLOUD=my_other_cloud

   As an alternative, you can specify the cloud name by adding the --os-cloud <cloud_name> option each time you run an openstack command.

2. You create record sets by using the openstack recordset create command. Record sets require a zone, name, type, and data.

   Example

   $ openstack recordset create --type A --record 192.0.2.1 example.com. www

   Note

   The trailing dot (.) is required when using fully qualified domain names (FQDN). If you omit the trailing dot, the zone name is duplicated in the resulting record name, for example www.example.com.example.com..

   In the earlier example, a user has created a zone named example.com.. Because the record set name www is not an FQDN, the DNS service prepends it to the zone name. You can achieve the same result by using the FQDN for the record set name argument:

   $ openstack recordset create --type A --record 192.0.2.1 example.com. \
   www.example.com.

3. If you want to construct a TXT record set that exceeds the maximum length for a character string (255 characters), then you must split the string into multiple, smaller strings when you create the record set.

   In this example, a user creates a TXT record set (_domainkey.example.com) that contains one string of 410 characters by specifying two strings—​each less than the 255 character maximum:

   $ openstack recordset create --type TXT --record '"210 characters string" \
   "200 characters string"' example.com. _domainkey

4. You can supply the --record argument multiple times to create multiple records within a record set. A typical use for multiple --record arguments is round-robin DNS.

   Example

   $ openstack recordset create --type A --record 192.0.2.1 --record 192.0.2.2 \
   example.com. web

Procedure

1. Confirm that the system OS_CLOUD variable is set for your cloud:

   $ echo $OS_CLOUD
   my_cloud

   Reset the variable if necessary:

   $ export OS_CLOUD=my_other_cloud

   As an alternative, you can specify the cloud name by adding the --os-cloud <cloud_name> option each time you run an openstack command.

2. You modify record sets by using the openstack recordset set command.

   Example

   In this example, a user is updating the record set web.example.com. to contain two records:

   $ openstack recordset set example.com. web.example.com. --record 192.0.2.5 --record 192.0.2.6

   Note

   When updating a record set you can identify it by its ID or its name. If you use its name, you must use the fully qualified domain name (FQDN).

Procedure

1. Confirm that the system OS_CLOUD variable is set for your cloud:

   $ echo $OS_CLOUD
   my_cloud

   Reset the variable if necessary:

   $ export OS_CLOUD=my_other_cloud

   As an alternative, you can specify the cloud name by adding the --os-cloud <cloud_name> option each time you run an openstack command.

2. You delete record sets by using the openstack recordset delete command.

   Example

   In this example, a user is deleting the record set web.example.com. from the example.com. zone:

   $ openstack recordset delete example.com. web.example.com.

Procedure

1. Confirm that the system OS_CLOUD variable is set for your cloud:

   $ echo $OS_CLOUD
   my_cloud

   Reset the variable if necessary:

   $ export OS_CLOUD=my_other_cloud

   As an alternative, you can specify the cloud name by adding the --os-cloud <cloud_name> option each time you run an openstack command.

2. Create a reverse lookup zone by using the openstack zone create command and specifying these required arguments:

   --email <email_address>

   a valid email address for the person responsible (owner) for the zone.

   <name>

   a name for the reverse lookup zone that conforms to the convention: <backward_IP_address>.in-addr.arpa for IPv4 addresses, and <backward_IP_address>.ip6.arpa for IPv6 addresses.

   Example

   In this example, the reverse lookup zone is designed for one PTR record, for the 198.51.100.42 address:

   $ openstack zone create --email admin@example.com \
     42.100.51.198.in-addr.arpa.

   Sample output

   +----------------+------------------------------------------+
   | Field          | Value                                    |
   +----------------+------------------------------------------+
   | action         | CREATE                                   |
   | attributes     |                                          |
   | created_at     | 2022-02-02T17:32:47.000000               |
   | description    | None                                     |
   | email          | admin@example.com                        |
   | id             | f5546034-b27e-4326-bf9d-c53ed879f7fa     |
   | masters        |                                          |
   | name           | 42.100.51.198.in-addr.arpa.              |
   | pool_id        | 794ccc2c-d751-44fe-b57f-8894c9f5c842     |
   | project_id     | 123d51544df443e790b8e95cce52c285         |
   | serial         | 1591119166                               |
   | status         | PENDING                                  |
   | transferred_at | None                                     |
   | ttl            | 3600                                     |
   | type           | PRIMARY                                  |
   | updated_at     | None                                     |
   | version        | 1                                        |
   +----------------+------------------------------------------+

   Example

   In another example for a reverse zone that is for a 198.51.100.0/24 subnet, you would create the zone:

   $ openstack zone create --email admin@example.com \
     100.51.198.in-addr.arpa.

   Sample output

   +----------------+------------------------------------------+
   | Field          | Value                                    |
   +----------------+------------------------------------------+
   | action         | CREATE                                   |
   | attributes     |                                          |
   | created_at     | 2022-02-02T17:40:23.000000               |
   | description    | None                                     |
   | email          | admin@example.com                        |
   | id             | 5669caad86a04256994cdf755df4d3c1         |
   | masters        |                                          |
   | name           | 100.51.198.in-addr.arpa.                 |
   | pool_id        | 794ccc2c-d751-44fe-b57f-8894c9f5c842     |
   | project_id     | 123d51544df443e790b8e95cce52c285         |
   | serial         | 1739276248                               |
   | status         | PENDING                                  |
   | transferred_at | None                                     |
   | ttl            | 3600                                     |
   | type           | PRIMARY                                  |
   | updated_at     | None                                     |
   | version        | 1                                        |
   +----------------+------------------------------------------+

Verification

1. Confirm that the reverse lookup zone that you created exists:

   $ openstack zone list -c id -c name -c status

   Sample output

   +--------------------------------------+-----------------------------+--------+
   | id                                   | name                        | status |
   +--------------------------------------+-----------------------------+--------+
   | f5546034-b27e-4326-bf9d-c53ed879f7fa | 42.100.51.198.in-addr.arpa. | ACTIVE |
   +--------------------------------------+-----------------------------+--------+

2. For the address-to-name mapping to be complete, the forward zone—​the zone that contains the IP address—​must exist. If the forward zone does not exist, create that now.

Procedure

1. Confirm that the system OS_CLOUD variable is set for your cloud:

   $ echo $OS_CLOUD
   my_cloud

   Reset the variable if necessary:

   $ export OS_CLOUD=my_other_cloud

   As an alternative, you can specify the cloud name by adding the --os-cloud <cloud_name> option each time you run an openstack command.

2. Create a PTR record by using the openstack recordset create command and specifying these required arguments:

   --record <domain_name>

   the target, the domain name, that should be returned when a reverse lookup is performed.

   --type PTR

   the kind of record, PTR, that you are creating.

   <zone_name>

   the name of the zone, the reverse lookup zone, where the record resides.

   <record_name>

   the name of the PTR record.

   The record name must match the <zone_name> or be a member of the zone. For example, for the reverse lookup zone 100.51.198.in-addr.arpa., these are valid PTR record names: 1.100.51.198.in-addr.arpa., 2.100.51.198.in-addr.arpa., and any other reversed IP addresses in the 198.51.100.0/24 subnet.

   Example

   openstack recordset create --record www.example.com. --type PTR \
   42.100.51.198.in-addr.arpa. 42.100.51.198.in-addr.arpa.

   Sample output

   +-------------+--------------------------------------+
   | Field       | Value                                |
   +-------------+--------------------------------------+
   | action      | CREATE                               |
   | created_at  | 2022-02-02T19:55:50.000000           |
   | description | None                                 |
   | id          | ca604f72-83e6-421f-bf1c-bb4dc1df994a |
   | name        | 42.100.51.198.in-addr.arpa.          |
   | project_id  | 123d51544df443e790b8e95cce52c285     |
   | records     | www.example.com.                     |
   | status      | PENDING                              |
   | ttl         | 3600                                 |
   | type        | PTR                                  |
   | updated_at  | None                                 |
   | version     | 1                                    |
   | zone_id     | f5546034-b27e-4326-bf9d-c53ed879f7fa |
   | zone_name   | 42.100.51.198.in-addr.arpa.          |
   +-------------+--------------------------------------+

Procedure

1. Confirm that the system OS_CLOUD variable is set for your cloud:

   $ echo $OS_CLOUD
   my_cloud

   Reset the variable if necessary:

   $ export OS_CLOUD=my_other_cloud

   As an alternative, you can specify the cloud name by adding the --os-cloud <cloud_name> option each time you run an openstack command.

2. Create the PTR record by using the openstack recordset create command and specifying these required arguments:

   --record <domain_name>

   the domain name of the lookup.

   --type PTR

   the kind of record, PTR, that you are creating.

   <zone_name>

   the name of the reverse lookup zone where the record resides.

   <record_name>

   the name of the PTR record.

   The record name must match the <zone_name> or be a member of the zone. For example, for the reverse lookup zone 100.51.198.in-addr.arpa., these are valid PTR record names: 1.100.51.198.in-addr.arpa., 2.100.51.198.in-addr.arpa., and any other reversed IP addresses in the 198.51.100.0/24 subnet.

   Example

   In this example, the reverse lookup zone is more broadly defined, For example, a 100.51.198.0/24 reverse lookup zone, 100.51.198.in-addr-arpa:

   $ openstack recordset create --record cats.example.com. --type PTR \
   --ttl 3600 100.51.198.in-addr.arpa. 3.100.51.198.in-addr.arpa.

   Sample output

   +-------------+--------------------------------------+
   | Field       | Value                                |
   +-------------+--------------------------------------+
   | action      | CREATE                               |
   | created_at  | 2022-02-02T20:10:54.000000           |
   | description | None                                 |
   | id          | c843729b-7aaf-4f99-a40a-d9bf70edf271 |
   | name        | 3.100.51.198.in-addr.arpa.           |
   | project_id  | 123d51544df443e790b8e95cce52c285     |
   | records     | cats.example.com.                    |
   | status      | PENDING                              |
   | ttl         | 3600                                 |
   | type        | PTR                                  |
   | updated_at  | None                                 |
   | version     | 1                                    |
   | zone_id     | e9fd0ced-1d3e-43fa-b9aa-6d4b7a73988d |
   | zone_name   | 100.51.198.in-addr.arpa.             |
   +-------------+--------------------------------------+

Verification

1. Perform a reverse lookup to confirm that the IP address (198.51.100.3) is mapped to the domain name (cats.example.com).

   Example

   In this example, 203.0.113.5 is one of the DNS servers in the deployment:

   $ dig @203.0.113.5 -x 198.51.100.3 +short

   Sample output

   cats.example.com.

2. Perform a reverse lookup to confirm that any other IP address (198.51.100.0/24) is mapped to the domain name (example.com).

   Example

   In this example, 203.0.113.5 is one of the DNS servers in the deployment:

   $ dig @203.0.113.5 -x 198.51.100.10 +short

   Sample output

   example.com.

Procedure

1. Confirm that the system OS_CLOUD variable is set for your cloud:

   $ echo $OS_CLOUD
   my_cloud

   Reset the variable if necessary:

   $ export OS_CLOUD=my_other_cloud

   As an alternative, you can specify the cloud name by adding the --os-cloud <cloud_name> option each time you run an openstack command.

2. Determine the ID of the floating IP address for which you want to delete a PTR record. You need this information in a later step.

   $ openstack floating ip list -c ID -c "Floating IP Address"

   Sample output

   +--------------------------------------+---------------------+
   | ID                                   | Floating IP Address |
   +--------------------------------------+---------------------+
   | 5c02c519-4928-4a38-bd10-c748c200912f | 192.0.2.11          |
   | 89532684-13e1-4af3-bd79-f434c9920cc3 | 192.0.2.12          |
   | ea3ebc6d-a146-47cd-aaa8-35f06e1e8c3d | 192.0.2.13          |
   +--------------------------------------+---------------------+

3. Determine the RHOSO region name of the neutron instance that hosts the floating IP. You need this information in a later step.

   $ openstack endpoint list -c ID -c Region -c "Service Name"

   Sample output

   +----------------------------------+-----------+--------------+
   | ID                               | Region    | Service Name |
   +----------------------------------+-----------+--------------+
   | 16526452effd467a915155ceccf79dae | RegionOne | placement    |
   | 21bf826a62a14456a61bd8f39648e849 | RegionOne | keystone     |
   | 9cb1956999c54001a39d11ea14e037a1 | RegionOne | nova         |
   | bdeec4e2665d4605bb89e16a8b1bc50d | RegionOne | glance       |
   | ced05a1c03ab44caa1a351ace95429e6 | RegionOne | neutron      |
   | e79e3113ea544d039b3a6378e60bdf3f | RegionOne | nova         |
   | f91ee44123954b6c82162dcd2d4fc965 | RegionOne | designate    |
   +----------------------------------+-----------+--------------+

4. Create the PTR record by using the openstack ptr record set command and specifying these required arguments:

   <floating_IP_ID>

   the floating IP ID in the format: <region_name>:<floating_IP_ID>.

   <ptrd_name>

   the target, the domain name, that should be returned when a reverse lookup is performed.

   Example

   $ openstack ptr record set RegionOne:5c02c519-4928-4a38-bd10-c748c200912f ftp.example.com.

   Sample output

   +-------------+------------------------------------------------+
   | Field       | Value                                          |
   +-------------+------------------------------------------------+
   | action      | CREATE                                         |
   | address     | 192.0.2.11                                     |
   | description | None                                           |
   | id          | RegionOne:5c02c519-4928-4a38-bd10-c748c200912f |
   | ptrdname    | ftp.example.com.                               |
   | status      | PENDING                                        |
   | ttl         | 3600                                           |
   +-------------+------------------------------------------------+

Procedure

1. Confirm that the system OS_CLOUD variable is set for your cloud:

   $ echo $OS_CLOUD
   my_cloud

   Reset the variable if necessary:

   $ export OS_CLOUD=my_other_cloud

   As an alternative, you can specify the cloud name by adding the --os-cloud <cloud_name> option each time you run an openstack command.

2. Determine the ID of the floating IP address for which you want to delete a PTR record. You need this information in a later step.

   $ openstack floating ip list -c ID -c "Floating IP Address"

   Sample output

   +--------------------------------------+---------------------+
   | ID                                   | Floating IP Address |
   +--------------------------------------+---------------------+
   | 5c02c519-4928-4a38-bd10-c748c200912f | 192.0.2.11          |
   | 89532684-13e1-4af3-bd79-f434c9920cc3 | 192.0.2.12          |
   | ea3ebc6d-a146-47cd-aaa8-35f06e1e8c3d | 192.0.2.13          |
   +--------------------------------------+---------------------+

3. Determine the name of your RHOSO region. You need this information in a later step.

   $ openstack endpoint list -c ID -c Region -c "Service Name"

   Sample output

   +----------------------------------+-----------+--------------+
   | ID                               | Region    | Service Name |
   +----------------------------------+-----------+--------------+
   | 16526452effd467a915155ceccf79dae | RegionOne | placement    |
   | 21bf826a62a14456a61bd8f39648e849 | RegionOne | keystone     |
   | 9cb1956999c54001a39d11ea14e037a1 | RegionOne | nova         |
   | bdeec4e2665d4605bb89e16a8b1bc50d | RegionOne | glance       |
   | ced05a1c03ab44caa1a351ace95429e6 | RegionOne | neutron      |
   | e79e3113ea544d039b3a6378e60bdf3f | RegionOne | nova         |
   | f91ee44123954b6c82162dcd2d4fc965 | RegionOne | designate    |
   +----------------------------------+-----------+--------------+

4. Delete the PTR record by using the openstack ptr record unset command and specifying these required arguments:

   <floating_IP_ID>

   the floating IP ID in the format: <region>:<floating_IP_ID>.

   Example

   $ openstack ptr record unset RegionOne:5c02c519-4928-4a38-bd10-c748c200912f

Procedure

1. Confirm that the system OS_CLOUD variable is set for your cloud:

   $ echo $OS_CLOUD
   my_cloud

   Reset the variable if necessary:

   $ export OS_CLOUD=my_other_cloud

   As an alternative, you can specify the cloud name by adding the --os-cloud <cloud_name> option each time you run an openstack command.

2. List the RHOSO service endpoints:

   $ openstack endpoint list -c "Service Name" -c Enabled -c URL

   Sample output

   +--------------+---------+-------------------------------------------------+
   | Service Name | Enabled | URL                                             |
   +--------------+---------+-------------------------------------------------+
   | swift        | True    | http://198.51.100.61:8080                       |
   | designate    | True    | http://203.0.113.103:9001                       |
   | heat-cfn     | True    | http://192.0.2.137:8000/v1                      |
   | designate    | True    | http://192.0.2.137:9001                         |
   | placement    | True    | http://203.0.113.103:8778/placement             |
   | cinderv3     | True    | http://203.0.113.103:8776/v3/%(tenant_id)s      |
   | heat         | True    | http://203.0.113.103:8004/v1/%(tenant_id)s      |
   | heat-cfn     | True    | http://203.0.113.103:8000/v1                    |
   | nova         | True    | http://203.0.113.103:8774/v2.1                  |
   | heat         | True    | http://192.0.2.137:8004/v1/%(tenant_id)s        |
   | glance       | True    | http://203.0.113.103:9292                       |
   | heat         | True    | http://203.0.113.103:8004/v1/%(tenant_id)s      |
   | glance       | True    | http://203.0.113.103:9292                       |
   | neutron      | True    | http://203.0.113.103:9696                       |
   | nova         | True    | http://192.0.2.137:8774/v2.1                    |
   | cinderv3     | True    | http://192.0.2.137:8776/v3/%(tenant_id)s        |
   | placement    | True    | http://203.0.113.103:8778/placement             |
   | keystone     | True    | http://192.168.24.17:35357                      |
   | neutron      | True    | http://192.0.2.137:9696                         |
   | nova         | True    | http://203.0.113.103:8774/v2.1                  |
   | heat-cfn     | True    | http://203.0.113.103:8000/v1                    |
   | cinderv3     | True    | http://203.0.113.103:8776/v3/%(tenant_id)s      |
   | glance       | True    | http://192.0.2.137:9292                         |
   | placement    | True    | http://192.0.2.137:8778/placement               |
   | swift        | True    | http://198.51.100.61:8080/v1/AUTH_%(tenant_id)s |
   | swift        | True    | http://192.0.2.137:8080/v1/AUTH_%(tenant_id)s   |
   | designate    | True    | http://203.0.113.103:9001                       |
   | keystone     | True    | http://192.0.2.137:5000                         |
   | neutron      | True    | http://203.0.113.103:9696                       |
   | keystone     | True    | http://203.0.113.103:5000                       |
   +--------------+---------+-------------------------------------------------+