community
community copied to clipboard
HIP for download cache (charts & provenance files)
This is a proposal for adding a download-cache for helm charts and provenance files to helm.
Co-authored-by: Matt Farina [email protected] Signed-off-by: Matt Farina [email protected]
Maybe not for this iteration, but what about storing chart in a configmap and using that first? This would allow a shared cache that could be used by CD systems as well as by multiple users or even the same user on multiple machines.
@joejulian Then there is no advantage for admins maintaining multiple clusters at once.
@bacongobbler I think I missed that this wasn't in there. The gist is that there is a provenance cache as well. It is separate but follows the same patterns. Since provenance files contain the chart archive hash there is a complete coupling of a provenance file to a specific archive.
If it helps, we have already been working on an implementation. You can find a provenance cache commit here.
We will update the HIP to account for this.
@joejulian That is an interesting idea. There are a couple reasons I would not want to do it...
- How would it work with
helm templateand other commands specifically designed to work without being connected to a cluster. Not connecting to a cluster is part of the security model for some commands. The cache wouldn't work there. The UX would also not work as a cache in a cluster for these commands would mean needing to make sure you were pointed at the right cluster before running the commands or risk polluting another clusters cache. If you were pointed at a cluster for an open source project and runninghelm templatefor a company project you could even risk leaking some company details. We wouldn't want that either. - A cache provides a performance boost when performing operations. Checking and pulling from a k8s cluster would go over a network and still need to download something. We would need to look at the performance difference of a Helm repository vs a k8s cluster. When both are handled over HTTP. For many cases, the cache won't be a performance boost. Something on local disk would be because it skips all the network traffic.
This is a cache rather than a common store.
Thoughts?
Is there an update coming on this? I talked with @mattfarina about some mitigations that would basically address my concerns, and I'm pretty interested in accepting this HIP if the mitigations land in the doc.
Are there any recent updates on this?
Any chance work can be continued on this?
It makes me developer-waiting-to-work-sad to see:
- Running
helm dependency updateon umbrella charts download the same chart multiple times (because multiple Chart.yaml dependencies point to it) - Next time
helm dependency updateis run the cachedtgzfile in thechartsfolder is not used, and the charts are downloaded again.
I know - and even myself - we all hate bumps, but it's been another year and there are still a lot of people hoping to see this in the wild <3