You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If the modules are being applied as part of the umbrella sigstore module, then cluster_name will be the same for each and they will try to create the same resource named the same thing, and terraform will abort with a conflict error:
The only way around this is to import the "existing" resource (which terraform just created for the other module) and run terraform apply again.
If no infrastructure had been deployed yet and we were working from a blank slate, an easy fix would be to move the address resource out of the redis and mysql submodules into the sigstore umbrella module: https://gist.github.com/cmurphy/e65913dd4533d2733a1c3404851b103e
This is not safe to do in an already-deployed environment, because terraform sees the resource as new and destroys the old ones, assigning a new IP range to the new resource.
Terraform provides a moved block to do this type of refactoring, so resources aren't destroyed. However, this won't work to move two resources, because it's ambiguous to terraform:
│ Error: Ambiguous move statements
│
│ on .terraform/modules/sigstore/terraform/gcp/modules/sigstore/sigstore.tf line 169:
│ 169: moved {
│
│ A statement at .terraform/modules/sigstore/terraform/gcp/modules/sigstore/sigstore.tf:164,1 declared that module.sigstore.module.mysql.google_compute_global_address.private_ip_address moved to module.sigstore.google_compute_global_address.private_ip_address, but this statement instead declares that
│ module.sigstore.module.redis.google_compute_global_address.service_range moved there.
│
│ Each resource can have moved from only one source resource.
The only way to resolve this on a running system would be to
Add the move statement for one of the resources, say mysql
Manually remove the other resource from the terraform state with terraform state rm.
Run terraform apply
This is not a friendly migration for anyone consuming the terraform modules from this repo.
Description
The redis and mysql modules each manage a
google_compute_global_address
resource with name<cluster name>-priv-ip
:scaffolding/terraform/gcp/modules/mysql/mysql.tf
Line 40 in 0621d50
scaffolding/terraform/gcp/modules/redis/main.tf
Line 35 in 0621d50
If the modules are being applied as part of the umbrella sigstore module, then
cluster_name
will be the same for each and they will try to create the same resource named the same thing, and terraform will abort with a conflict error:The only way around this is to import the "existing" resource (which terraform just created for the other module) and run terraform apply again.
If no infrastructure had been deployed yet and we were working from a blank slate, an easy fix would be to move the address resource out of the redis and mysql submodules into the sigstore umbrella module: https://gist.github.com/cmurphy/e65913dd4533d2733a1c3404851b103e
This is not safe to do in an already-deployed environment, because terraform sees the resource as new and destroys the old ones, assigning a new IP range to the new resource.
Terraform provides a
moved
block to do this type of refactoring, so resources aren't destroyed. However, this won't work to move two resources, because it's ambiguous to terraform:The only way to resolve this on a running system would be to
terraform state rm
.terraform apply
This is not a friendly migration for anyone consuming the terraform modules from this repo.
Version
6d618cc
The text was updated successfully, but these errors were encountered: