- How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out
Re: How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out
toggle quoted messageShow quoted text
Just so everyone has reference, Steve is referring to the fact that the "chart" and "registry" subcommands in Helm 3 are hidden behind an experimental env var. For more info, please see this doc: https://v3.helm.sh/docs/topics/registries/
IMO the registry stuff has been marked experimental in Helm 3 at this point for a few reasons:
- Unresolved UX issues. For example, you currently cannot "helm install" a registry-based chart without first exporting it to local directory
- OCI compliance - the artifacts repo has been created, but it does not yet provide concrete, agreed-upon guidelines for alternate artifact support
Helm chart support across all registry providers would be nice of course, but this isn't what's primarily keeping these things from getting out of experimental mode. For now, we can start instructing users to set HELM_EXPERIMENTAL_OCI=1 in their environment if interested in using registries at this early stage.
Now that we have
artifacts accepted as an OCI project, what is the thought process to pull this out of experimentation?
This isn’t as much a chicken/egg scenario as cart/horse. Registries will prioritize enabling artifacts as there are interesting artifacts to store.
- ACR already supports Helm
- ecr has said they will, when it gets adopted.
- Harbor is also looking to support artifacts, including helm 3.
- Quay either already supports, or would support – (jimmy ? )
We know the current limitations of storing lots of helm charts with index.yaml. Artifact support solves the automation of chart builds not toppling over index.yaml.
Is the question whether someone using helm would have a registry?
Join firstname.lastname@example.org to automatically receive all group messages.