Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1792422

Summary: RabbitMQ is using the Public API DNS short name to bind to instead of the Local IP DNS short name
Product: Red Hat OpenStack Reporter: Darin Sorrentino <dsorrent>
Component: tripleo-ansibleAssignee: Luke Short <lshort>
Status: CLOSED ERRATA QA Contact: Sasha Smolyak <ssmolyak>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 16.0 (Train)CC: emacchi, jhajyahy, kholden, kmehta, lshort, mburns, sputhenp
Target Milestone: betaKeywords: Triaged
Target Release: 16.1 (Train on RHEL 8.2)   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: tripleo-ansible-0.4.2-0.20200326125313.9d5ef54.el8ost Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-07-29 07:50:33 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Darin Sorrentino 2020-01-17 16:08:37 UTC
Description of problem:

According to the documentation, we are supposed to update the /etc/hosts file with the FQDN and Short Name of the Director host and configure it to point to the Public API IP address (undercloud_public_host):

https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.0-beta/html/director_installation_and_usage/preparing-for-director-installation#preparing-the-undercloud

3.1, Step 8.

My /etc/hosts prior to deployment:

[stack@director16 ~]$ cat/etc/hosts
172.16.220.25 director16.homelab.net director16
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
[stack@director16 ~]$

Here's the undercloud.conf file used for deployment:

[stack@director16 ~]$ egrep -v '(^$|^#)' undercloud.conf 
[DEFAULT]
certificate_generation_ca = local
container_images_file = /home/stack/templates/containers-prepare-parameter.yaml
enabled_hardware_types = ipmi,redfish,ilo,idrac,staging-ovirt
generate_service_certificate = true
local_interface = ens7
local_ip = 192.168.200.5/24
local_mtu = 1500
overcloud_domain_name = homelab.net
undercloud_admin_host = 192.168.200.6
undercloud_debug = false
undercloud_hostname = director16.homelab.net
undercloud_nameservers = 172.16.225.254
undercloud_public_host = 172.16.220.25
[ctlplane-subnet]
cidr = 192.168.200.0/24
dhcp_end = 192.168.200.200
dhcp_start = 192.168.200.100
gateway = 192.168.200.5
inspection_iprange = 192.168.200.20,192.168.200.99
masquerade = true
[stack@director16 ~]$ 

During deployment, the /etc/hosts file is updated as such:

[stack@director16 ~]$ cat/etc/hosts
172.16.220.25 director16.homelab.net director16
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
# BEGIN ANSIBLE MANAGED BLOCK




192.168.200.5 director16.homelab.net director16
192.168.200.5 director16.external.homelab.net director16.external
192.168.200.5 director16.ctlplane.homelab.net director16.ctlplane


# END ANSIBLE MANAGED BLOCK
[stack@director16 ~]$

This is causing rabbitmq container startup to fail when it attempts to resolves the listen host/port:

+ echo 'Running command: '\''/usr/lib/rabbitmq/bin/rabbitmq-server'\'''
Running command: '/usr/lib/rabbitmq/bin/rabbitmq-server'
+ exec /usr/lib/rabbitmq/bin/rabbitmq-server
ERROR: epmd error for host director16: address (cannot connect to host/port)
+ sudo -E kolla_set_configs

If the documentation is correct, RabbitMQ should be using the "director16.ctlplane" to bind to instead of "director16". I think this is the actual issue as Rabbit shouldn't be exposed to the Public API.

I removed the line for the Public API (undercloud_public_host) entry that I configured prior to deployment and re-ran the Director install and it completed successfully which leads me to believe that is the case.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Luke Short 2020-02-18 15:55:49 UTC
*** Bug 1801686 has been marked as a duplicate of this bug. ***

Comment 8 Alex McLeod 2020-06-16 12:28:51 UTC
If this bug requires doc text for errata release, please set the 'Doc Type' and provide draft text according to the template in the 'Doc Text' field. The documentation team will review, edit, and approve the text.

If this bug does not require doc text, please set the 'requires_doc_text' flag to '-'.

Comment 10 errata-xmlrpc 2020-07-29 07:50:33 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:3148