fix(VPCSC): enable dryrun mode

[eeaton]

Address issue #1209 .
CI tests have high flaky failure rate due in part to propagation delays with VPCSC perimeter. Changing this to dry mode better adheres to best practices for enablement and will avoid this issue in CI tests.

[daniel-cit]

the way the projects are added to the perimeter in step 4-projects also needs to be updated.

  vpc_service_control_attach_enabled = var.vpc_service_control_attach_enabled
  vpc_service_control_perimeter_name = var.vpc_service_control_perimeter_name
  vpc_service_control_sleep_duration = var.vpc_service_control_sleep_duration

https://github.com/terraform-google-modules/terraform-example-foundation/blob/master/4-projects/modules/single_project/main.tf#L62C1-L64C78

This cloud be a new flag like how it is coded in the project factory module

https://github.com/terraform-google-modules/terraform-google-project-factory/blob/master/modules/core_project_factory/main.tf#L347C1-L365C2

[amandakarina]

hey Eliot, just wondering if this change could be done with a flag instead of comment/uncomment the code, export in outputs to be read by other steps, like 4-projects as Daniel mentioned. It would also be less tricky for others blueprints that have documentation of how to deploy on top of foundation.

[daniel-cit]

• This fix also needs to be implemented in the hub and spoke flow
  
• and also in the simple project module in step 4-projects
• It would be helpful for the user to have a note on the main README and the READMEs from step 3 that the perimeter is created in dry mode and that it need to be updated to start enforcing the rules.

is it possible to have a flag vcp_sc_dry_run that could be set to true in the test instead of editing the code?

[fmichaelobrien]

/lgtm
either with/without dryrun flag - will be usefull

[eeaton]

Thanks Daniel & Amanda for the input.

ACK to add the changes consistently across step 4-projects, simple project module, and hub-and-spoke flow
Will add directions on the Readme about what to set for VPCSC.

re: the flag, like our discussion over chat I realize now we need separate input variables, because it is a valid use case for customers to set the enforced perimeter and dryrun perimeter to separate configurations (they are two different resources managed by the same CFT module). I'll draft this proposal and update the PR.

[eeaton]

Quick update: I'm blocked by a provider error on CFT.
terraform-google-modules/terraform-google-project-factory#904

The project factory module has partially designed support for an argument vpc_service_control_attach_dry_run but doesn't complete the implementation, it's not actually exposed to the Terraform Google Provider.

I've experimented locally with a few different patterns consistently that set the perimeter to dry_run mode in the 3-networks and 4-projects stage, but until the provider is fixed I don't think I can implement it using the current project factory module.

[daniel-cit]

Quick update: I'm blocked by a provider error on CFT. terraform-google-modules/terraform-google-project-factory#904

The project factory module has partially designed support for an argument vpc_service_control_attach_dry_run but doesn't complete the implementation, it's not actually exposed to the Terraform Google Provider.

I've experimented locally with a few different patterns consistently that set the perimeter to dry_run mode in the 3-networks and 4-projects stage, but until the provider is fixed I don't think I can implement it using the current project factory module.

@eeaton new release for the project factory module v15.0.0

[eeaton]

I've made a few new commits, but no need to do a full review yet. I've got a working version of configuring the dry-run perimeter in my local environment for the dualsvpc pattern, but haven't tested it fully for hub-and-spoke (just copied off the key differences manually). I want to run the full CI tests to identify any configuration errors I might have introduced.

Once that is working well I'll add the readme changes and then ask for a review

[daniel-cit]

Dual Shared VPC build

Step #17 - "verify-networks":         	Error:      	Received unexpected error:
Step #17 - "verify-networks":         	            	FatalError{Underlying: error while running command: exit status 1; 
Step #17 - "verify-networks":         	            	Error: Output "restricted_access_level_name" not found
Step #17 - "verify-networks":         	            	
Step #17 - "verify-networks":         	            	The output variable requested could not be found in the state file. If you
Step #17 - "verify-networks":         	            	recently added this to your configuration, be sure to run `terraform apply`,
Step #17 - "verify-networks":         	            	since the state won't be updated with new output variables until that command
Step #17 - "verify-networks":         	            	is run.}
Step #17 - "verify-networks":         	Test:       	TestNetworks/nonproduction

[eeaton]

Thanks for helping identify the issue Daniel. I've fixed the tests to check for the correct variable name (I hadtweaked a few variables in code that I found to be misleading variable names but didn't apply the same changes to variables that the tests expected)