1. Messages
  2. 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

Josh Dolitsky
 

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.

Josh

On Wed, Aug 21, 2019 at 4:09 PM Steve Lasker <StevenLasker@...> wrote:

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 {cncf-helm@lists.cncf.io to automatically receive all group messages.