Add RFC about helm chart repository #4
Conversation
Signed-off-by: Flavio Castelli <[email protected]>
| **TODO:** is this possible? I mean having a SR that includes packages from one | ||
| project (the devel prj of charts) and another one (the prj where the image | ||
| referenced by the new chart is built). | ||
|
|
There was a problem hiding this comment.
SRs/MRs have one source project. However, multiple SR/MR can be merged into the same incident/staging project. This requires coordination between the maintainers of the image and the maintainers of the packages. Actually in all cases the image needs to be submitted, so the coordination is always needed.
When you add a new helm chart pattern, the image won't build unless this packages is available. Thus packages should be "visible" from the project where we build the image since the beginning.
I think packages containing helm charts should live in the same project as the image which will contain them. This can be a bottleneck, I know, but other solutions like using links or aggregates or adding extra paths to the project, can be a mess.
If we did that, having the packages and the images in the same repo, then submitting them all together would be easy.
There was a problem hiding this comment.
+1 on storing the helm chart with the project (Dockerfile) on github. Unless you meant OBS?
| ### Concerns and Unresolved Questions | ||
|
|
||
| > List any concerns, unknowns, and generally unresolved questions etc. | ||
|
|
There was a problem hiding this comment.
When we get into the implementation of such things, we always struggle with the tagging of the images. For example, helm charts may contain "image: foo:abcd1234" but then the image gets rebuild and the tag does not work anymore. I think we should consider this case. This is a general issue with the images and we already have this problem, so this document may not be the place for the solution, but I think is worth mentioning it that this needs to be addressed.
| What should happen to the tag of the image? How can we prevent existing helm chart to become broken or even worse obsolete (as in pointing to an outdated and vulnerable image). | ||
|
|
||
| This problem is out of the scope of this RFC. We will elaborate on it inside of another RFC (probably the same one mentioned above). | ||
|
|
There was a problem hiding this comment.
:) . Sorry I wrote the previous comment before reading this ...
|
Maybe this is a silly question - but will be all of the helm charts in the registry be signed with a SUSE key? How will this signing process work? How will customers be sure they're only running the signed charts from the SUSE registry? A less silly question - I assume we will implementing this for openSUSE Kubic first? |
This is something we should do in the future by using helm provenance files. I mentioned them, but this is out of the scope of this RFC.
This whole RFC is about providing a way to have offline copy of a custom helm chart repository. Is this something relevant also for the openSUSE Kubic project? What we describe here can be replicated on openSUSE Kubic (in fact @davidcassany made a POC using tumbleweed as base OS of the container image), but we don't even have a openSUSE helm chart repository. I think we shouldn't even have it, but rather contribute to the official upstream helm cart one (like it's being done for the Portus helm chart). |
That seems, dangerous.. I do not like the potential implications of customers downloading unsigned helm charts. Has anyone considered the potential security and reputational risks involved?
Why wouldn't it be? You need it for CaaSP, and in the same way openSUSE utilises many of the same tools and processes as SUSE in order to be able to be a test bed and incubator for SUSE, I'd need to understand why this doesn't apply to helm charts before agreeing to make an exception here. I think the natural place for considering this feature would be Kubic first, rather than assuming that it is only relevant to SUSE CaaS Platform. We should be striving for feature parity between CaaSP and Kubic, then pushing for Kubic to extend that..not limiting the scope of Kubic. |
| * Provide an offline copy of the SUSE chart repository to be used by customers | ||
| installing our products into air gapped environments. That includes providing a way to integrate with mirrored registries | ||
| * Ensure the workflow fits within the requirements of the SUSE Maintenance, Maintenance QA and security teams. | ||
| * Have reference copies of supported upstream charts that are working with SUSE CaaS |
| inside of the on-premise container registry of our customers, like it happens | ||
| with all the other images we are shipping. | ||
|
|
||
| Customers operating inside of an air-gapped environment will have to: |
There was a problem hiding this comment.
Agreed, and ChartMuseum can do all of this for us. We should revisit the build process for this container.
| The above command mounts the charts directory from the host into the container | ||
| using the read-only mode. Then it starts ChartMuseum with the following flags: | ||
|
|
||
| * `--disable-api`: all the write operations (create, update, delete) are |
| * `--storage` and `--storage-local-rootdir`: all the charts are stored on the | ||
| local filesystem and are inside of the `/charts` directory. | ||
|
|
||
| The `index.yaml` file can be obtained by executing: `curl http://localhost:4000`. |
There was a problem hiding this comment.
Remove this instruction as it is not needed. Unless this is meant as a learning step?
|
|
||
| The SUSE chart repository available at [kubernetes-charts](https://kubernetes-charts.suse.com) | ||
| is going to be shipped inside of an image called | ||
| `registry.suse.com/suse/kubernetes-charts` (again, the name is just an example |
| * `/usr/share/suse/kubernetes-charts/cf-2.0.2.tgz` | ||
| * `/usr/share/suse/kubernetes-charts/cf-2.10.1.tgz` | ||
|
|
||
| In the future each chart RPM should also provide the `.tgz.prov` provenance files. However this RFC doesn't want to cover the problem of creating these signed files (currently they are missing also from *”kubernetes-charts.suse.com”*). |
There was a problem hiding this comment.
** Agreed with others that this is something we should address up front. It is not the most straight forward process but it is just GPG under the hood.
|
|
||
| The OBS project would include also the definition of the `registry.suse.com/suse/kubernetes-charts` container image. | ||
|
|
||
| This image would take the ChartMuseum image maintained by the SUSE CaaS Platform |
There was a problem hiding this comment.
Why do we need 2 CM builds, rather than have one kiwi project that can pull in multiple dependencies?
| **TODO:** is this possible? I mean having a SR that includes packages from one | ||
| project (the devel prj of charts) and another one (the prj where the image | ||
| referenced by the new chart is built). | ||
|
|
There was a problem hiding this comment.
+1 on storing the helm chart with the project (Dockerfile) on github. Unless you meant OBS?
|
|
||
| The SUSE Customer Center team is currently maintaining the hosted version of the SUSE chart repository. | ||
|
|
||
| This is currently implemented by exposing the contents of a S3 bucket. The S3 bucket contains all the `.tgz` files and the `index.yaml` that make the repository. The helm chart creation, the index generation and the upload to S3 is currently automated via a concourse pipeline described [here](https://github.com/SUSE/cloudfoundry/wiki/Building-SUSE-Cloud-Application-Platform#publishing-to-the-helm-repository-httpskubernetes-chartssusecom). |
| ### Concerns and Unresolved Questions | ||
|
|
||
| > List any concerns, unknowns, and generally unresolved questions etc. | ||
|
|
Proposal about helm chart repository.
Rendered version available here