Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feature] cache helm YAML rendered result #935

Open
brandonkal opened this issue Dec 31, 2019 · 7 comments
Open

[feature] cache helm YAML rendered result #935

brandonkal opened this issue Dec 31, 2019 · 7 comments
Labels
area/helm area/sdk Related to the Kubernetes SDKs (nodejs, Python, etc.) customer/feedback Feedback from customers impact/performance Something is slower than expected kind/enhancement Improvements or new features mro2 Monica's list of 2st tier overlay related issues

Comments

@brandonkal
Copy link

Problem description

Helm chart index lookup, fetch, template, and rendering consumes a notable amount of time. This is especially painful when a stack has many helm charts and unrelated changes are made to the stack. I have a slow internet connection which makes this even worse.

I'd also like to be able to distribute Pulumi projects without requiring the user to install the helm 3 binary on their systems. If the rendered YAML string can be cached and stored in git, this would enable that use case as well.

Affected product version(s)

All

Suggestions for a fix

The work performed in the parseTemplate method up to and including this line:

yaml: objs.map(o => jsyaml.safeDump(o)),
can be cached to disk. This only requires improvements to the SDK. Caching can be done in cases where the inputs are known and unchanged and a chart version is specified. It can also be done across stacks, as long as the chart inputs remain the same. Pulumi can create a .pulumi-cache/helm-urn.yaml file that is used whenever possible to conserve work.

@lblackstone lblackstone added area/sdk Related to the Kubernetes SDKs (nodejs, Python, etc.) customer/feedback Feedback from customers impact/performance Something is slower than expected labels Jan 1, 2020
@lblackstone lblackstone self-assigned this Jan 1, 2020
@brandonkal
Copy link
Author

Another thought: If the helm chart happens to generate things that pulumi considers to be secrets, pulumi may wish to ensure they are encrypted before writing anything to disk. Or perhaps just using a single key to encrypt the whole file.

@Place1
Copy link

Place1 commented Apr 1, 2020

Maybe a stepping stone could be to cache the helm chart's .tgz locally. That would at least allow repeat runs to be sped up without Pulumi needing to solve the "save a secret" problem highlighted above.

Some of my stacks end up downloading 10+ charts per run making pulumi very sluggish.

@Place1
Copy link

Place1 commented Apr 1, 2020

I actually just ran a test. I implemented a little local cache for the chart's i'm using. My preview time went from 103 seconds to 37 seconds.

My test project uses 14 helm charts

I cached the charts by downloading/untar'ing them to a directory and then using Pulumi Helm's path option to use the local chart.

@Bazze
Copy link

Bazze commented Feb 5, 2021

This would be a well needed addition. Overtime we tend to use a lot of helm charts and our Pulumi programs are just getting slower and slower 😅 I'm just waiting for the day when one of the Helm charts won't longer be public available on the internet – then a copy of the helm chart under version control would be a great saviour.

@viveklak
Copy link
Contributor

As mentioned in #1504, this may also help in case of network issues.

@lukehoban lukehoban added the kind/enhancement Improvements or new features label May 2, 2021
@raelix
Copy link
Contributor

raelix commented Feb 1, 2023

Would be better at least if we could have the ability of downloading the charts in parallel. Is there any way to achieve this? I have to install more than 100 charts so this becomes really slow...

@mnlumi mnlumi added the mro2 Monica's list of 2st tier overlay related issues label Mar 28, 2023
@lblackstone lblackstone removed their assignment Jul 14, 2023
@EronWright
Copy link
Contributor

There's a lot of good suggestions in the above discussion, here's a recap:

  1. Parallelism - in some SDKs, the charts are downloaded sequentially. I believe this will be addressed with Chart v4 because MLCs are constructed in parallel.
  2. Helm binary - fortunately there's no need to have the helm tool because Pulumi now uses Helm as a library.
  3. Chart caching - see: HIP for download cache (charts & provenance files)  helm/community#185

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/helm area/sdk Related to the Kubernetes SDKs (nodejs, Python, etc.) customer/feedback Feedback from customers impact/performance Something is slower than expected kind/enhancement Improvements or new features mro2 Monica's list of 2st tier overlay related issues
Projects
None yet
Development

No branches or pull requests

9 participants