Bug 1779277

Summary: FQDN lookup when scaling down is too strict
Product: Red Hat OpenStack Reporter: Kevin Carter <kecarter>
Component: openstack-tripleo-commonAssignee: Kevin Carter <kecarter>
Status: CLOSED ERRATA QA Contact: Alexander Chuzhoy <sasha>
Severity: medium Docs Contact:
Priority: medium    
Version: 16.0 (Train)CC: mburns, slinaber
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: openstack-tripleo-common-11.3.2-0.20191127200419.5c82293.el8ost Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-02-06 14:43:39 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 Kevin Carter 2019-12-03 16:20:54 UTC 
Description of problem:

When running a scale down operation the FQDN lookup for service agent names can be too strict. While agent names are generally assumed to be the FQDN of the host, and that the deployment engines [heat, mistral, ansible, puppet] will provide identical information as what is defined when the service was registered, this input could have an incorrect name, short or otherwise, due to a mirriod of unforeseen issues:

1. overridden in config
2. set in inventory
3. bad configuration on the host
4. bad facts
etc...

To make our process more resilient we changed the hostname lookup to use a fuzzy search. This fuzzy search will use the provided server name as an anchor and match against the available names. If a duplicate name is discovered (like in the instance where two hosts have the same FQDN or there is an improper setting in config), an error will be raised explaining the issue so that operators has the ability to confidently resolve the problem.

Upstream change: https://review.opendev.org/695998
Comment 7 errata-xmlrpc 2020-02-06 14:43:39 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/RHEA-2020:0283