Bug 1846557
| Summary: | [upgrade] novacompute vs compute naming diff in 13 vs 16 results in redundant entries in 'openstack compute service list' | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | John Fulton <johfulto> |
| Component: | documentation | Assignee: | Dan Macpherson <dmacpher> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | RHOS Documentation Team <rhos-docs> |
| Severity: | urgent | Docs Contact: | |
| Priority: | urgent | ||
| Version: | 16.1 (Train) | CC: | amcleod, aschultz, bdobreli, dbecker, igallagh, jpretori, lbezdick, mbracho, mburns, morazi, ramishra, sbauza, scohen, smooney, spower, stephenfin |
| Target Milestone: | ga | Keywords: | Triaged |
| Target Release: | 16.1 (Train on RHEL 8.2) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Known Issue | |
| Doc Text: |
There is a known issue when upgrading from RHOSP 13 to RHOSP 16.1. The value of `HostnameFormatDefault` has changed from `%stackname%-compute-%index%` to `%stackname%-novacompute-%index%`. This change in default value can result in duplicate service entries and have further impacts on operations such as live migration.
+
Workaround: If you upgrade from RHOSP 13 to RHOSP 16.1, you must override the `HostnameFormatDefault` value to configure the previous default value to ensure that the previous hostname format is retained. If you upgrade from RHOSP 15 or RHOSP 16.0, no action is required.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-09-07 15:05:04 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
John Fulton
2020-06-11 22:17:02 UTC
Bug 1563866 is back and will continue to be back until we stop down-streaming this change. Can we instead of yet again donw-streaming the change make procedure to switch the name of compute and either do the removal in OSP13 or in FFWD 13->16. If we go with FFWD 13->16 we will need procedure for renaming both ways so we can support rollback. We would like Compute team to propose way out of this rabbit hole. (In reply to Lukas Bezdicka from comment #3) > We would like Compute team to propose way out of this rabbit hole. I mean, don't rename the service? Sorry for sounding flippant, but what's the purpose/use case behind renaming the compute services? (In reply to Artom Lifshitz from comment #4) > I mean, don't rename the service? Sorry for sounding flippant, but what's > the purpose/use case behind renaming the compute services? That is something that appears to have been done upstream between Mitaka and Newton. See https://bugzilla.redhat.com/show_bug.cgi?id=1365789 for more details. Ever since then there has been a downstream patch to prevent the rename during the upgrade process. (In reply to Lukas Bezdicka from comment #3) > We would like Compute team to propose way out of this rabbit hole. It's not possible to change this value upstream since it will result in the same issue in reverse for everyone else. We would also have the same issue if we forward ported it since that patch doesn't appear to have been included in 15.0, meaning anyone trying to upgrade from 15.0 -> 16.1 will break. Looking at that linked patch, it looks like this is configurable via the 'ComputeHostnameFormat' parameter. Forgive my ignorance, but couldn't this be overidden and set to the legacy value when doing a fast forward upgrade of an OSP 13.0 deployment? This would need to be done for any future upgrades to 17.1 etc. but it makes this a documentation issues and would prevent the need to carry the downstream patch for infinity. If that's not possible now, we'll have to make it so. I think this needs to be solved in two parts: 1. Document that the HostnameFormatDefault changes from '%stackname%-novacompute-%index%' to '%stackname%-compute-%index%' and how to (a) add the applicable configuration to maintain the previous naming standard or (b) what the effect is of not changing the default and how to clean up the old service names. 2. Implement a check and stop (unless --yes or something like that) if the current stack has the old naming convention and the to-be config will change it. The first is essential for GA. The second is ideal to have for GA because it will prevent people making unexpected changes in their cluster. I've registered an RFE in https://bugzilla.redhat.com/show_bug.cgi?id=1876464 and will therefore convert this into a docs bug. Closing this BZ as the docs component has already been implemented. |