Feature Overview

Keep argocd instances on separate versions with the same Openshift GitOps Operator{}

OpenShift GitOps works together with ACM to manage clusters across different environments (dev, acceptance, prod, ...). However we can only update the OpenShift GitOps operator and its instances at the same time, preventing us to do a gradual rollout over the different environments. This means we can not test an update first in dev before promoting it.

Business Goal/Objective

What is the nature and description of the request?{}

OpenShift GitOps works together with ACM to manage clusters across different environments (dev, acceptance, prod, ...). However we can only update the OpenShift GitOps operator and its instances at the same time, preventing us to do a gradual rollout over the different environments. This means we can not test an update first in dev before promoting it.

Why does the customer need this? (List the business requirements here){}

We need to be able to test an ArgoCD update before rolling it out to higher environments.

How would the customer like to achieve this? (List the functional requirements here){}

Specify the version in the ArgoCD instance or install multiple versions of the operator in a supported way. If the engineers can think of a better way to achieve this, it's also fine for us.

Goals

• < Who benefits from this feature, and how? What is the difference between today's current state and a world with this feature? >

Requirements

Use Cases

• < What are we making, for who, and why/what problem are we solving?>

Out of Scope

• <Defines what is not included in this story>

Dependencies

• < Link or at least explain any known dependencies. >

Background and Strategic Fit

• < What does the person writing code, testing, documenting need to know? >

Assumptions

• < Are there assumptions being made regarding prerequisites and dependencies?>
• < Are there assumptions about hardware, software, or people resources?>

Customer Considerations

• < Are there specific customer environments that need to be considered (such as working with existing h/w and software)? >

Documentation/QE Considerations

• < What educational or reference material (docs) is required to support this product feature? For users/admins? Other functions (security officers, etc)? >
• < Does this feature have a doc impact? Possible values are: New Content, Updates to existing content, Release Note, or No Doc Impact>

Impact

• < If the feature is ordered with other work, state the impact of this feature on the other work >

Related Architecture/Technical Documents

• <links>

Definition of Ready

• The objectives of the feature are clearly defined and aligned with the business strategy.
• All feature requirements have been clearly defined by Product Owners.
• The feature has been broken