cert-manager: removing and preventing 'alternate' versions of Helm charts about hub HOT 8 CLOSED

@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.

from hub.

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

from hub.

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

from hub.

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.

from hub.

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.

from hub.

@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.

from hub.

@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.

from hub.

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

from hub.