Provide a knob to optionally skip creating the VPC related resources

[yegle]

Description

Provide a var.external_vpc to specify the VPC settings that are not managed by the Terraform configs.

Checklist

General

• Added the correct label
• Assigned to a specific person or civiform/deployment-system
• Created tests which fail without the change (if possible)
• Performed manual testing (at a minimum run bin/setup without your changes and then bin/deploy with your changes to ensure your changes don't break existing deployments)
• Extended the README / documentation, if necessary

Instructions for manual testing

Tested by patching this change to the checkout folder against my dev environment, w/o vars.external_vpc.

(NOTE: it will be difficult to test w/ vars.external_vpc, as Terraform will try to destroy some resources)

Issue(s) this completes

Fixes civiform/civiform#7378

This reverts commit ed78f28. It also fixed the breakage originally introduced in f1e3565, where a local variable was referenced without the local. prefix.

[dkatzz]

Thanks for fixing this, @yegle! Would you mind updating the title to remove the "revert" parts. And then in the description could you include a bit more information about what changed and also include the github issue it relates to (similar to what was included in the original PR, but with some information about what changed between that PR and this one to fix the issue)? And could you also include in the description how you tested it?

[yegle]

PR description updated, PTAL.

[dkatzz]

Could we try testing with vars.external_vpc set for a bin/setup? In that case there won't be existing resources. You can first nuke the resources in the environment or use a different app-prefix.

[yegle]

With the moved block added in the last commit, I did the following test:

Testing w/o external vpc configs:

1. Deploy to my dev project using the main branch
2. Switch to the fix-vpc-knob branch (this PR), run terraform plan

Output:

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the
following symbols:
  ~ update in-place
-/+ destroy and then create replacement
...
Plan: 2 to add, 1 to change, 2 to destroy.

(resource.aws_ecs_task_definition.civiform_only and resource.aws_ecs_task_definition.civiform_with_monitoring were force replaced due to the image version change)

I did not test w/ external vpc configs. We will need to work with the CE on this, since if the CE partially sets up the VPC using the Terraform config and then sets the external_vpc variable, it will destroy all vpc related resources, even if you want to reuse the partially created resource.

When the CE decides to use this knob, we should work closely with them, run terraform state rm for every resource that is proposed to destroy and then switch to the external managed VPC resources.

SGTY?

[dkatzz]

With the moved block added in the last commit, I did the following test:

Testing w/o external vpc configs:

1. Deploy to my dev project using the main branch
2. Switch to the fix-vpc-knob branch (this PR), run terraform plan

Output:

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the
following symbols:
  ~ update in-place
-/+ destroy and then create replacement
...
Plan: 2 to add, 1 to change, 2 to destroy.

(resource.aws_ecs_task_definition.civiform_only and resource.aws_ecs_task_definition.civiform_with_monitoring were force replaced due to the image version change)

I did not test w/ external vpc configs. We will need to work with the CE on this, since if the CE partially sets up the VPC using the Terraform config and then sets the external_vpc variable, it will destroy all vpc related resources, even if you want to reuse the partially created resource.

When the CE decides to use this knob, we should work closely with them, run terraform state rm for every resource that is proposed to destroy and then switch to the external managed VPC resources.

SGTY?

We'll actually be using a different AWS account for them for this deployment than their previous deployment, so we shouldn't have to do the terraform state rm. I think we should be able to just add the new VPC information before the deployment and then see how that goes.