community icon indicating copy to clipboard operation
community copied to clipboard

HIP for download cache (charts & provenance files)

Open dragonchaser opened this issue 4 years ago • 8 comments

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]

dragonchaser avatar May 07 '21 14:05 dragonchaser

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 avatar May 13 '21 16:05 joejulian

@joejulian Then there is no advantage for admins maintaining multiple clusters at once.

dragonchaser avatar May 17 '21 07:05 dragonchaser

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

mattfarina avatar Jun 02 '21 13:06 mattfarina

@joejulian That is an interesting idea. There are a couple reasons I would not want to do it...

  1. How would it work with helm template and 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 running helm template for a company project you could even risk leaking some company details. We wouldn't want that either.
  2. 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?

mattfarina avatar Jun 02 '21 13:06 mattfarina

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.

technosophos avatar Sep 16 '21 17:09 technosophos

Are there any recent updates on this?

annaagaf avatar Oct 06 '22 12:10 annaagaf

Any chance work can be continued on this?

It makes me developer-waiting-to-work-sad to see:

  • Running helm dependency update on umbrella charts download the same chart multiple times (because multiple Chart.yaml dependencies point to it)
  • Next time helm dependency update is run the cached tgz file in the charts folder is not used, and the charts are downloaded again.

Andrioden avatar May 03 '23 18:05 Andrioden

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

MaxWinterstein avatar May 08 '24 09:05 MaxWinterstein