Permadiff in pulumiLabels and effectiveLabels with empty labels for gcp:container:Cluster

[zbuchheit]

Describe what happened

Similar behavior to #2372

A user reported seeing a diff in effectiveLabels/pulumiLabels under 8.2.0

gcp:container:Cluster gke-cluster  update [diff: ~effectiveLabels,pulumiLabels]

Sample program

TODO

Log output

No response

Affected Resource(s)

No response

Output of pulumi about

gcp:container:Cluster

Additional context

The previous issue for the other resources like bucket and kms key are fine now, seems only gcp:container:Cluster remains problematic

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

[iwahbe]

Hmmm. @zbuchheit please let us know as soon as you have a repro.

[VenelinMartinov]

The resource has an overloaded labels field: https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/container_cluster

labels is used as a Kubernetes property and resource_labels are the GCP labels.

I suspect that #2386 does not handle that case.

[iwahbe]

It does not. I'm guessing we will need to special case this resource.

[VenelinMartinov]

Couldn't repro so far:

import * as pulumi from "@pulumi/pulumi";
import * as gcp from "@pulumi/gcp";

const _default = new gcp.serviceaccount.Account("default", {
  accountId: "service-account-id-2",
  displayName: "Service Account",
});

const primary = new gcp.container.Cluster("primary", {
  name: "marcellus-wallace",
  location: "us-central1-a",
  initialNodeCount: 3,
  deletionProtection: false,
  nodeConfig: {
    serviceAccount: _default.email,
    oauthScopes: ["https://www.googleapis.com/auth/cloud-platform"],
    resourceLabels: {
      foo: "bar",
      empty: "",
    },
  },
});

produces no diff, unlike with #2372

[VenelinMartinov]

Ok, the repro is with labels actually:

import * as pulumi from "@pulumi/pulumi";
import * as gcp from "@pulumi/gcp";

const _default = new gcp.serviceaccount.Account("default", {
  accountId: "service-account-id-2",
  displayName: "Service Account",
});

const primary = new gcp.container.Cluster("primary", {
  name: "marcellus-wallace",
  location: "us-central1-a",
  initialNodeCount: 3,
  deletionProtection: false,
  nodeConfig: {
    serviceAccount: _default.email,
    oauthScopes: ["https://www.googleapis.com/auth/cloud-platform"],
    labels: {
      foo: "bar",
      empty: "",
    },
  },
});

[iwahbe]

@VenelinMartinov I am unable to reproduce the problem on v8.2.0 with the above program.¹

Footnotes

1. I changed id-2 to id-3, but I don't think that will be material. ↩

[VenelinMartinov]

Yeah, it looks like i was using 7.38.0 - pulumi new still gives v7.

[zbuchheit]

Happening via Go MLC will attempt a repro shortly

[zbuchheit]

the following repros for me on 8.2.0, it appears the field causing it is resourceLabels

Code Repro

import * as gcp from "@pulumi/gcp";

const serviceAccount = new gcp.serviceaccount.Account(
  "zbuchheit-service-account",
  {
    accountId: "zbuchheit-service-account",
    displayName: "zbuchheit-service-account",
  }
);

const cluster = new gcp.container.Cluster("zbuchheit-cluster", {
  name: "zbuchheit-cluster",
  initialNodeCount: 1,
  location: "us-west2",
  nodeConfig: {
    machineType: "e2-medium",
    oauthScopes: ["https://www.googleapis.com/auth/cloud-platform"],
    serviceAccount: serviceAccount.email,
  },
  resourceLabels: {
    environment: "dev",
    test: "",
  },
  deletionProtection: false,
});

[VenelinMartinov]

I've confirmed @zbuchheit 's repro also works for me with 8.2.0 - will investigate.

My previous attempts at reproing this were with resourceLabels on the nodeConfig property - that seems to be the reason we couldn't repro before.

[pulumi-bot]

This issue has been addressed in PR #2441 and shipped in release v8.3.1.