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
However nowhere in the environment a hierarchical FW rule with this name is visible
This is the error
Error: Error creating OrganizationSecurityPolicy: googleapi: Error 400: Invalid value for field 'resource.displayName': 'common-firewall-rules-kaj5'. The display name is already used. Please choose another one, invalid
with module.hierarchical_firewall_policy.google_compute_organization_security_policy.policy,
on ../../modules/hierarchical_firewall_policy/main.tf line 27, in resource "google_compute_organization_security_policy" "policy":
27: resource "google_compute_organization_security_policy" "policy" {
There might have been a failed "apply" before that somehow left hanging around in non-existence a FW rule with this name. But can't see it anywhere in the environment.
The problem is the random "suffix" which won't change in subsequent apply operations because the resource random_string is already in the tfstate
To verify the hypothesis just bumped from 4 to 6 the length of the random string in 3-networks-hub-and-spoke/modules/hierarchical_firewall_policy/main.tf : resource "random_string" "suffix"
Lol and behold, the "apply" succeeded this time.
Expected behavior
Should not have such naming conflicts with zombie resources or at least have an explanation why this happens (e.g. issue 1187)
Observed behavior
It seems this issue with "zombie" left-over resources after failed "apply" is general and should be fixed
Terraform Configuration
Nothing special
shared.auto.tfvarstarget_name_server_addresses= [
{
ipv4_address ="192.168.0.1",
forwarding_path ="default"
},
{
ipv4_address ="192.168.0.2",
forwarding_path ="default"
}
]
common.auto.tfvars// The DNS name of peering managed zone. Must end with a period.domain= "gcp.mcn.gouv.qc.ca."// Update the following line and add you email in the perimeter_additional_members list.// You must be in this list to be able to view/access resources in the project protected by the VPC service controls.//perimeter_additional_members = ["user:[email protected]"]perimeter_additional_members= ["user:[email protected]"]
remote_state_bucket= "bkt-prj-b-seed-tfstate-55de"enable_hub_and_spoke_transitivity= false
Terraform Version
$ terraform version
Terraform v1.6.0
on linux_amd64
Additional information
No response
The text was updated successfully, but these errors were encountered:
TL;DR
However nowhere in the environment a hierarchical FW rule with this name is visible
This is the error
Error: Error creating OrganizationSecurityPolicy: googleapi: Error 400: Invalid value for field 'resource.displayName': 'common-firewall-rules-kaj5'. The display name is already used. Please choose another one, invalid
with module.hierarchical_firewall_policy.google_compute_organization_security_policy.policy,
on ../../modules/hierarchical_firewall_policy/main.tf line 27, in resource "google_compute_organization_security_policy" "policy":
27: resource "google_compute_organization_security_policy" "policy" {
There might have been a failed "apply" before that somehow left hanging around in non-existence a FW rule with this name. But can't see it anywhere in the environment.
The problem is the random "suffix" which won't change in subsequent apply operations because the resource random_string is already in the tfstate
To verify the hypothesis just bumped from 4 to 6 the length of the random string in 3-networks-hub-and-spoke/modules/hierarchical_firewall_policy/main.tf : resource "random_string" "suffix"
Lol and behold, the "apply" succeeded this time.
Expected behavior
Should not have such naming conflicts with zombie resources or at least have an explanation why this happens (e.g. issue 1187)
Observed behavior
It seems this issue with "zombie" left-over resources after failed "apply" is general and should be fixed
Terraform Configuration
Terraform Version
Additional information
No response
The text was updated successfully, but these errors were encountered: