Currently, ArgoCD v1.5.0 support both Helm 2 and Helm 3 without OCI enabled. Details about Helm 3 with OCI enabled can be found from https://helm.sh/docs/topics/registries/. In the future, more and more classic chart repositories (index.yaml-based repos) will be migrated to the OCI-based registries.
We are using the helm v3 OCI feature to store and share packages across OCI-based registries and I have a proposal to support this feature. Wish to get some comments about this proposal.
We are using Alibaba Cloud Container Registry which has supported a OCI-based registry to store chart packages. Compared with index.yaml-based repos, fetching a chart will be like this:
$ HELM_EXPERIMENTAL_OCI=1 helm registry login demo-registry.cn-hangzhou.cr.aliyuncs.com --username xxxx --password xxxx
$ HELM_EXPERIMENTAL_OCI=1 helm chart pull demo-registry.cn-hangzhou.cr.aliyuncs.com/demo/app-demo:0.1.0
$ HELM_EXPERIMENTAL_OCI=1 helm chart export demo-registry.cn-hangzhou.cr.aliyuncs.com/demo/app-demo:0.1.0 /tmp/helm373662/
Then a chart folder named app-demo will be saved to /tmp/helm373662/ , and other operations like helm template or helm show are the same as before in ArgoCD
In my proposal:
repoType named helm-oci to help determine if a HELM_EXPERIMENTAL_OCI=1 helm operation is needed, because we have no chart content to determine correct Helm version and type when ExtractChart. Add new function Login,Logout and modify Fetch to implement helm registry login,helm registry logout,helm chart pull and helm chart export operations, related file is util/helm/cmd.go
Other files like reposerver/repository/repository.go,util/helm/client.go ... will be involved.
Any comments about this proposal are welcome, and I will submit a PR if it can be accepted.
OCI storage method will be the mainstream direction in the future, it provides better security and more convenient interactive experience, @jannfis help to see if this requirement is suitable, we are willing to contribute this function to the community
Hi @haoshuwei and @xianlubird, thanks for this proposal and the offer to contribute this functionality!
As the OCI feature in Helm v3 is still considered experimental, I'm unsure whether we should implement it in ArgoCD at this point in time, at least not as a mainstream feature.
I guess if you would put the implementation behind a feature gate/toggle which is disabled by default (similar to how Helm does it), and the semantics of current repository access would not change (neither with the feature turned on nor off), chances are that we can merge an early implementation and develop it along while the feature evolves in Helm. Once the feature comes out of experimental stage in Helm, we could also enable the feature by default.
However, I think due to the fact that there will be major internal changes in v1.6 (GitOps Engine), target version for merging a PR would be likely v1.7 at the earliest.
@jessesuen @alexmt - what's your take on this?
@jannfis any estimates when v1.7 (with this feature) will be released/stable?
Hi. I think it is an important feature also because some cloud native native solution such as azure container registry integrated OCI Helm Registry : https://docs.microsoft.com/en-us/azure/container-registry/container-registry-helm-repos .
Implemented by https://github.com/argoproj/argo-cd/pull/4018
Can you precise in which release this has/will be included ? Looking forward to use this to replace old chartmuseum.
@fredleger This will be part of the upcoming v1.8 (as indicated by the target milestone)
@jannfis thanks for the info didn't pay attention to the milestone, sorry for that
Most helpful comment
@jannfis any estimates when v1.7 (with this feature) will be released/stable?