Can see the peerings were provisioned in the spoke VPC but the controlling variable var.private_service_cidr has a null default and is not set anywhere
e.g. in vpc-d-shared-base-spoke in prj-d-shared-base
What's the purpose of enabling private-service-access (purportedly for accessing services like CloudSQL) if there seem to be no way to enable the resource? And then why the peering is nontheless provisioned and the project behind it?
Also the "proxy" subnets one of it in each region for each spoke VPC
In the code comments they are marked as "example" but - what's the practical use and why provisioning them is not optional?
Not to mention that the CIDRs of these proxy subnets are hardcoded e.g.
3-networks-hub-and-spoke/envs/non-production/main.tf
...
locals {
env = "non-production"
...
base_subnet_proxy_ranges = {
(local.default_region1) = "10.18.4.0/23"
(local.default_region2) = "10.19.4.0/23"
}
...
Expected behavior
There should not have been any peering and service-access provisioned (this might add up to the cost)
"Example" resources should not be created unless serving a practical purpose in the landing zone. And there should be no hardcoding.
Observed behavior
A peering and a project behind are provisioned although there is no need for CloudSQL at this stage
| Peering Name | Peered VPC | Peered project
| servicenetworking-googleapis-com | servicenetworking | vd8485225771cd5c4p-tp
This is an example deployment, this is not a module. You have the option of removing code as desired once you fork the repository. I will be closing this issue.
TL;DR
For each VPC in the spokes can see a servicenetworking peering associated with an instance of private-service-access
in 3-networks-hub-and-spoke/modules/restricted_shared_vpc/main.tf ... resource "google_service_networking_connection" "private_vpc_connection" { count = var.private_service_cidr != null ? 1 : 0 network = module.main.network_self_link service = "servicenetworking.googleapis.com" reserved_peering_ranges = [google_compute_global_address.private_service_access_address[0].name] depends_on = [module.peering] }
Can see the peerings were provisioned in the spoke VPC but the controlling variable var.private_service_cidr has a null default and is not set anywhere
e.g. in vpc-d-shared-base-spoke in prj-d-shared-base
What's the purpose of enabling private-service-access (purportedly for accessing services like CloudSQL) if there seem to be no way to enable the resource? And then why the peering is nontheless provisioned and the project behind it?
| Peering Name | Peered VPC | Peered project | servicenetworking-googleapis-com | servicenetworking | vd8485225771cd5c4p-tp
Also the "proxy" subnets one of it in each region for each spoke VPC In the code comments they are marked as "example" but - what's the practical use and why provisioning them is not optional? Not to mention that the CIDRs of these proxy subnets are hardcoded e.g. 3-networks-hub-and-spoke/envs/non-production/main.tf ... locals { env = "non-production" ... base_subnet_proxy_ranges = { (local.default_region1) = "10.18.4.0/23" (local.default_region2) = "10.19.4.0/23" } ...
Expected behavior
There should not have been any peering and service-access provisioned (this might add up to the cost)
"Example" resources should not be created unless serving a practical purpose in the landing zone. And there should be no hardcoding.
Observed behavior
A peering and a project behind are provisioned although there is no need for CloudSQL at this stage | Peering Name | Peered VPC | Peered project | servicenetworking-googleapis-com | servicenetworking | vd8485225771cd5c4p-tp
Terraform Configuration
Terraform Version
Additional information
No response