Open sathieu opened 3 years ago
@rbreeze Are you sure about cherry-picking the change of this behavior into 2.1? Frankly, I think this is not a bug, but rather an enhancement to existing functionality. I agree with the v2.2 milestone, but I'd oppose cherry-picking a behavioral change like a possible fix for this into 2.1.
I confused @rbreeze and asked to add cherry-pick label. Removing it
Thanks a lot for the investigation and preparing the summary @sathieu ! It helps a lot.
I think problem 1 is solved already. The https://github.com/argoproj/argo-cd/issues/3594 was reported for v1.5.4 which indeed did not have support for --api-versions
We can fix problems 2 and 4 in v2.2! Working on pull request.
Thanks @alexmt. Looking forward for those fixes!
We are facing the same issues at the moment when we try to update our ingress API versions. Looking forward to the changes aswell @alexmt
@alexmt @sathieu can you confirm if this is what is expected for issue #3594 - PR #8371
@gdsoumya Don't know. I'm more interested in problem 3.
Describe the bug
There are several bugs about
.Capabilities.APIVersions
.Here is my understanding of the current behavior, with identified filled issues:
helm template
with--kube-version x.y
and--api-versions api/version
helm template
doesn't access the k8s API, but it fills.Capabilities.APIVersions
with the api/version (in pkg/chartutil/capabilities.go)--api-versions
to the list it gets, we proposed a change here (not accepted): https://github.com/helm/helm/pull/10108. This is this bug :point_left:To Reproduce
With a given chart,
repo-server
will log:ArgoCD is correctly passing k8s version and api/versions, (but not api/version/kinds - problem 2), however while only
policy/v1beta1
is passed,policy/v1
will also be in.Capabilities.APIVersions
, because Helm was compiled with k8s 1.21. As such, a template will have the following evaluated incorrectly:As a workaround, and thanks to problem 4, changing the condition will evaluate correctly:
Expected behavior
.Capabilities.APIVersions
to not be prefilled with values depending on the k8s version used during the Helm build.Some cooperation is needed between ArgoCD devs and Helm devs about this, we can work on the implementation.
Proposals:
--strict-api-versions
option to Helm (https://github.com/helm/helm/pull/10108)StrictAPIVersions
in the struct, and change ArgoCD to build against Helm (see here)Hardcode api/version/kind for each k8s version(rejected by Helm maintainer)helm
to access k8s API to fill.Capabilities.APIVersions.
Version