Deleting an entire database (Google Cloud SQL, for example) shouldn't require deleting every single User/Role/Grant

[dor-utila]

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

Currently, when destroying a stack that has a database and a bunch of resource within it,
Pulumi tries to first remove the contained resources. This is wasteful - all those contained resource will be deleted anyway if the entire DB server is deleted.

Also, sometimes the network connectivity to the DB is lost - and then I get something like:

     Type                           Name                                          Status                  Info
     pulumi:pulumi:Stack            util-dev-1-dortest2                **failed**              1 error; 4 
 -   ├─ postgresql:index:GrantRole  k8s-job-svc-account-login-user-grant  **deleting failed**     1 error

Meaning, Pulumi won't even try to delete the DB server, and I have to manually pulumi state delete all the DB-internal resources before I can move on to delete the server resource.

[sam-utila]

One would think that using Parent semantics (i.e. GrantRole a child of the database) will help, but it also does not.

[viveklak]

As it stands, the pulumi engine can't distinguish between cases where the presence of contained resources will be a failure scenario (e.g. think of subnets in a vpc) vs. those where the deletion of the container resource will delete the contained resources. If there is no ambiguity about retaining the contained resource, you could annotate them with https://www.pulumi.com/docs/intro/concepts/resources/options/retainondelete/ such that pulumi doesn't attempt to delete the contained resources during deletion. Deletion of the database will then take care of cleaning up the underlying resources.

[sam-utila]

Thanks for the answer Vivek.

That's a serious limitation in Pulumi.

RetainOnDelete is not enough because it will retain whether you delete the container resource or only the contained resource itself.

This problem "shines" in pulumi-postgresql:

Imagine someone deleted the enveloping database which had 1000 resources within it.
Removing the DB from the state will be a painful task.

Imagine you want to delete the database on GCP (CloudSQL), you have access to the instance but you don't have a password to connect to it - you can't delete the container instance without caring that you don't know the password.

[sam-utila]

Added small PR that adds this functionality to Pulumi:
pulumi/pulumi#11095