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

Not right now, but you’re right that particular thing is pretty annoying.

I’ve thought about allowing users to specify it by adding annotations, for example.

One problem is that imperative operations like “delete this” are not exposed to the language host, and it’s not clear they should be.

like `"<http://pulumi.io/strict-delete|pulumi.io/strict-delete>": "true"` or something.

this particular issue of `StatefulSet` / `PersistentVolume` is sooooooo annoying.

And we don’t really tell the user what’s happening, currently. It just is something you have to figure out.

What I had in mind is some sort of generic resource on_destroy hook in which i can some execute an arbitrary function, e.g. in my case `execSync('kubectl delete pvc -l='some=label'')`. I’m not 100% about this, but I think terraform has some stuff like that.

We are already planning on having things like “strict pods” Pulumi will consider successful if and only if none of the containers are crashing

So it might make sense to just wrap that into the definition of `StrictStatefulSet` or something.

The other option is, we could just decide to always delete the underlying PVC.

I’m actually not 100% sure I understand why k8s doesn’t do it.

Is there any workaround I could use for now?

Yeah I think actually k8s should introduce something similar to ReclaimPolicy on the statefulset itself.

There are ways to do stuff after creation and update, but not delete, I think. <@U84SY03DF> <@UB3BGTV63> do you have ideas here?

<@UCPSHLVC4> we could also have `StrictStatefulSet` extend the semantics of `StatefulSet` so that it _does_ have a `ReclaimPolicy`.

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