Helm Release shows resourceNames diff on pulumi up -r even though at the end no changes are made.

[MitchellGerdisch]

What happened?

Using the code provided below, running pulumi up -r will indicate changes to the resourceNames even though nothing has changed. And at the end of the update it'll indicate there were no changes.

If you use repository args to point at repo URL or a local tgz file, the problem goes away.

Maybe a dupe of https://github.com/pulumi/pulumi-kubernetes/issues/2573 But it seemed different enough to be worthy of a separate issue.

Example

/*  Test sequence
    Test 1:
        Make sure the "Test 1" block is UNCOMMENTED and the "Test 2" block is COMMENTED below.
        Run `helm repo add bitnami https://charts.bitnami.com/bitnami`
        Run `pulumi up -r -y` a couple/few times and convince yourself there is no escaping the falsely reported Resource name diffs.

        Run `pulumi refresh` a few times and note that it shows no changes.
        Run `pulumi up -y` a few times and note that it shows no changes.

    Test 2:
        Make sure the "Test 2" block is UNCOMMENTED and the "Test 1" block is COMMENTED below.
        Run `pulumi up -r -y` a couple of times to convince yourself it's nice and quiet and not reporting any diffs, etc.
*/

package main

import (
    helm "github.com/pulumi/pulumi-kubernetes/sdk/v4/go/kubernetes/helm/v3"
    "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

func main() {
    pulumi.Run(func(ctx *pulumi.Context) error {

            _, err := helm.NewRelease(ctx, "bijou-bijou", &helm.ReleaseArgs{
                Name: pulumi.StringPtr("bijou"),
                Namespace: pulumi.String("bijou"),

                // Run: helm repo add bitnami https://charts.bitnami.com/bitnami
                // Test 1 Block begin
                Chart: pulumi.String("bitnami/nginx"),
                // Test 1 Block end

                // Test 2 Block begin
                /*
                Chart: pulumi.String("nginx"),
                RepositoryOpts: helm.RepositoryOptsArgs{
                    Repo: pulumi.String("https://charts.bitnami.com/bitnami"),
                },
                */
                // Test 2 Block end

                Version: pulumi.StringPtr("15.3.0"),
                CreateNamespace: pulumi.BoolPtr(true),
                CleanupOnFail: pulumi.BoolPtr(true),
            })
            if err != nil {
                return err
            }

        return nil
    })
}

Output of pulumi about

CLI
Version 3.85.0 Go Version go1.21.1 Go Compiler gc

Plugins NAME VERSION go unknown kubernetes 4.2.0

Host
OS darwin Version 13.5 Arch x86_64

This project is written in go: executable='/usr/local/bin/go' version='go version go1.20.5 darwin/amd64'

Found no pending operations associated with dev

Backend
Name pulumi.com

Dependencies: NAME VERSION github.com/pulumi/pulumi-kubernetes/sdk/v4 4.2.0 github.com/pulumi/pulumi/sdk/v3 3.84.0

Additional context

No response

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).

[rquitales]

Thanks for reporting this UX issue. Yes, as you've identified, specifying the Helm repository within the Pulumi program, vs looking it up against locally added repositories will result in a diff, despite there being functionally no difference in the final charts. This issue is similar to #2573, but triggered in a different manner. I believe with @EronWright's latest additions to calculate checksums of charts, we could use that to improve diffing.

[EronWright]

@MitchellGerdisch my understanding of this report is that the "test 1" variation will continually produce a diff, and that you provided a "test 2" variant to show how the issue seems related to absence of repositoryOpts. There's definitely a bug, and here's my analysis so far:

When the system is evaluating the resource inputs (such as chart and repositoryOpts), it uses helm template to render the charts locally, to calculate the resourceNames and checksum properties. Later, it uses helm install. Turns out that the handling of the inputs is deficient in the helm template step and is unable to use locally-configured Helm repositories. The resultant error is suppressed and simply yields an (erroneous) diff.

I'm working on a fix.

[EronWright]

@MitchellGerdisch could you re-test with the latest version of the provider, and let us know if the fix was effective for you?