Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compatibility matrix ArgoCD Operator and ArgoCD #1283

Open
popalav opened this issue Mar 18, 2024 · 3 comments
Open

Compatibility matrix ArgoCD Operator and ArgoCD #1283

popalav opened this issue Mar 18, 2024 · 3 comments
Labels
documentation Improvements or additions to documentation

Comments

@popalav
Copy link

popalav commented Mar 18, 2024

Is your task related to a problem? Please describe.

Compatibility matrix between ArgoCD Operator and ArgoCD is missing.

Describe the solution you'd like

A compatibility matrix for each new released version of ArgoCD and their corresponding ArgoCD Operator version, also this should be done for previous releases as well.

Describe alternatives you've considered

If not a compatibility matrix, than a clear state in the release notes about ArgoCD and ArgoCD Operator corresponding versions available.

Additional context

For example I have updated to ArgoCD 2.9.2 with version Operator version 0.7 just to find out that these versions are incompatible, and that Operator 0.9 is needed for that specific version of ArgoCD.

@fuerer
Copy link

fuerer commented Mar 18, 2024

To what I know, ArgoCD version 2.x exhibits a direct compatibility with the ArgoCD operator version 0.x. This compatibility matrix implies that if you desire to utilize ArgoCD version 2.9, you necessitate ArgoCD operator version 0.9, and this pattern extends accordingly.

The rigid interdependency arises due to the fact that the ArgoCD operator encapsulates and integrates the ArgoCD Custom Resource Definitions (CRDs) essential for proper operation. Hence, upgrading ArgoCD versions often necessitates a corresponding update to the operator to maintain alignment with the CRDs.

However, I encountered a scenario where I successfully deployed ArgoCD version 2.10.2 while employing ArgoCD operator version 0.8.0. This configuration diverges from the established compatibility matrix, but it proved viable for my specific environment.

To achieve this, I manually obtained the CRDs tailored for ArgoCD version 2.10 and substituted them for the existing CRDs, which were configured for version 2.8. It's important to acknowledge that this approach may not be advisable for production environments due to potential risks associated with compatibility mismatches. Nonetheless, for the purposes of testing, this workaround functioned seamlessly within my testing environment

@popalav
Copy link
Author

popalav commented Mar 19, 2024

Thank you for your quick response!

@saumeya saumeya added the documentation Improvements or additions to documentation label May 1, 2024
@doman18
Copy link

doman18 commented Jul 5, 2024

@fuerer Its not always 1:1 relation. For example 0.7.0 has upgraded Argocd to 2.6.1

My case is that i have to provide upgrade plan for okd cluster from version 4.8.0 (k8s 1.2.1) to the newest. Redhat has tool which generates upgrade path for openshift to newest version. My client (big finance institution) require from me to do impact analysis and provide upgrade plan for each app/operator installed in cluster. This should look like this

OKD version -- k8s version -- upgrade channel -- argocd operator version -- another app version
4.8.0 -- 1.21 -- stable-4.8 -- 0.1.0
4.9.28 -- 1.22 -- stable-4.9 -- x
... etc

So not only i need Operator vs. ArgoCD corelation (which would be easy if indeed their minor versions were equal all the time) but also their dependency on k8s. And such informations are just not existent to my knowledge. The only tiny bit of relevant information i found here. But its not enough
https://argo-cd.readthedocs.io/en/stable/operator-manual/installation/#tested-versions

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

4 participants