Cannot use Input<> with ChartOpts

[pgavlin]

e.g. the outputs of another resource cannot be used to fill in a Helm chart's parameters.

[hausdorff]

This turns out to be harder than we had thought -- the values in chart.values needs to be recursively resolved expanded before it is written to some temporary file, so that the helm CLI can pick it up. Let's move to 0.18, as this will not block adoption.

[hausdorff]

Let's expand the scope of this issue to make all ChartOpts of type pulumi.Input

[hausdorff]

Let's be sure to resolve #147 as part of this.

[hausdorff]

Looking closer, this seems like it will need to involve a break to the API:

1. If values has a pulumi.Input somewhere inside, we'll need to wait for that to resolve before shelling out to the helm CLI too.
2. Since we can't shell out to helm until after all the inputs resolve, the underlying list of resources will need to become a pulumi.Output, which in turn implies that getResources will need to return a pulumi.Output as well.
3. This breaks anyone calling it, as they will have to resolve the output before they can use it.

[joeduffy]

@hausdorff Any progress on this?

[hausdorff]

After some consideration, @lukehoban and I now believe that any approach that requires any subset of ChartOpts fields to be Input<T> will break preview. We believe there is no remediation for this problem, and we believe this flaw is serious enough to not proceed with this feature.

Our reasoning:

• We need to call pulumi.output on ChartOpts before we shell out to the helm CLI in order to resolve all the values that we'd pass to the Chart.
• This implies that Chart#resources needs to be type Output<T>, since in general we have no ability to statically determine what resources will be output by helm's template expand without running it on the fully-resolved values.
• This, in turn, implies that preview could (and, we believe, very often will) generate a preview that is drastically different from what will be executed, as we are essentially generating those resources inside a call to .apply.

At the same time, we believe this issue will come up a lot, so I'll be playing around with some other ideas about how we can smooth this flow out in the near future.

I'll leave the issue open for other input.

[pgavlin]

Fixed in #241.