Closed ovitente closed 10 months ago
@ovitente Hi, you will need to add keep_associated_vpc
to the cloudamqp_instance
resource.
https://registry.terraform.io/providers/cloudamqp/cloudamqp/latest/docs/resources/instance#keep_associated_vpc
Otherwise the VPC will be destroyed when the cloudamqp_instance
being destroyed. Remnant from older versions, in between when managed standalone VPCs was introduced.
@tbroden84 I wonder if we could make the provider smarter: not sure it makes sense for cloudamqp_vpc
to raise an error when the resource has already been deleted
If we make our backend respond with 410 Gone instead of 404 Not Found, we could make it happen and still raise error when the ID is actually incorrect
@tbroden84 Thank you, it solved the issue for now.
I'll add that this issue can also get you into an inconsistent state which blocks planning completely if you target the instance for destruction, but nothing else:
$ terraform destroy --target=module.cloudamqp.cloudamqp_instance.instance
...
Destroy complete! Resources: 28 destroyed.
$ terraform plan
module.cloudamqp.random_password.password_items["service_user"]: Refreshing state... [id=none]
module.cloudamqp.random_password.password_items["second_service_user"]: Refreshing state... [id=none]
data.google_secret_manager_secret_version.cloudamqp_full_access_key: Reading...
data.google_secret_manager_secret_version.cloudamqp_full_access_key: Read complete after 0s [id=projects/501495631697/secrets/cloudamqp-full-access-key/versions/1]
cloudamqp_vpc.vpc: Refreshing state... [id=258088]
Planning failed. Terraform encountered an error while generating this plan.
╷
│ Error: ReadVpcInstance failed, status: 404, message: map[error:No VPC found with ID: 258088]
│
│ with cloudamqp_vpc.vpc,
│ on main.tf line 4, in resource "cloudamqp_vpc" "vpc":
│ 4: resource "cloudamqp_vpc" "vpc" {
│
╵
Here, I'd expect the provider to plan the creation of the instance. Note that the vpc itself did not show up in the list of resources to be destroyed.
I understand and will apply the workaround, but I do believe the default behavior should be to not destroy a VPC if you have managed it in TF through a specific resource. I might want to both create and remove an instance in the same apply, example. If I have declarative code for the VPC, I shouldn't have to think.
Furthermore, the dependency graph should be resolved such that the VPC is also scheduled for destruction if I destroy the instance, if the default is kept as it is. I should be able to see in the TF destruction plan what the provider is gonna do.
The managed VPC resource will no longer throw and error in the latest version v1.29.0. Instead log a warning and continue if it has been deleted by other resource.
The reason it doesn't show up in the dependancy graph, is when destroyed through the instance it's done in our backend. No such dependency is known by the provider. This is unfortunately a rest from when the managed standalone VPC resource was introduced.
I think we can close this issue now?
We will still have https://github.com/cloudamqp/terraform-provider-cloudamqp/issues/245 open to track that gotcha.
I have simple module
Which allows create vpc and cloudamqp instance under it, but it fails when I try to delete these resources.
It actually deletes them on CloudAMQP but returning error in terraform.
It seems it is some bug in cloudamqp provider.
Destroy log