getporter
Helm/Porter issue: modifying charts in order to achieve copy/archive support defeats drop-in artifact goals
Hey all.
I am creating a bundle that can deploy porter online but be copyable and moveable. But we currently see to have to modify the helm chart to use digests rather than tags. I would think that, at build time, we could pull the tags to resolve to digests, but that's not what we do. (I'm sure for a good reason.)
If modifying the chart to support digests is required to move a chart offline -- in this case, it requires me to modify the official rudr chart merely to create a bundle and/or push that modification into a tree that I don't own and maybe doesn't want to do it that way. (Although I also guess that's a great scenario for relocation as well.)
On the one hand, copying and offline support are niche environments. On the other, too many hurdles restrict usage, which restricts its value to the world as well. What do we think here?
Hey @squillace I did a little digging/experimenting.
This isn't really an issue specific to Helm. It's really an artifact of how CNAB (the spec) and cnab-to-oci are handling the images. Since CNAB is in the business of immutability, it's dealing with digests. Let's consider the following porter.yaml context:
name: spring-music
version: 0.6.0
description: "Run the Spring Music Service on Kubernetes and Digital Ocean PostgreSQL"
invocationImage: jeremyrickard/porter-do:v0.6.0
tag: jeremyrickard/porter-do-bundle:v0.6.0
images:
spring-music:
description: "Spring Music Example"
imageType: "docker"
repository: "jeremyrickard/spring-music"
tag: "v1.0.0"
#digest: "sha256:8f1133d81f1b078c865cdb11d17d1ff15f55c449d3eecca50190eed0f5e5e26f"
This ends up giving us the following relocation mapping:
"jeremyrickard/porter-do:v0.6.0":"jeremyrickard/porter-do-bundle@sha256:da879273203b36b60b10590a66b791f5484e5353486de74e3cd2f6d1cf2ff7f5","jeremyrickard/spring-music:v1.0.0":"jeremyrickard/porter-do-bundle@sha256:8f1133d81f1b078c865cdb11d17d1ff15f55c449d3eecca50190eed0f5e5e26f"}
So if we are specifying the non-digested form, we still get the digested form in the relocation mapping. cnab-to-oci relocates these images by default, so it will always get moved. This isn't really a HELM thing as I mentioned, it's a "cnab bundles relocate stuff and deal in immutable references" thing. The best practice is to copy the chart into your bundle source anyway...not rely on one on the interwebs. Is modifying it after you've copied it into the bundle that much worse?
Good response. OK, here I am, creating a bundle out of a repo that I don't own (oamdev/rudr). I do not want to create a bundle based on copying over that section of charts from a very large repo (thus being out of synch and not easily synched with git). Instead, I want to build a local version inside that local clone, which gives me the ability to stash a commit/branch and always be able to git diff to track differences as the project goes forward. (This is my mental world.)
Now, my real desire is to have things be easy. So it's not that modifying the chart can't be done. It can. AND I can use git to diff as the project moves forward. But now I have to master how helm charts work/manifests before I can use Porter, a tool that I want to help me (while we can expect that bundle authors do need to have some knowledge, they should not have to be total fullstack experts I don't think). So I expect, somehow, that when I want to use a tag, above, I'd hope that the tool would grab the digest (as it does, above) and both a) capture that digest as it does but also b) add the same tag to the image upon relocation so that the chart can in both cases use the same chart but the tooling does in fact track the digests as it should.
This is NOT a time-sensitive thing, but rather an exercise in understanding where the tooling can achieve more for us rather than pushing off specific work on the users. At the moment, we are capturing and using the tag (the most common chart/manifest method) and converting that to the digest and thence to the digest usage. What I'm asking is whether we can -- totes ignorant here -- capture the original tag and smuggle it through and add it to the image so that whether the digest or tag is used in the chart/manifest, it will work.
If I explain myself well, then if it could work, I don't care when that can happen -- it's not a blocker now at all. let's just log the issue. if I misunderstand and we can't do that, then no problem. Let's just get specific and doc and example that shows how a manifest or helm chart must be modified or built in order to enable both online and offline usage (helm is easier; possibly manifests can't do one OR the other and must be modified to use digests).
Now, do I understand at all? It's entirely possible that I don't. :-)
This now just needs a doc. Either you can't do both easily, but more likely you have specific bundles for specific things as a best practice. You don't build an uber-bundle that is the switchblade of setups.
This has been documented in our airgap example and in the image doc.
We really need a concept (no task or example) document that explains airgaps and quirks/best practices like this.
They need to edit the chart to support digests vs tags but don't own the chart
The best practice is to copy the chart into your bundle source anyway.
The issue tracking automating the tag -> digest resolution is https://github.com/getporter/porter/issues/1357