cert-manager: removing and preventing 'alternate' versions of Helm charts

[munnerz]

Hey all 👋

I've been taking a look through various Helm chart repos (i.e. artifacthub, helm hub, chartcenter etc) and have found that there are a number of 'alternate' versions of the cert-manager Helm chart being published and listed on the Helm Hub: https://hub.helm.sh/charts?q=cert-manager

Whilst I am all in favour of openness and allowing people to do what they want with our software, I am concerned that this may 1) confuse end-users and 2) put users on an 'unsupported' release, which we will have little to no recourse to correct as a project.

If there are changes needed in the cert-manager Helm chart, it'd be far more productive if these could be proposed, discussed and merged upstream so that we can properly take care of users.

There are currently three repositories that contain a variant of the cert-manager chart (all of which are either incorrectly published with the wrong version number, contain patches that are now already upstreamed and implemented in a manner that is dangerous for end-users, or otherwise out of date):

• infobloxopen (managed by @drewwells) - which appears to just be a direct copy (no changes to the README at least), on an outdated version. The repo in question also reads as if it is cert-manager specific based on the domain name too.

• choerodon (managed by @vinkdong) - from what I can tell, this exists to provide a mirror for our Helm chart so it can be used in China, although I am not certain on the version being published here without digging into the chart further myself. I am uncertain whether our main Helm chart (jetstack/cert-manager) can be fetched in China, and do appreciate the efforts from the community to help adoption in this region. If that is the case, it'd be great to work with you @vinkdong to avoid us confusing others users (and to sort out version numbering, or for us to ensure the jetstack repo is accessible in China).

• cloudposse (managed by https://cloudposse.com/, added by @osterman) - this is a very old version of our Helm chart that includes CRDs as part of the Helm chart in an unsafe way (via the crd-install annotation) - without going into the conversation around use of this annotation again, to summarise, it prevents the cert-manager team's ability to manage CRD versions. Our own Helm chart already supports this functionality nowadays anyway, in a safe way, via the installCRDs option in our values.yaml.

What's the best way to go about addressing this? If the cc'd maintainers could respond here with their thoughts, and/or make the change to remove these charts, it'd be greatly appreciated.

As an aside, is there any kind of process to handle this in other instances? As these sorts of 'registries' develop, it's going to become more and more of an issue (especially if big corp legal teams get involved 😅)

Thanks! 🚀

[mattfarina]

@munnerz thanks for bringing this up here.

The first thing I'd like to point out is that multiple charts for the same application are technically ok. For example, someone might provide a chart with a simple install while someone else might provide something far more configurable. Multiple charts from different people are ok.

I'm reminded that there are numerous debian packages for mysql or mariadb out there. Some are not very discoverable but they exist.

That being said, we have long had conversations on highlighting the "official" chart where possible. For the case where the project itself puts out a chart. This is not something we have implemented in the Helm Hub. Might I ask that you file an issue on Artifact Hub about this. I will follow-up on your issue there but that way you can track it. The long term plan for the Helm Hub is up in the air. Ideally, we would like the Artifact Hub to replace it. Either with the software or with the actual site.

The Artifact Hub has the ability for people to star charts. I think that's also a nice way to help indicate which to use. We are looking at other markers and if you have suggestions please file issues.

Quay is listed as being available in China so I would suspect your images are as well. There is a Helm Hub like site for China at https://developer.aliyun.com/hub/. This is done by Alibaba who tries to make sure the charts work in China.

There is no perfect solution to this problem. We can do much better, though. Suggestions are welcome.

[osterman]

@munnerz thanks for raising the issue regarding our cert-manager chart.

We should delete that chart from https://github.com/cloudposse/charts, but will preserve it in our chart repository for people still using it. It ended up not working well, for the reasons Jetstack warned about and that you raised, which is why we do not use it anymore.

[mattfarina]

@osterman prior to deleting it, you could mark it as deprecated. This would make it disappear from displays by default but still be discoverable.

[mattfarina]

I created an issue on artifacthub/hub#542 for official versions of artifacts.

[osterman]

So we've gone ahead and deprecated the chart and will subsequently remove it.

Also, not sure if part of the concern is related to the maintainer field. We struggle with this because whilst we became the maintainer of this chart in our repo, we wanted to maintain attribution. We changed very little but wanted to credit the original maintainers so we left that there, even though we were the maintainers of this fork.

That said, to @mattfarina 's point, we don't see anything wrong with having alternate versions of the chart published; that is the open-source way. =) Blocking alternate charts would be very much against the ethos of open-source (and probably the law of open source licenses). More importantly, alternate chart versions provide field tests of alternatives to the "official" chart that the software maintainers can consider in their future plans without requiring them to make an immediate decision. Cloud Posse publishes several charts that we believe are "better" in some substantial way than the "official" charts or else we would not have bothered to create and publish them. Of course, "better" is subjective, and we do not try to persuade anyone to use our charts, but every chart we publish is one we have used successfully at some point in time, so obviously we see value in them as compared to the pre-existing charts.

