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

Bug 2016684

Summary: [RFE]: Assume the use of more than one underlying version of RHEL
Product: Red Hat OpenStack Reporter: Jesse Pretorius <jpretori>
Component: RFEsAssignee: OSP Team <rhos-maint>
Status: CLOSED DUPLICATE QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 17.0 (Wallaby)CC: aschultz, chjones, eglynn, jslagle, markmc, mbracho, morazi
Target Milestone: ---Keywords: FutureFeature, Reopened
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-05-27 12:38: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:
Bug Depends On:    
Bug Blocks: 2006966    

Description Jesse Pretorius 2021-10-22 16:44:23 UTC 
The current deployment process assumes a homogenous environment with regards to the version of RHEL on the host.

In order to implement a smoother upgrade process, the assumption needs to be that there is more than one version of RHEL implemented on hosts in the environment.

In the case of distributed services like nova-compute, neutron-agent, etc there may be different versions of RHEL for an extended period of time (aka 'hybrid state' or 'mixed mode'). In this case we need to be able to still continue to make changes to the configuration, do scale-up/scale-down operations and implement updates for packages and containers.

This is essential for improving the workflow for the upgrade of very large environments and of environments with multiple cells.
Comment 1 Alex Schultz 2021-10-25 15:35:04 UTC 
This is too broad of scope to understand what needs to be fixed. The framework is generally OS agnostic as it's just running what it's told. Are there specific services/functions that need to be made more OS agnostic?  Its likely that RFEs need to be filed against specific services to address this where they assume specific versions of RHEL.  

From a framework standpoint (which is still really service specific), it sounds like there's a need to be able to provide different containers based on roles maybe?
Comment 3 Jesse Pretorius 2021-11-02 19:56:50 UTC 
We need to cater for multiple RHEL versions (at least two major versions) on compute, networker and storage nodes.
To make that work, we might need to select one or the other container based on RHEL version for those nodes to cater for components which have hard dependencies on specific kernels or devices (libvirt, iscsi, etc).
This may be possible through some THT changes, but the component DFG's will need an example to work from and we'll need to ensure that we have a way of differentiating the containers and we will need to build them. These will need to be updatable, which is not the case in 13->16.
We will also need to be able to update anything installed on the hosts - os-net-config is one I know of, there may be others. We'll need advice for what components will need this so that we can register RFE's against the correct DFG's.
Comment 8 Jesse Pretorius 2022-05-27 12:38:04 UTC 

*** This bug has been marked as a duplicate of bug 2077576 ***