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

Bug 1876464

Summary: [RFE][validations][pre-upgrade] Implement a check and stop if the current stack has a different HostnameFormatDefault
Product: Red Hat OpenStack Reporter: Jesse Pretorius <jpretori>
Component: python-tripleoclientAssignee: OSP Team <rhos-maint>
Status: CLOSED WONTFIX QA Contact: Jason Grosso <jgrosso>
Severity: medium Docs Contact:
Priority: medium    
Version: 16.1 (Train)CC: hbrock, jslagle, mburns
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-09-13 14:23:47 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 Jesse Pretorius 2020-09-07 09:37:51 UTC 
When doing an upgrade from OSP 13/14 to OSP 16.1, the default value for HostnameFormatDefault changes as described in bz#1846557. It would be ideal if there was a check against the existing stack which warned the user of that change before it took effect. This would provide the user with the option of changing their templates before the change took effect.

This implementation would be best implemented as a general purpose tool which could be used for any stack comparisons. The error message should provide the ability to refer to a URL in docs, or a BZ. It should also provide the ability to agree to go ahead regardless (with --yes or something like that).

As mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1846557#c15 this can be implemented in a similar way to the neutron mechanism check here: https://github.com/openstack/python-tripleoclient/blob/c5e1d309717abc31604c16445fef3e3d2d6aadd9/tripleoclient/v1/overcloud_deploy.py#L201
Comment 1 Jesse Pretorius 2022-09-13 14:23:47 UTC 
This is unique to the OSP 13->16.x upgrade process and the development of OSP 16.x is complete. If the documentation is not clear enough or needs a warning or something, then we would recommend requesting a warning note in the documentation and perhaps a reference to a knowledgebase article with more details.