Steve, you ask a great question here. Specifically...

Now that we have artifacts accepted as an OCI project, what is the thought process to pull this out of experimentation?

At KubeCon/CloudNativeCon EU this year we learned that there is good demand for Helm v3 sooner rather than later. Specifically, a Helm without Tiller. Having to install Tiller has proven to be problematic for several reasons in many environments. Especially those that lock down access for security. With that in mind we pulled back on all the features we wanted for v3.0.0 in order to get this out the door more quickly. We are entering the home stretch in our effort to get that out the door.

That meant some of the features we wanted to have in the 3.0.0 are going to have to wait for a feature release (minor version increment in SemVer terms). Charts in registries was one of those features.

In my mind, for charts in registries to become a reality we need a couple things:

1. The UX within the Helm needs to be completed. That includes things like search, signing, and other areas.
   
2. Helm needs to implement the spec appropriate for artifacts. Looking at the artifacts repo, which was created on August 11th, I don't yet see those details in a release form. We'll need to understand those details (which I imagine Josh is well up to speed on) and where they sit within a release cycle. We don't want to release a stable feature in Helm holding to SemVer on it with something in development that may change at any time.
   

I'm excited to have Helm charts in repositories. We just need to make sure we dot the i's and cross the t's prior to telling everyone it's stable. I look forward to that happening in a feature release.

In addition to these two things I would like to see the Helm Hub be able display charts in registries. I wouldn't call this a blocker for the Helm CLI, though.

All of these are areas we are open to contributions if anyone is interested.

Steve, how will the registries support something that doens't have documented guidance that's released with a version (more than dev)? You noted ACR does while ECR and Harbor are looking at it. Do you know the timetable for the OCI artifacts project to get to releases with directions for projects?

Thanks,

Matt Farina

On Wed, Aug 21, 2019, at 7:24 PM, Josh Dolitsky wrote:

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?