reqs.md

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

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

https://app.swaggerhub.com/apis/ant31/cnr-api/0.2.6

app-registry examples using curl: https://github.com/app-registry/appr/blob/master/Documentation/server/test.sh

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

• Example OCI Schema
• Docker Registry Spec

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.