While we always try to work with chart creators to have them update their charts, the process is often too slow when we are faced with an issue preventing us from using the existing chart right away on our customer engagements. In the case of the cert-manager chart, we had a philosophical difference of opinion, preferring an approach that Jetstack officially rejected, so that certainly was not going to be "merged upstream".

That said, we fully support efforts to highlight the chart published by the maintainers of the underlying software. We're grateful for the hard work Jetstack puts into the cert-manager project which we have relied on for years. Certainly, users should be made aware of who is responsible for the chart being published, and efforts made to prevent confusion over which chart has the support of the software developers. We also look forward to seeing improved means of attribution in chart manifests but oppose anything that would limit the openness of charts in the helm ecosystem.

[mattfarina]

@osterman You bring up a great point on the maintainer field on a chart. It's not about attribution. We should clarify the meaning and use of it somewhere. The maintainer field is for the point of contact of the maintainers of this instance. If there is an issue, such as a security problem, those are the maintainers to contact. In the case of a fork with changes, it's the forks maintainers.

[scottrigby]

Now that Helm Hub has moved to Artifact Hub, and we have an issue for this there #402 (comment), let's close this one.

[drewwells]

We had issues using the upstream chart and reached out several times to negotiate with the upstream maintainer about it. They closed those issues, which left us with requirements that the upstream chart did not support. Now that helm and this chart have matured, the default cert-manager have finally met our requirements and the fork has been removed.

Related to the topic of alternate versions. There are a number of situations where maintainers are not interested in supporting or allowing through configuration to support client use cases. In CertManager's case, we had a requirement that the chart include all dependencies in the chart. I believe this is actually outlined in the original helm charts repo, helm install {chart} should work with default values. For cert-manager, this was not the case until fairly recently. We created a github repo that applied git patches to the Jetstack repo so helm install {chart} works. Thanks to changes in the original repo, we noticed that dependencies are now included by default (yay). So we closed our fork.

We had to make this alternate chart to satisfy our use case. The ability to publish that alternative chart so others could take advantage of the work is fundamental to OSS. Ideally, you can negotiate with the original maintainers so forking is not necessary. It is not always possible to do so and maintaining an internal fork costs nearly as much as publishing an open source one, sometimes it costs a lot more to keep the repo private. It's advantageous to all users and future users that forks are available. If you ask most OSS project founders, they started by loving a tool. Yet, that tool had just one small thing that they didn't like, so they forked or made a similar project that does this one small thing.

I have been on the other side trying to sort out which chart is the 'best version'. Grafana and Grafana operator are good examples of this. It can be confusing to sort out which one to use, but I don't expect Helm Hub to answer that question for me. As long as the alternative chart provides a maintainer contact, then a user can reach out for detailed questions about the nature of this alternative chart.