Enabling Chart Dependency within the Red Hat OpenShift Certified Helm Chart Index

Red Hat's Helm Chart certification program has made our partner's certified Helm charts instantly accessible for installation via the OpenShift® Console since 2021. Using the OpenShift developer console view, our customers have immediate access to your software, making the deployment and management of that software just a few clicks away.

For developers who prioritize working with Helm across Kubernetes and its distributions, especially those working at scale, it stands to reason that relying on Helm's dependency system to join complementary charts is a top priority in order to ease the maintenance of your software deployment stack.

Several developers have noticed that our certified index has historically not allowed for a chart developer to depend on a chart that lives in our index without a manual workaround for each chart on which you depend. This is actually further demonstrated when attempting to use GitOps platforms such as OpenShift GitOps, ArgoCD, etc.

Here, I'll cover a brief description of the problem we see, our approach to resolution, and then  address how your experience as a Helm certification partner may change.

Our indexing approach

The certified index is one of the core components of our Helm certification program. Our certified chart index is where users will find your certified charts after you've successfully completed the certification process. Today, we use a Helm repository, which is effectively an index.yaml file, that is updated periodically each time a chart completes our certification process.

The details of Helm indexing are pretty straightforward: The index file contains a map of chart entries, where each key corresponds with a chart's name, and its value is a list of the various versions of that chart available through the index.

The chart certification automation takes each chart that passes our certification policy and updates our repository with the corresponding entry. This is where things get tricky.

It stands to reason that multiple partners may want to release a Helm chart with similar names, even if just to customize the deployment of that chart in a way that is tightly coupled with the underlying application being deployed. Red Hat's software certification programs commonly allow for this kind of duplication, and will typically namespace assets in our indexes and repositories to allow for the reuse of these names. This is how our index works today.

If you look at our index, you'll see that all charts are preceded with your unique “partner label”, a simple string representing your organization, in our entry mapping.For example, if you provide a chart called "hello-world", and your partner label is "awesomepartner", your index key will be added as "awesomepartner-hello-world", which effectively namespaces your chart to your organization, and allows for another partner to bring their own "hello-world" chart without impacting you.

Mismatching entry keys and chart names

Indexing in this way solves the issue of partners bringing charts with the same names, but we've inadvertently caused another problem: the chart entry keys and the chart's name have now drifted. From the previous example, "awesomepartner" had certified a chart called "hello-world", not "awesomepartner-hello-world"! And, for the most part, this is a transparent mismatch. If you attempt to install that chart using the Helm CLI, or OpenShift's developer console experience for Helm, you should see no issues at all.

However, Helm's packaging tooling (i.e. helm package)  complains when you try to define a chart in our index as your dependency, pull it down locally, and then package up your chart with the included dependencies. The chart you will pull from our index (i.e. with helm dep up) will be stored locally at the chart's actual name (e.g. "hello-world"), but in order to pull it down, you would have referenced it by its index entry key (e.g. "awesomepartner-hello-world"). At packaging time, Helm correctly identifies that it should see a dependency in your charts/ directory that corresponds with what's in the dependencies section of your Chart.yaml, and that it's missing (because it's stored under the Chart's actual name).

This is far from ideal, and also causes issues with platforms such as OpenShift GitOps, ArgoCD, etc. which all complain for similar reasons.

Our approach to resolving this in the near term

Long term, we believe that distribution of Helm charts through an OCI registry, which has graduated to general availability as of Helm 3.8.0, may help us improve our certified chart repository strategy. But as of this writing, we have not completed an evaluation on migrating to OCI registry-based distribution model.

Until then, we wanted to resolve this in a way that required the absolute minimum from our certified partners, aside from partners validating that everything continues to work as you expected, seamlessly, after we've implemented our fix. To that end, here's what we plan to do.

We will be dropping the namespace component for our partner charts as they stand in our certified index, and will be requiring globally unique chart names across all of our certified Helm chart partners as a side effect of that change. That is, our "awesomepartner-hello-world" mentioned above will simply be indexed as "hello-world".

Once we make this change, users of your chart should be able to immediately include your chart as a dependency, and get full access to your entire chart version history.

Your chart, in the OpenShift Console, will be represented exactly as it was before this change is implemented, and in our testing, existing installations can be upgraded seamlessly and transparently to a new version after this change rolls out.

What can I expect?

As a partner, you should evaluate the following tasks to see which apply to you:

• Any of your documentation that refers to the old chart name in our registry should be updated to use the new chart name.
• When creating net-new chart certification projects via Red Hat Partner connect, make sure to include your organization’s name in your project’s naming if you want it to be a part of your indexing. Note that this is completely optional, and will not impact your organization’s presentation within the OpenShift Console. At the time of this writing, we do not support a migration path for existing certification projects.
• Test away and make sure the experience is as you expect. Specifically, try to create and package a Helm chart that depends on your certified chart locally, and/or try to deploy your chart using OpenShift GitOps.

You may also notice some automation changes when you submit your chart for certification via our repository.