Description of problem:
When you specify a custom domain name using the CloudDomain parameter, the overcloud nodes are deployed with a hostname that includes ".localdomain" and not the custom one specified.
Version-Release number of selected component (if applicable):
Create a .yaml environment file containing:
Deploy the overcloud via "openstack overcloud deploy -e <environment_file>".
After deployment completes, ssh in to an overcloud node and "hostname"
Note that the hostname specifies a domain name of ".localdomain".
Steps to Reproduce:
1. See above.
The hostname is set to <name>.localdomain
The hostname should include the domain name specified in the CloudDomain parameter.
Executing "hostname --fqdn" on an overcloud node results in an error:
[heat-admin@r13-controller-0 ~]$ hostname
[heat-admin@r13-controller-0 ~]$ hostname --fqdn
hostname: Name or service not known
Note that the entries in /etc/hosts are correct and do include the custom domain name.
I can also reproduce this.
In two separate configurations I added the CloudDomain and deployed withe release OSP8 bits. I see the entries in /etc/host have the specified domain, but hostname returns with .localdomain and this is also seen in /etc/hostname.
I know Steve hardy said he saw the hostname return the right value for him, but wonder if that only working in a simple deployment. My understand is both Chris and I are using network isolation.
If you set dhcp_domain in nova.conf on the undercloud node to the custom domain name in addition to setting the CloudDomain parameter in an environment file, then the hostname is set correctly, /etc/hostname is set up correctly, and hostname --fqdn works as it should.
(In reply to Chris Dearborn from comment #4)
> See https://bugzilla.redhat.com/show_bug.cgi?id=1336952
Have we ended up with a duplicate, should this bz be closed then we can track fixing the issue via https://bugzilla.redhat.com/show_bug.cgi?id=1336952 (that one contains my debug analysis and links to the upstream bug).
Well, they look like 2 separate bugs to me, which is why I wrote 2 BZs. Don't really care if we glom these into one BZ as long as both bugs are fixed.
do we need an analog BZ for Mitaka/OSP9 and Newton/OSP10?
We have a workaround for this implemented in our solution. When the fix comes in we can remove the workaround. I think we only care about the fix in OSP10 and beyond, so there's no need for multiple bugs. Perhaps this should be retargeted to OSP10.
Upstream patch is merged in stable/Ocata. Need this backported to OSP 10.
Backport here: https://review.openstack.org/#/c/517446/