1. Proposed title of this feature request

Coordination between OpenShift and "Infrastructure Operators" During Upgrades

2. What is the nature and description of the request?

The customer would like to request OpenShift define a declarative method for coordinated and automated updates of infrastructure operators during the cluster upgrade process for both connected and disconnected clusters.

The goal is to ensure that when the platform is updated, key operators integral to the platform, such as ODF, are upgraded as part of the process to limit manual steps, shorten upgrade time, and increase upgrade predictability and success rates.

It may be possible to enable "single click" upgrades by aligning the OLM and CVO operators.

3. Why does the customer need this? (List the business requirements here)

Because there is no coordination between infrastructure operators such as ODF and the cluster operators during upgrades. For one key customer, their operations team must follow numerous detailed instructions and run corresponding scripts at various points of the upgrade process as well as document and script for exception-based interventions.

This means the upgrades, especially between EUS versions, can take more than a single personnel shift and the process has to be handed off within the operations team. Sometimes with their larger clusters, EUS-style upgrades can even come close to taking longer than a weekend change window can accommodate.

Providing a way for "infrastructure" operators like ODF to integrate into the upgrade process would have the following benefits:

• Enable frequent, security patch updates
• Enable the customer to keep pace with updates more easily
• Improve perception of updates and the platform
• Encourage adoption due to platform stability
• Enable upgrades during the shorter nightly change window instead of weekends.

The risks of inaction and maintaining the status quo 

• Life cycle management becomes too onerous
• Lack of adequate change windows prevent updates from happening in a timely manner
• Long upgrade times can mean only one cluster a week can be upgraded, making fleet upgrades nearly impossible.
• Operations will tend to lock into single versions for too long, exacerbating bugs that are fixed and leaving security issues unpatched.
• Reputation harm as the platform is viewed as brittle.
• Customer dissatisfaction can lead to slower adoption or alternative platforms.

4. List any affected packages or components

OLM, CVO, etc.