Charts: RFC: Have each chart in its own git repository

Created on 11 Aug 2017 · 13Comments · Source: helm/charts

Hi,

I'd like your take on this subject.

Currently all official helm charts are hosted in the same git repo. Personally I find this kind of organization quite disturbing. I had no problem with it as long as it was invisible to be, as long as I was a first time helm user and I was just using the charts without looking under the hood.

Now that I've come to deploy a lot of things with helm on different k8s clusters that have different configurations I arrived to the point where official helm charts could, in some cases, not meet all my needs. One example I have right now is Prometheus chart which does not allow setting a custom service account.

At this point I came here and realize that all charts were grouped in the same repository.

I was pretty surprised. In my head I was going to take a quick glance at the Prometheus helm chart issue tracker to see if there already was a issue about the service account and Prometheus and if not, clone the Prometheus helm chart, make a quick patch and submit a PR. I did not expect to dig into all the charts issues and clone all the helm charts at the same time.

According to me each charts should have its own repo for the following reasons:

Each chart is completely independent from the other
Common git commit history for independent components is disturbing/messy
Common issue tracker for independent components is disturbing/messy

I understand that even if you came to agree, It could be know quite impossible to change things now, but who knows, right ? :)

Cheers.

lifecyclrotten

Source

sylr

👍11

Most helpful comment

I've often thought the same thing - perhaps this repo can become the master repo, and all the charts can live in their own, and be added to the master as git submodules ?

I'm sure some tooling would need to be modified, but it should be possible, with some effort.
Awaiting comments from the maintainers of this repo.. :smile:

egeland on 12 Aug 2017

👍4

All 13 comments

I've often thought the same thing - perhaps this repo can become the master repo, and all the charts can live in their own, and be added to the master as git submodules ?

I'm sure some tooling would need to be modified, but it should be possible, with some effort.
Awaiting comments from the maintainers of this repo.. :smile:

egeland on 12 Aug 2017

👍4

Docker's official library repo is just an index of independent repos, each having its issues, branches and members. E.g. https://hub.docker.com/_/traefik/ corresponds to just a single file at https://github.com/docker-library/official-images/blob/master/library/traefik. In turn, this file references the repo with all the ‘meat’ at https://github.com/containous/traefik-library-image (that is a different github org).

When an official docker image needs to be updated, the members of the vendor team discuss a PR amongst themselves and merge it to master of their own repo (i.e. not yet docker-library/official-images). Then, someone creates a small PR with the new tags and git SHAs similar to this: https://github.com/docker-library/official-images/pull/3259. Finally, the maintainers of docker-library/official-images merge this PR and the images become available at https://hub.docker.com/_/*/.

This workflow contains more steps, but feels to scale better. It also allows for some extra public image testing before they become ‘fully official’ (i.e. land https://hub.docker.com/_/*/). I'm not sure if switching to something similar for the official helm charts repo is worth the effort right now, but I agree with @sylr that leaving things as is may over time create a tremendous mess in issues and PRS and also put too much load on the k8s members.

IMO, making it possible to optionally reference a chart instead of copying its contents to this repo could be a good start. E.g. there exist a few charts for GitLab, which are truly official (i.e. they are maintained by the same guys that develop GitLab itself). Those charts are located at https://gitlab.com/charts/charts.gitlab.io. At the same time, this repo contains two other charts called gitlab-ce and gitlab-ee, which are developed independently and are likely to fall behind. It'd be great if there was some mechanism for replacing these with the links, thus making the chart development process a bit more distributed and less prone to self-repetition or inconsistencies.

Over time, more teams might want to maintain the official helm charts for their products thus reducing the buzz in kubernetes/charts issues and finally making this repo just an index of the hundreds of official charts, similar to how this is organized in the official Docker library.

kachkaev on 15 Aug 2017

👍3

Big +1. Me (and the Jupyter community) maintain the JupyterHub chart at https://github.com/jupyterhub/helm-chart. One big reason is that we'd like members of the Jupyter community to have merge rights on the chart, which doesn't work if we put the chart here.

yuvipanda on 27 Aug 2017

👍1

In the near term of months I don't think we'll have a switch made. There is the App Registry that works in a similar way to Docker Hub. Anyone looked at that, yet?

mattfarina on 14 Sep 2017

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 on 5 Jan 2018

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 on 9 Feb 2018

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

fejta-bot on 11 Mar 2018

/reopen

sylr on 15 May 2018

Definitely a good idea.

I would like to pick a few charts that make sense to my stack, clone then and keep both my changes and official changes versioned. And, of course, if any of my changes are good enough I would like to give then back to official repo.