[Helm] Helm Charts Management

[wbuchwalter]

Hello!

Managing all Helm charts through a GitHub repository is not really scalable:
The few maintainers of the repository have the responsability to merge and review all the charts, even the one they are not familiar with or never used, thus slowing down the release cycle of every chart.
Since adding the creator of each chart as a contributor so they can take ownership of their charts is not really doable, this will become increasingly painful the more Helm get used.

Do you think a system closer to npm would be beneficial? Each chart creator is responsible for the release cycle of it's chart, doing the review etc.
Essentially, each chart would live in a different repository, and hcm ( helm chart manager... :) ) would mostly be a discovery tool.

What do you think & Is anyone already working on something similar?

cc @seanknox @lachie83

[seanknox]

FYI @kubernetes/charts-maintainers...

[seanknox]

Also @technosophos who might have opinions (on this).

[prydonius]

@wbuchwalter interesting idea, I know @viglesiasce has some ideas about giving chart developers more control over the release cycle via separate github repos in a single org. That said, I do think maintaining a single repo is ultimately doable with the right process and automation - Homebrew is a great example of this.

The only concern I'd have about an npm style model is that it can become harder to maintain quality and consistency of charts.

[viglesiasce]

Hey folks!!!

I have indeed been thinking about this!

The value of this repo is in having a standardized CI process and code review from maintainers keeping patterns and methodologies consistent and sane, producing "higher quality"* charts than if there were random repos all around GitHub. Another benefit of having this repo is that there are gatekeepers for what ends up in the default repository, stable.

Fortunately, due to some of the patterns and conventions established here, other projects/products/services have been able to create and maintain their own "high quality" charts. It would behoove us as maintainers of this repo to not replicate the work that those folks are doing.

I propose that we figure out how to onboard other blessed repos that would like to benefit from the CI and release process that we have established here.

I wont postulate too much about solutions to this problem at the moment as I believe there are many.

*in theory

[ant31]

@viglesiasce

gatekeepers for what ends up in the default repository, stable

I think it can be done by having a core-team at the org level: kubernetes-charts, that are mentionned to take a final review before tagging 'stable' a chart release.
Also stable is true only at a single moment (tag) and the current mono-repo model don't capture that.

benefit from the CI

I don't know how your CI is working but can't it be extended to any repo?
Also we can define criteria to have chart entering the kubernetes-charts/* and criteria to retired them

What about moving couple charts to begin and enabling the CI for them ?

[kachkaev]

There is a related discussion in #1714.

[jzelinskie]

This hasn't yet been mentioned, but is absolutely related: App Registry is a project developed in the open that gives standups during SIG-Apps that attempts to build a registry protocol and client for managing artifacts like Helm charts. There's an open source Python client and server implementation, a Helm plugin, and Quay.io support. This doesn't address "quality" or officially maintained Charts in one centralized place, but relies on the user to trust the namespace where they found the chart (e.g. trust quay.io/coreos/etcd-chart for a stable etcd chart) much like what has been done for the container image ecosystem.

[bhack]

I think that some charts could be trusted by the namespace but for others handing MIA and trusting the source it is required. Scalability and quality assurance can go together only if the trust can scale.
This is a process that Debian is handling by years.

[mattfarina]

Here's another option, at least for the short term. The k8s CI systems works with OWNERS files. If each chart had an OWNERS file containing the GitHub id for the owners then they could approve PRs that affected those charts without having full permissions to all charts. This could take advantage of existing tooling.

[mattfarina]

@kubernetes/charts-maintainers anyone opposed to a PR that adds owners files to any chart we have the details for? This would be a start to using the OWNERS to enable more people to merge changes to their charts.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close