Bug 1779277 - FQDN lookup when scaling down is too strict
Summary: FQDN lookup when scaling down is too strict
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo-common
Version: 16.0 (Train)
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Kevin Carter
QA Contact: Alexander Chuzhoy
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-12-03 16:20 UTC by Kevin Carter
Modified: 2020-02-06 14:43 UTC (History)
2 users (show)

Fixed In Version: openstack-tripleo-common-11.3.2-0.20191127200419.5c82293.el8ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-02-06 14:43:39 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
OpenStack gerrit 695998 0 'None' MERGED Update hostvars lookup to fix regression 2020-01-30 00:46:44 UTC
OpenStack gerrit 697103 0 'None' MERGED Update hostvars lookup to fix regression 2020-01-30 00:46:44 UTC
Red Hat Product Errata RHEA-2020:0283 0 None None None 2020-02-06 14:43:56 UTC

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


Note You need to log in before you can comment on or make changes to this bug.