Open L3n41c opened 1 year ago
kpitzen
commented
1 year ago Hi @L3n41c - I appreciate you not only opening this issue, but a corresponding PR as well! Engagement like this really makes my day. Looking forward to seeing the test results!
rquitales
commented
1 year ago Thanks for submitting #2410! I still think we may need one more PR to fully address this issue.
Consider a potential user journey where the local adjacent folder (eg datadog) also contains a Chart.yaml. The logic change in #2410 would still have Pulumi use the local folder rather than fetching it from the remote repository URL. If RepositoryOpts.Repo is specified explicitly, then I think it makes sense to always fetch the remote chart. We should also add some test cases to ensure this occurs.
EronWright
commented
1 year ago Folks, I am re-opening this issue to have a conversation about an unforeseen consequence, which is that Pulumi's behavior has diverged from that of Helm. The behavior of helm install is to prefer the local chart, without the fancy detection logic that was subsequently added. For example:
❯ mkdir metallb
❯ helm install metallb metallb -n metallb-system --dry-run --repo https://metallb.github.io/metallb
Error: INSTALLATION FAILED: Chart.yaml file is missingPulumi has a forked copy of the locateChart function, that was forked for an unrelated reason that has since been fixed (https://github.com/helm/helm/commit/9f199b6517c21394bca555983c70fc232d65014c). It would be nice to cleanup the forked code and to have consistent behavior between Helm and Pulumi. Thoughts?
EronWright
commented
3 weeks ago @rquitales are you supportive of re-aligning pulumi's behavior with that of the Helm CLI?
rquitales
commented
3 weeks ago @EronWright Yes, I think that's the right move as to not surprise any users expecting Helm behaviour.
What happened?
We try to create a new Helm release from a remote chart with:
We use
RepositoryOpts.Repoto indicate that the chart is to be fetched from a remote registry.We get the following error:
If we increase the log level, we can see that the
datadogchart is looked locally instead of on the remote registry:This is caused by the fact that the current working directory contains a subdirectory which has exactly the same name as the chart we want to create. In this case, Helm tries to leverage the local directory instead of honoring the
RepositoryOpts.Repoparameter.Expected Behavior
Have helm fetch the remote chart from the registry.
Steps to reproduce
Try to create a Helm Release with
helm.NewReleasewith aRepositoryOpts.Repoparameter to specify the URL of the remote registry and create a folder inside the working directory with the same name as the chart.Output of
pulumi aboutAdditional context
If the current working directory subdirectory named with the same name as the chart is renamed to something different, the error goes away.
Contributing
Vote on this issue by adding a 👍 reaction. To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).