example
Step 1 - I create a cdn in azure
Step 2 - I create a dns on amazon pointing to the cdn’s cname
Step 3 - I create a custom domain
(this above works perfectly for creating)
however to destroy the error
because I would have to destroy the dns first, the destroy order should be
Step 2 destroy the dns
Step 3 destroy the custom domain
Step 1 destroy the cdn
is it´s posible?
Hi @marciojsilva,
There’s no way to arbitrarily re-order the resource destruction, as it is defined by being the inverse of the order of creation. There is the create_before_destroy lifecycle option, but that only inverts the order of operations between create/update and destroy.
It would be highly unusual for 2 resources to require being both created and destroyed in the same order if there were a true dependency between the two. Can you show an example of the configuration for these resources?
Hi jbardin, thanks your help
create_before_destroy lifecycle i don’t think it will work here
the idea is as follows
Step 1 - I create the CDN in Azure
Step 2 - I create the CDN EndPoint
Step 3 - to create the Endpoint’s Custom Domain, I need to create a dns, and my provider is on Amazon, after creating this DNS I can create the custom domain
to destroy
If I try to destroy the CDN directly(terraform destroy),
it says that first I need to delete the DNS, so here my problems begin, if I go and delete the record directly on the portal, I can do it
destroy, if it doesn’t, it doesn’t destroy the CDN
I get a message like this
deleting “custom Domain: cannot delete custom domain. please remove the DNS CNAME records and try again”
Can I create 2 tfstate in the same code?
because I can create a delete CI pointing to separate tfstate
if it doesn’t work, i’m thinking about using amazon cli and deleting the record before terraform destroy
It’s hard to say exactly what is going on here without actual configuration to see. Some resources do have unusual behaviors, so it isn’t entirely impossible that the custom domain requires dns but cannot be deleted before the dns entry. It still seems very unusual, and may be worth bringing up with the provider to see if they can work around it in some way if this is really the case.
It will take some scripting to work around the described situation. You cannot currently manage multiple states from a single plan+apply workflow, so multiple terraform steps would be required for that approach. You could also directly call the aws cli like you mentioned, or even try calling it from a destroy-time provisioner on a null_resource (however that has additional drawbacks like only being able to execute once on a complete terraform destroy action).
Thanks @jbardin ,
I made it through Amazon CLI in a CI .
but I’ll try to talk to my provider, to see if there is a way around it.
I was reading on the internet and I saw more people with similar problems, but on different objects, maybe an idea to improve our terraform was to create a destroy_on
Thanks you help
Marcio Silva
Why does this have to be a provider problem? It’s not unreasonable for the provider to require that the CNAME record be created before the infra can be created. And it’s not unreasonable for the provider to require that the CNAME be deleted before the infra can be destroyed.
Why can’t you just add a feature to Terraform to allow us to specify what should happen?
It’s this kind of stuff that makes me look like an idiot for suggesting that we use Terraform.
@alexdresko, it’s not necessarily a provider problem, there isn’t much a provider can do here either, other than ensure that resources can be used with the create_before_destroy ordering. The reason for the overall order is because that is what is required to create a dependency graph with no cycles in all create, update, destroy and replace scenarios.
If this is a prevalent enough problem, we could work with providers to research alternatives, but I’m not sure what that would look like given the inherent problems that the proposed ordering can create. There are more details in comments in issues Allow to specify deletion order – similar to `create_before_destroy` · Issue #30439 · hashicorp/terraform · GitHub and Terraform apply destroys resources that are still referenced from other resources · Issue #31309 · hashicorp/terraform · GitHub
Just wanted to chime in and say that the correct fix for this problem is to run az feature register --namespace Microsoft.Cdn --name BypassCnameCheckForCustomDomainDeletion. This, I believe, is what @jbardin was trying to get it at. After running that command, Azure still requires the CNAME to be created before the custom domain can be created, but it no longer requires deleting the CNAME before the custom domain can be deleted.
Thanks for leading me in the right direction, @jbardin. Sorry if I sounded like a jerk.
I have a use case for this. using the github provider, I create branch_protection rules that prevent deletion for a pattern of branch names, then create a branch that matches, where I do not want the 1st push to occur before the branch protection rules exist. On repo removal via “terraform destroy”, the above dependency requires the branch deletion to go first, which fails because branch protection prevents branch deletion, and this prevents the deletion of the branch protection rules. I think I’m forced to add an entirely separate step before the terraform delete to handle this.