Hi, I got a problem regarding of how to configure that when a resource it’s recreated during the apply phase, another resource is destroyed first in terraform. It needs to be taken in consideration that create_before_destroy cannot be used for the resource recreated because this resource must be unique within its provider.
My particular use case it’s a Databricks Workspace, that got an storage credential, which its used for creating some external locations, necessary for creating some catalogs. When I change the external locations and run terraform apply, they need to be recreated but they cannot be destroyed because there it’s the catalogs depending on it. Also cannot be use create_before_destroy because it is raised an error that cannot be created two external locations pointing to the same url.
As a work around I handle it through different terraform commands using the -target flag. Nevertheless it would be nice that this is handled automatically through the terraform configuration during the apply phase.
There are only 2 valid orderings for the handling of replacement/deletion of resources, the default (which is destroy then create) and create_before_destroy.
It’s somewhat common for a resource to have “registered” some aspect of another dependency, and that registration must updated before the dependency can be removed or replaced. Resources that operate in this manner must be made compatible with create_before_destroy (which could also be called “update before destroy” when thinking of this in terms of these registration pattern resource), and will usually provide some way to automatically create unique identifiers to avoid conflicts.
This is something that should be raised with the provider if they want to be able to have this type of replacement work in a single terraform plan+apply operation. The workaround would be to manually make the change over 2 operations, removing the registration first, then replacing the resource.