KEP: Draft For Repository (targeted for KEP-15) #654
Conversation
kensipe
changed the title
keps/draft-repo.md
Outdated
|
|
||
| ### Create Repository Index | ||
|
|
||
| KUDO needs the ability to create an index file for the repository. Something like `kubectl kudo repo index new-repo --url https://kudo-repo.storage.googleapis.com`. In this example, the `kudo repo index` is the command. The `new-repo` is a folder containing operator tarballs. The index file defined in [KEP0010](keps/0010-package-manager.md) will be created using the url provided for links in the file. |
There was a problem hiding this comment.
Could the URLs be relative instead of absolute?
There was a problem hiding this comment.
seems like an implementation detail that I'm not entire sure about at this point. This kep is to capture the need to create a repo index. if we can find ways to make life easier 👍. The helm docs used as inspiration does not.
keps/draft-repo.md
Outdated
| * CLI Tooling for search, packaging, and pushing to/from repository | ||
| * Define the rules and means to promote incubated operators to the graduated repository. | ||
|
|
||
| By providing a repository (or set of repositories), KUDO will provide a mechanism for administrators to easy discover and install KUDO operators. [Helm has provided some prior art](https://github.com/helm/helm/blob/master/docs/chart_repository.md) which we should align closely to from a mental model stand point. |
There was a problem hiding this comment.
So.. while we're taking a note from Helm's book.. Helm is actually moving away from the custom chart repository model: https://blog.bacongobbler.com/post/2019-01-25-distributing-with-distribution/index.html
So they outline a number of problems with the custom chart repository model:
While there are several benefits to the Chart Repository API meeting the most basic storage requirements, a few drawbacks have started to show:
- Chart Repositories have a very hard time abstracting most of the security implementations required in a production environment. Having a standard API for authentication and authorization is very important in production scenarios
- Helm’s Chart provenance tools used for signing and verifying the integrity and origin of a chart is an after-thought of the chart publishing process
- In multi-tenant scenarios, the same chart can be uploaded by another tenant, costing twice the storage cost to store the same content. Smarter chart repositories can be designed to handle this, but it’s not a part of the spec
- Using a single index file for search, metadata information and fetching charts has made it difficult or clunky to design around in secure multi-tenant implementations.
Compared to using OCI-compatible registries for a backend:
Let’s talk about what the Distribution project brings to the table:
- A stable, battle-hardened product with many cloud vendors providing their own flavour of Distribution
- A rich set of libraries for interacting with Distribution
- A pluggable storage backend, including support for local filesystem, Azure, GCS, Aliyun OSS, AWS S3, and Openstack Swift out of the box
- A standard API for authentication/authorization
- Content stored in Distribution is content-addressable via a sha256 checksum. In other words, if two files are uploaded with identical content, only one copy of the content is stored.
So it seems like quite a bit of the work is already done for us in the OCI image format and repositories. Maybe we should explore that more?
There was a problem hiding this comment.
Oh niiiice, why haven't I seen this before!! :) Couple of thoughts:
- I think our current model is fine up until the point where we want to support people running their own registries (eg. airgaps? other use cases?) then we basically run to the same "problems" as they note there
- the downside of using repository model is that you actually have to run the repository 'application' somewhere and manage it while right now we just use hosted GCS and don't need to maintain official repo app that has to be up all the time
all and all I think we should investigate both options and probably write pros and cons to this list. Maybe we can stick with current model for now and move to that one later? (it worked for helm for quite some time) But maybe that does not make sense if we would invest a lot of time in the current model that will just get thrown away.
Also not sure what that means for the V2 deliverable next friday :)
keps/draft-repo.md
Outdated
| kubectl kudo repo index new-repo --url https://kudo-repo.storage.googleapis.com | ||
| ``` | ||
|
|
||
| ### Create Local Respository |
There was a problem hiding this comment.
this is for me out of scope for this KEP, I would remove it. It does not even address any of the goals. I think we need to put a more thought into running local/custom repositories, I would almost see that as a separate KEP
There was a problem hiding this comment.
leaving it makes sense to me... it is part of creating a repo... it is little work to support. I definitely don't see it as a separate KEP.
There was a problem hiding this comment.
I would love our keps to be very lean and something we commit to in one release iteration and I don't see this as an essential feature, just nice to have. Does not really help with Day 2 or our core business so I would postpone it and remove it but if you feel like it's very high on our roadmap 🤷♀ just keep in mind every feature mean implementing it, testing it and documenting it
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: gerred, kensipe The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
New changes are detected. LGTM label has been removed. |
Co-Authored-By: Justin Taylor-Barrick <46463088+jbarrick-mesosphere@users.noreply.github.com>
… and creating its official file name
What type of PR is this?
/kind kep
What this PR does / why we need it:
KEP for automating the repository
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?: