Charts: Charts Repo Structure

[viglesiasce]

We need a plan to deal with how charts are organized within this repo. If we continue down the path we are on (folder at the top level) we will quickly end up with an unwieldy top level structure.

Examples in the wild:

1. Mesosphere universe, folder per letter
   
   
   
   • repo
     
     
     
     
     
     • packages
     
     
     
     • A
     
     
     
     • B
     
     
     
     • meta
     
     
     
   
   
2. Docker Library, subfolder and file per app
   
   
   
   • library
     
     
     
     
     
     • A
     
     
     
     • B
     
     
     
   
   

[viglesiasce]

My 2c would be to just have 1 level of indirection.

• src
  
  
  
  • mariadb
  
  
  • jenkins
  
  
• docs

Where docs is how we document best practices for creating and maintaining charts, not the documentation of the charts.

[prydonius]

Agree that 1 level (at least for now) makes sense, this is the same structure Homebrew has adopted.

[viglesiasce]

I propose a structure that removes the need to maintain 2 repos (contrib as mentioned in #40):

• stable
  
  
  
  • mariadb
  
  
  • jenkins
  
  
• contrib
  
  
  
  • etcd
  
  
  • consul
  
  

This means we can keep the same release process, same PR and CI infrastructure for both the prod ready and in development charts. For example, PRs that use alpha features can land in the contrib folder. Migrating them from contrib to stable is as simple as a PR with a git move.

[technosophos]

Yeah, I really like that structure for the reason that we can "promote" charts from one to the other, but still retain the Git history.

[michelleN]

@viglesiasce - I mentioned this thread in @kubernetes/sig-apps agenda. Feel free to comment/update us on it at the meeting or collect more thoughts around the matter. :)

[erictune]

I support putting them all in one repo, and not using the first-letter directories. I'd prefer a name other than contrib, if we can come up with one (see this comment)

[viglesiasce]

I like alpha/beta/stable but it might be a bit confusing since we are using deployments everywhere. Maybe just alpha and stable?

[michelleN]

alpha/stable might be confusing since a chart's version specification in the Chart.yaml file might also contain alpha/beta.
@erictune made a great point about "contrib" not implying the intent to grow, so I would be in favor of "incubator"

Will all charts be built with the intention of growing into being "official"? Is there a reason for a chart to be a building block and not necessarily ever be production grade?

cc/ @viglesiasce @prydonius @erictune @technosophos

[erictune]

I think stuff not trying to be production quality should not be in this repo.

The maintainers of this repo are, I assume, going to be people who are interested in production-quality charts, and who have other jobs as well. Most of them are going to want to watch all the PRs and issues in this repo so they can know what they want to comment on. Random charts that are not production quality or aspiring to production quality are going to create noise.

[viglesiasce]

I agree that we should make sure that charts here are production quality (stable) or aspiring to be (incubator). What makes a chart production quality though?

I believe as a minimum requirement you would have the ability to:

• Customize the configuration
• Persist data (only implementing emptyDir is not enough)
• Upgrade gracefully (explicit documentation at a minimum)
• Secure out of the box

That having been said each application will be different. Here are some other packaging guidelines we can co-opt ideas from:

• Fedora Packaging Guidelines
• Homebrew Acceptable Formulae
• Ubuntu Packaging Guide

Proposed directories:

• stable
  
  
  
  • mariadb
  
  
  • jenkins
  
  
• incubator
  
  
  
  • etcd
  
  
  • consul