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

Bug 2059368

Summary: [RFE][OSP18] RHEL Version Mix: Allow OSP to run on more than one major version of RHEL
Product: Red Hat OpenStack Reporter: James Slagle <jslagle>
Component: rhosp-directorAssignee: OSP Team <rhos-maint>
Status: CLOSED WONTFIX QA Contact: David Rosenfeld <drosenfe>
Severity: high Docs Contact:
Priority: high    
Version: 18.0 (Zed)CC: bdobreli, bshephar, grosenbe, jpretori, mburns, morazi, pweeks
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:
: 2072644 (view as bug list) Environment:
Last Closed: 2024-01-04 16:09:51 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 James Slagle 2022-02-28 22:08:57 UTC 
This RFE is for director changes for OSP.Next Goal 1: RHEL Version Mix:

https://docs.google.com/document/d/1Ec-Gk1cwwIykw51Tr8DAVrKGMEhlX2jmu3b72oFEi_E/edit#heading=h.vf8ggcboqtj2

Director needs to support deploying a single version of OSP across mixed versions of RHEL. This includes support for:

* A single OSP deployment might span different RHEL versions
* Different versions of RHEL need to be managed simultaneously with the same version of director

Possible implementations imply a separation of deployment tasks between those that are necessary for RHEL configuration and those that are necessary for OpenStack configuration. Or, it may imply configuration tasks that are RHEL version aware, and support multiple versions instead of assuming only a single version.

For example, when FFU is performed from OSP 17 to 18, it will be possible to upgrade to 18, while remaining on RHEL 9.Y. This may be accomplished with either noop'ing the RHEL configuration tasks, or adding support to tasks for both RHEL 9 and 10. A seperate overcloud management operation would then be used to then migrate from RHEL 9 to 10 at a later date, and would have to be explicitly triggered by the operator.
Comment 3 Brendan Shephard 2022-04-24 07:00:50 UTC 
The deployment completes with all containers running using current-tripleo:

```
[stack@tripleo-director overcloud]$ ansible -i tripleo-ansible-inventory.yaml overcloud-compute-0,overcloud-compute-1 -m shell -a 'podman inspect nova_compute | jq .[0].Config.Labels.name && cat /etc/redhat-release' -b
overcloud-compute-1 | CHANGED | rc=0 >>
"ubi8"
CentOS Stream release 8
overcloud-compute-0 | CHANGED | rc=0 >>
"ubi8"
CentOS Stream release 9
```

Be interesting to see if we get the same results with ubi9 containers. But at least an initial deployment works without any modifications to anything. So this may be less of a challenge than we initially suspected, and probably most of the dependencies will be with other components like Neutron if the host openvswitch versions have incompatibilities, etc.
Comment 4 Bogdan Dobrelya 2022-04-28 14:57:09 UTC 
The privileged containers become a special snowflake in this architecture:

RHEL doesn't support privileged containers, if the container OS does not match the host OS major version.
The host/container match requirement is just because the assumption is that privileged containers are likely to be using privileged kernel features.

tl;dr we need to discuss that requirement with RHEL and Containers teams.

It is unlikely we can get rid of all privileged containers in OSP, so the above requirement becomes a blocker for this RFE!

I can see a possible w/a for this situation, given the independent OSP containers / OS version upgrade requirement and this example workflow:

- deploy all nodes of RHEL version X with OSP containers for RHELX;
- (if we'd wish to support that) scale-out a few Nova computes as OSP X+1, but leaving RHEL version and all privileged containers at X there
- (if we support that) upgrade a few "old" Nova computes RHEL to X+1, leaving OSP containers at X, also the priv ones

Now when upgrading all that (n>=1):
- upgrade OSP containers to X+n, leaving RHEL on "old" X **and priv containers on the same version X of RHEL**
- then upgrade RHEL to X+n, then and only then upgrade the priv containers to X+n
- or vice versa, for other nodes: 
- upgrade RHEL to X+n, leave OSP on X (could the priv containers also stay on X then, or must become X+n to match OS version?)
- upgrade OSP to X+n (also with priv containers, if weren't upgraded on the prev step)

(I ignored the roles' and OVN specific upgrade order requirements to not make it even more complicated)