No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

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>

I look at this as an intermittent network issue.

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

Did you run a preview prior to applying the update?

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

&gt; 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.

If you are using the Pulumi Service, you can export older versions using `pulumi stack export --version &lt;n&gt;` or download it from the UI (we added this capability last week).

Or is the version the last part of the permalink posted after `pulumi up`?

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 &lt;file&gt;`

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. :smile:

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

&gt; 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?

<https://github.com/pulumi/pulumi-kubernetes/issues/1013>