Creating Persistent Volume Claim on GKE cluster results in timeout

[DennyPazak0101]

What happened?

The Pulumi Kubernetes provider is unable to detect that PVCs on GKE clusters usually are created when there are pods that use the PVC actually mentioned by the hint: waiting for first consumer to be created before binding. The Kubernetes would expect the PVC to return with the status created, but this won't happen. Therefore Pulumi will run in a timeout. The workaround right now is to run Pulumi a second time when Pulumi detects that the PVC have to be updated.

The abortion of Pulumi worsens the problem because in a second run the PVC will be detected to be still created instead of being needed to be updated. Also pulumi refresh doesn't work either.

Steps to reproduce

Create a PVC on a GKE cluster.

Expected Behavior

The Pulumi Kubernetes provider detects that the Kubernetes cluster is running on GKE and therefore doesn't wait for the PVC to be created in order to move on to create other reservices such as deployments that actually use the PVC. Resulting from that the previous created PVC will be actually bound.

Actual Behavior

The Pulumi Kubernetes provider runs into a timeout because it expects that the PVC will be created or rather bound. But this won't happen on a GKE cluster til a consumer is created such as a deployment.

Versions used

I use the libs for TypeScript:

{
    "name": "dummy",
    "devDependencies": {
        "@types/node": "^14"
    },
    "dependencies": {
        "@pulumi/gcp": "^6.24.0",
        "@pulumi/kubernetes": "^3.19.0",
        "@pulumi/kubernetesx": "^0.1.6",
        "@pulumi/pulumi": "^3.33.1",
        "@pulumi/random": "^4.7.0",
        "@types/lodash": "^4.14.182",
        "@types/luxon": "^2.3.2",
        "lodash": "^4.17.21",
        "luxon": "^2.3.2"
    }
}

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

[viveklak]

Thanks for flagging this @DennyPazak0101 - I at least was not aware of this "optimization" on GKE. I think a reasonable workaround for the moment might be to consider adding the pulumi.com/skipAwait: "true" annotation to the PVC specification to avoid blocking other resources.