Pulumi import by passing json file is failing

[yogeshghotekar]

What happened?

I am trying to import resource define in json file to pulumi but is failing to import the helm charts
This started failing on pulumi-kubernetes provider v4.3.0 It works fine with v4.2.0

Example

To reproduce this issue. You can create resources in json file. In my case I am creating this resource json file from my terraform deployed resources and then trying to import it in pulumi.

json file

{
    "nameTable": {
        "edge": "urn:pulumi:production::deployer::myinfra:deployer:Cluster::edge",
        "edge-provider": "urn:pulumi:production::deployer::pulumi:providers:kubernetes::edge"
    },
    "resources": [
       {
            "name": "edge/metallb-system",
            "type": "kubernetes:core/v1:Namespace",
            "id": "metallb-system",
            "parent": "edge",
            "provider": "edge-provider"
        },
		{
            "name": "edge/metallb-system/my-secret",
            "type": "kubernetes:core/v1:Secret",
            "id": "metallb-system/my-secret",
            "parent": "edge",
            "provider": "edge-provider"
        },
        {
            "name": "edge/metallb-system/metallb",
            "type": "kubernetes:helm.sh/v3:Release",
            "id": "metallb-system/metallb",
            "parent": "edge",
            "provider": "edge-provider"
        }
    ]
}

my resource creation code

release, err := helmv3.NewRelease(ctx, fmt.Sprintf("%s/%s/%s", clusterName, helmRelease.Namespace, helmRelease.Name),
                &helmv3.ReleaseArgs{
                    Name:            pulumi.String("metallb"),
                    Chart:           pulumi.String("metallb-system/metallb"),
                    Namespace:       pulumi.StringPtr("metallb-system"),
                    CreateNamespace: pulumi.BoolPtr(true),
                    WaitForJobs:     pulumi.BoolPtr(true),
                    SkipAwait:       pulumi.BoolPtr(false),
                    CleanupOnFail:   pulumi.BoolPtr(true),
                    Atomic:          pulumi.BoolPtr(false),
                    Version:         pulumi.StringPtr("1.18.0"),
                    Timeout:         pulumi.IntPtr(900),
                    Values:          pulumi.ToMap(helmRelease.Values),
                    Lint:            pulumi.BoolPtr(false),
                    Verify:          pulumi.BoolPtr(false),
                    ResetValues:     pulumi.BoolPtr(true),
                    AllowNullValues: pulumi.BoolPtr(true),
                },
                pulumi.Provider(providers[clusterName]))

once json file is ready execute below command
pulumi import -f ./vars/bulk-import.json --protect=false --generate-code=false

Error:

kubernetes:helm.sh/v3:Release (edge/metallb-system/metallb):
error: Preview failed: failed to load chart from temp directory: stat metallb: no such file or directory

This works fine with pulumi-kuberenetes provider v4.2.0 and failing on v4.3.0

Output of pulumi about

CLI
Version 3.85.0
Go Version go1.21.1
Go Compiler gc

Plugins
NAME VERSION
go unknown

Host
OS debian
Version 12.1
Arch x86_64

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

Additional context

Suspecting the issue is due to changes #2568 added in v4.3.0 I tried ignoreChanges: ["checksum"] but still it is failing for pulumi import

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

[mikhailshilkov]

@EronWright This sounds like a regression from #2568, could you take a look?

[EronWright]

I am able to reproduce this issue, and I agree that it is a regression from #2568.

Some repro notes (WIP):

❯ k create namespace metallb-system
namespace/metallb-system created
❯ helm repo add metallb https://metallb.github.io/metallb
❯ helm install metallb metallb/metallb -n metallb-system

[EronWright]

To provide a brief update, a potential fix has been implemented and is being tested:
#2605

[EronWright]

@yogeshghotekar we published a fix in v4.5.0, could you reply with a confirmation that the fix was effective for you?

[rhuanbarreto]

This is still actual in v4.5.4. We should reopen

[EronWright]

@rhuanbarreto could you elaborate on the specific issue that you are seeing? Some output would really help, thanks.