NO! A warning about an unreachable K8s cluster should not remove the resource from the Pulumi state!

Diagnostics:
  kubernetes:apps:Deployment (ingress-gloo-qq119b7f/discovery):
     warning: configured Kubernetes cluster is unreachable: unable to load schema information from the API server: Get https://<mycluster>.<http://azmk8s.io:443/openapi/v2?timeout=32s|azmk8s.io:443/openapi/v2?timeout=32s>: net/http: TLS handshake timeout
... 15 more times
...
Resources:
    - 15 deleted
    69 unchanged

Nothing of that Helm chart deployment is actually deleted!

What would you suggest instead? It’s like this because users would frequently delete the k8s cluster in a separate stack, and then there was no way to clean up the resources that had been deployed to the cluster without manually editing state. Since the state is recoverable, we thought this was a reasonable compromise (warn prior to deleting from state).

See my comment on this GH issue: https://github.com/pulumi/pulumi-kubernetes/issues/881#issuecomment-593500282

The problem is we can’t tell the difference between a transient network partition and the cluster being deleted.

Yes. it was ok then. Even the “preview part” of

pulumi up

was still OK

Ah, I see. I didn’t consider the case where the partition occurred between preview and update

It’s like this because users would frequently delete the k8s cluster in a separate stack, and then there was no way to clean up the resources that had been deployed to the cluster without manually editing state.

This should be the exceptional case where users need to fiddle with state, not the normal behavior. I now feel punished for bad user practices of not removing their deployments before deleting the cluster. I now have to fiddle with state and my cluster manually.

We should be able to recover your state, and I’ll open an issue to reconsider this behavior.

Can I list the versions via the CLI?

AFAIK, there’s no programmatic way to get the version currently (https://github.com/pulumi/pulumi/issues/2412#issuecomment-590125246) But yes, the version number is part of the permalink.

The faulty run was 68, so I exported 67. Do I now just import that version of the state again?

Yes, that’s right.

pulumi stack import --file <file>

OK, I’m going to do that at home. I’m in the train at the moment via my mobile. That feels like doing surgery with a shaking hand. 😄

Sure thing. Let me know if you’re still having problems, and sorry for the inconvenience.

and I’ll open an issue to reconsider this behavior.

Just one last thing, can you @-mention me on the GH issue you would create so I can follow up?