You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our organization uses a Helm chart to deploy and configure our services in production environments, and currently, we are in the process of converting Garden to use that chart for development environments as well. What we're aiming to do is to set up Garden modules to deploy individual services, but have run into a problem with using the same chart across multiple modules.
Each Helm Deploy action will always run a helm dependency update when deploying, which causes a conflict when parallel modules compete over the tmpcharts directory. That directory is used by Helm to download the dependent charts before copying them over to the proper charts directory. This conflict over the tmpcharts directory can cause deploys to fail if one module cleans up the directory while another is running.
Error: open /Users/username/org/repo/charts/mychart/tmpcharts: no such file or directory
Some workarounds are:
Add a dependency chain in Garden to deploy each module one at a time
Separate each service into an individual chart
But neither of those options will scale with a larger number of services.
Since the dependencies can be updated manually or already be present in the chart, it is not necessary to always run the helm dependency update and therefore should be an option in the Garden Helm Deploy action. This could also default to true to not change the behavior for existing modules.
What should the user be able to do?
Specify a boolean value in the Helm Deploy action to disable dependency update.
Why do they want to do this? What problem does it solve?
Allow parallel Helm Deploy actions to deploy using the same chart without conflicts.
When false, the dependency update that occurs here would be skipped, and also the --dependency-update argument would be omitted from the render template function here.
How important is this feature for you/your team?
🌵 Not having this feature makes using Garden painful
The text was updated successfully, but these errors were encountered:
Feature Request
Background / Motivation
Our organization uses a Helm chart to deploy and configure our services in production environments, and currently, we are in the process of converting Garden to use that chart for development environments as well. What we're aiming to do is to set up Garden modules to deploy individual services, but have run into a problem with using the same chart across multiple modules.
Each Helm Deploy action will always run a
helm dependency update
when deploying, which causes a conflict when parallel modules compete over thetmpcharts
directory. That directory is used by Helm to download the dependent charts before copying them over to the propercharts
directory. This conflict over thetmpcharts
directory can cause deploys to fail if one module cleans up the directory while another is running.Some workarounds are:
But neither of those options will scale with a larger number of services.
Since the dependencies can be updated manually or already be present in the chart, it is not necessary to always run the
helm dependency update
and therefore should be an option in the Garden Helm Deploy action. This could also default to true to not change the behavior for existing modules.What should the user be able to do?
Specify a boolean value in the Helm Deploy action to disable dependency update.
Why do they want to do this? What problem does it solve?
Allow parallel Helm Deploy actions to deploy using the same chart without conflicts.
Suggested Implementation(s)
Add a value for disabling update of dependencies:
When false, the dependency update that occurs here would be skipped, and also the
--dependency-update
argument would be omitted from the render template function here.How important is this feature for you/your team?
🌵 Not having this feature makes using Garden painful
The text was updated successfully, but these errors were encountered: