terraform-example-foundation icon indicating copy to clipboard operation
terraform-example-foundation copied to clipboard

[UX] Project ID collision handling

Open matt-declarativecloud opened this issue 4 years ago • 8 comments
trafficstars

Deploying with Cloud Build

Issue

When Project creation fails with Error 409: Requested entity already exists, alreadyExists the randomized Project ID is written to .tfstate in "provider[\"registry.terraform.io/hashicorp/random\"]" and even though Project creation fails, the Project ID is recorded in .tfstate outputs

Workaround

To resolve the Project ID collision the .tfstate must be modified to remove the object created by the hashicorp/random provider

Enhancement ideas

  • Project outputs should only be written when Project Resource creation succeeds
  • It would be great if the hashicorp/random resource could be tainted in this scenario so subsequent apply operations generate new random Project IDs

matt-declarativecloud avatar Apr 24 '21 19:04 matt-declarativecloud

Unfortunately there isn't any way for us to do this. It's core Terraform behavior.

morgante avatar Apr 24 '21 22:04 morgante

reopening to include some sample commands on how to taint and recover in the troubleshooting docs

bharathkkb avatar Apr 25 '21 03:04 bharathkkb

Trying to understand what needs to be documented. Is it the case that if the user gets the listed error message, they should delete the project name from .tfstate and try running terraform again?

mark1000 avatar Aug 18 '21 18:08 mark1000

IMO instruction should be given to temporarily

  • connect to remote state
  • taint the resource as described in 494

Tension is inherent between the goal of having a black box GitOps interface for customers that doesn't require Terraform expertise, and the likelihood that at some point an escape hatch will be required. For cases like this it will be useful to explain how to temporarily break out of the GitOps workflow and wire up Terraform to remote state for targeted, resource-level operations.

matt-declarativecloud avatar Aug 19 '21 22:08 matt-declarativecloud

Any update on this? Whilst rehearsing the deployment of landing zones with the CFT - my team has experienced this issue multiple times. Ideally the modules building out projects, would be updated to use a larger range of "random Id's" but i realise there are many different modules which would need the same issue remediation.

Could all the layers instead have an extra random id inserted into the project name template (before the module's are called?)

for example: prj-c-dns-hub-c98c becomes prj-c-dns-hub-7bfe-c98c

This should then hopefully avoid the opportunity for the same "unique" project name to be generated twice, obviously there is a probability but a much lesser one than currently

M88YEH avatar Jun 27 '22 10:06 M88YEH

@bharathkkb - are you still planning to work on this?

g-awmalik avatar Aug 11 '22 22:08 g-awmalik

@daniel-cit once https://github.com/terraform-google-modules/terraform-google-project-factory/pull/742 lands lets update project factory everywhere to use new approach added in https://github.com/terraform-google-modules/terraform-google-project-factory/pull/735 which should reduce this from happening

bharathkkb avatar Sep 09 '22 01:09 bharathkkb

@bharathkkb - Is this work still happening? Thanks!

stevena-cloudsec avatar Nov 28 '22 18:11 stevena-cloudsec