Skip to content

Instantly share code, notes, and snippets.

@mattfarina
Last active October 10, 2017 17:11
Show Gist options
  • Save mattfarina/9f9ebe1171943e873576c0ea3e6f4f30 to your computer and use it in GitHub Desktop.
Save mattfarina/9f9ebe1171943e873576c0ea3e6f4f30 to your computer and use it in GitHub Desktop.

Hosted Chart Repository Requirements

Background

Kubernetes Helm has the ability to work with remotely hosted Charts. While charts can be seen in the community provided charts, the charts themselves can be privately or separately hosted for an organization or individual.

There are currently 3 major ways to host your own chart repository:

  • Helm provides a means to generate a chart repository that can be hosted on a web server, object storage, or via a similar setup.
  • App Registry provides a system, similar to the handling of Docker images, to store charts. In this setup one can push or pull charts in a similar way to container images. There is a spec and Quay, the image hosting service, has implemented it. For Helm to interact with this API a plugin is required.
  • Recently, ChartMuseum came into existance. ChartMuseum provides an API to push charts into a system that then leverages the out of the box APIs Helm works with.

Requirements

This document looks to capture requirements for what a chart repository needs to include with details to help an implementor. A good requirement can be implemented by more than one different system. This is not looking to caputure how the system should work but rather what it should include.

  1. The ability to programatically retrieve a chart version
  2. The ability to search all charts and versions accessible by a user
  3. The ability to programatically add a new chart version to a repository
  4. Ability to mark a chart release as deprecated
  5. A method to have private charts tied to a user (Users and Organizations)
  6. A method to have private charts for a group (e.g., team or company) (Users and Organizations)
  7. A method to enable automation (e.g., bots) to operate on charts in place of a user (Users and Organization)
  8. A method to verify the integrity of a chart (Security and Auditing)
  9. Ability to mark a chart release as having a known security issue (Security and Auditing)
  10. A method to retrieve details on chart security releases (Security and Auditing)
  11. Logging of who performed CRUD charts and versions (Security and Auditing)
  12. A method for compatibility with N and N-1 versions of Helm, once Helm 3 is release
@ant31
Copy link

ant31 commented Oct 9, 2017

  • Agnostic to the content-format but uses a well-defined metadata spec to describe a package and limited to content that resolve into kubernetes resources.

@scottrigby
Copy link

@ant31
Copy link

ant31 commented Oct 9, 2017

@jzelinskie
Copy link

For reference, this is what inspired App Registry, but not how it works:

@prydonius
Copy link

Do we have a specific goal for this effort? This looks like a great set of requirements to look at when we discuss the repository model for Helm 3, but it's not clear to me whether the idea is to take this and start working on converging App Registry and Chart Museum to a single spec or start working on something new.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment