Fix HELM_HOME handling for v3 #1076

lblackstone · 2020-04-17T20:37:15Z

Proposed changes

Helm v3 removed the --home parameter, but still supports the HELM_HOME env var for backward compatibility. Pass ambient env vars to the helm binary so this works properly.

TODO:

NodeJS
Python
C#

Related issues (optional)

Fix #1070

sdk/dotnet/Helm/ChartBase.cs

sdk/dotnet/Utilities.cs

mikhailshilkov · 2020-04-20T20:43:50Z

sdk/nodejs/helm/v2/helm.ts

        if (opts.devel === true)            { flags.push(`--devel`);                                           }
        if (opts.prov === true)             { flags.push(`--prov`);                                            }
        if (opts.verify === true)           { flags.push(`--verify`);                                          }
    }
-    execSync(`helm fetch ${shell.quote([chart])} ${flags.join(" ")}`);
+    execSync(`helm fetch ${shell.quote([chart])} ${flags.join(" ")}`, { env });


Are we sure we want to pass all env variables as opposed to passing HELM_HOME specifically? Is there a combination of env variables that would change the behavior of helm between two Pulumi versions, and therefore break somebody?

I suppose it's possible. The advantage of passing everything is that it makes it easier for users to configure Helm behavior without requiring us to change code, but maybe it would be better to limit the change here.

The default for execSync was to pass process.env down to the subprocess. So I think we should keep that behaviour by default (and add HELM_HOME).

Indeed! The same applies to .NET, actually, if I read the docs correctly. Therefore, we can simplify the PR and not retrieve/pass env variables, only add HELM_HOME if needed.

@lukehoban This comment indicates that setting env only sets the passed values, which is why I copied process.env explicitly.

@lblackstone That makes sense to me. I think we don't need to retrieve/pass them for .NET - just add the extra one.

sdk/nodejs/helm/v2/helm.ts

lblackstone · 2020-04-20T23:32:09Z

@mikhailshilkov Any idea on this error?

[              helm-api-versions ]   kubernetes:helm.sh:Chart (api-versions):
[              helm-api-versions ]     error: Pulumi.ResourceException: Value does not fall within the expected range.
[              helm-api-versions ]        at Pulumi.Kubernetes.Helm.ChartBase.<>c__DisplayClass0_0.<.ctor>b__1(ValueTuple`2 values)
[              helm-api-versions ]        at Pulumi.Output`1.ApplyHelperAsync[U](Task`1 dataTask, Func`2 func)
[              helm-api-versions ]        at Pulumi.Output`1.Pulumi.IOutput.GetDataAsync()
[              helm-api-versions ]        at Pulumi.Serialization.Serializer.SerializeAsync(String ctx, Object prop)
[              helm-api-versions ]        at Pulumi.Deployment.SerializeFilteredPropertiesAsync(String label, IDictionary`2 args, Predicate`1 acceptKey)
[              helm-api-versions ]        at Pulumi.Deployment.SerializeAllPropertiesAsync(String label, IDictionary`2 args)
[              helm-api-versions ]        at Pulumi.Deployment.RegisterResourceOutputsAsync(Resource resource, Output`1 outputs)
[              helm-api-versions ]        at Pulumi.Deployment.Runner.WhileRunningAsync()

lukehoban · 2020-04-21T00:02:26Z

provider/pkg/gen/nodejs-templates/helm/v2/helm.ts

                const yamlStream = execSync(
                    cmd,
                    {
+                        env: {...process.env},


Isn't this the default already?

lukehoban · 2020-04-21T00:04:38Z

sdk/nodejs/helm/v2/helm.ts

        if (opts.devel === true)            { flags.push(`--devel`);                                           }
        if (opts.prov === true)             { flags.push(`--prov`);                                            }
        if (opts.verify === true)           { flags.push(`--verify`);                                          }
    }
-    execSync(`helm fetch ${shell.quote([chart])} ${flags.join(" ")}`);
+    execSync(`helm fetch ${shell.quote([chart])} ${flags.join(" ")}`, { env });


The default for execSync was to pass process.env down to the subprocess. So I think we should keep that behaviour by default (and add HELM_HOME).

mikhailshilkov · 2020-04-21T07:54:45Z

@lblackstone

Any idea on this error?

Hmm, I suspect we screwed up environment variables related to paths somehows. I think we should revert to not passing all the env variables explicitly and only pass HELM_HOME in addition to the ambient defaults - and I think the error will be gone.

lukehoban

Do we have any way to test this?

The changes look good to me - but there is enough subtlety here that it would be great if we could lock this in with test coverage.

lblackstone · 2020-04-21T23:00:15Z

Do we have any way to test this?

I specified the home option on a test Chart for each SDK. This should be a no-op if things are working, and fail in current master if the helm v3 binary is used.

lblackstone requested a review from mikhailshilkov April 17, 2020 22:40

lblackstone marked this pull request as ready for review April 17, 2020 22:41

lblackstone commented Apr 20, 2020

View reviewed changes

sdk/dotnet/Helm/ChartBase.cs Outdated Show resolved Hide resolved

mikhailshilkov reviewed Apr 20, 2020

View reviewed changes

lukehoban reviewed Apr 21, 2020

View reviewed changes

lblackstone added 5 commits April 21, 2020 12:33

Fix HELM_HOME handling for v3

4f8315d

Fix python support

aa3919a

Fix .NET

f2cb48a

Address feedback

a31ad44

Update env var handling

326e6a1

lblackstone force-pushed the lblackstone/fix-helm-home branch from a1a9b86 to 326e6a1 Compare April 21, 2020 18:33

Regen SDKs

c81e25e

lblackstone requested review from lukehoban and mikhailshilkov April 21, 2020 21:46

lukehoban approved these changes Apr 21, 2020

View reviewed changes

Add tests

4b60f19

lblackstone merged commit e83039f into master Apr 22, 2020

pulumi-bot deleted the lblackstone/fix-helm-home branch April 22, 2020 14:42

renovate bot mentioned this pull request Jun 6, 2021

chore(deps): update dependency @pulumi/kubernetes to v3 marcus-sa/pulumi-kubernetes-istio#61

Open

1 task

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix HELM_HOME handling for v3 #1076

Fix HELM_HOME handling for v3 #1076

lblackstone commented Apr 17, 2020 •

edited

Loading

mikhailshilkov Apr 20, 2020

lblackstone Apr 20, 2020

lukehoban Apr 21, 2020

mikhailshilkov Apr 21, 2020

lblackstone Apr 21, 2020

mikhailshilkov Apr 21, 2020

lblackstone commented Apr 20, 2020

lukehoban Apr 21, 2020

lukehoban Apr 21, 2020

mikhailshilkov commented Apr 21, 2020

lukehoban left a comment

lblackstone commented Apr 21, 2020

Fix HELM_HOME handling for v3 #1076

Fix HELM_HOME handling for v3 #1076

Conversation

lblackstone commented Apr 17, 2020 • edited Loading

Proposed changes

Related issues (optional)

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lblackstone commented Apr 20, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mikhailshilkov commented Apr 21, 2020

lukehoban left a comment

Choose a reason for hiding this comment

lblackstone commented Apr 21, 2020

lblackstone commented Apr 17, 2020 •

edited

Loading