fix: make sure subnet is uniquely named

[glasnt]

Resolves #60

[glasnt]

TestSimpleExample 2023-04-28T06:00:31Z retry.go:99: Returning due to fatal error: FatalError{Underlying: error while running command: exit status 1; 
Error: Invalid for_each argument

  on .terraform/modules/dynamic-python-webapp.gce-vpc/modules/subnets/main.tf line 29, in resource "google_compute_subnetwork" "subnetwork":
  29:   for_each                   = local.subnets
    ├────────────────
    │ local.subnets will be known only after apply

The "for_each" map includes keys derived from resource attributes that cannot
be determined until apply, and so Terraform cannot determine the full set of
keys that will identify the instances of this resource.

When working with unknown values in for_each, it's better to define the map
keys statically in your configuration and place apply-time results only in
the map values.

[grayside]

Summary

We are using the random_id resource to generate a 4 character suffix as namespacing trick for new infrastructure setups. The suffix is generated when it can't be looked up from terraform state. In this PR, we're adding that suffix to use of the module terraform-google-modules/network/google. This is far from the first resource to have this suffix added.

However, we are for the first time running into a problem in conjunction with for_each, where the random_id is not resolved at apply time and terraform is not happy.

This PR's change works fine on my local instance because I have the random_id already computed in my local terraform state. It fails with clean terraform state.

As I noted below, we have some workarounds, but this doesn't seem like it should be a unique problem for this solution.

Underlying resource: https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/compute_subnetwork

[grayside]

After not finding similar issues in GitHub repos associated with the module or terraform provider, I tried running it myself and didn't find this error. Going to re-run the test on the assumption this failure was a flake.

[grayside]

The test failed again.

I found this excellent explanation: https://stackoverflow.com/a/70192949.

I see two paths forward based on information so far:

1. Maybe if we add an explicit depends_on, the random_id will be resolved before it's needed for network creation.

2. We need to shift the terraform apply to a two-step process:

   terraform apply -target random_id.suffix
   terraform apply
   

[grayside]

From further discussion, the recommended path is to remove the network module in favor of directly using the google_compute_subnetwork resource, because we're only creating a single subnet the module doesn't benefit us much, but the indirection and for_each it introduces prevents using random_id.

[glasnt]

remove the network module in favor of directly using the google_compute_subnetwork resource

I'll use this same PR, but rework to this suggestion.