Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make optional the deployment of "example' resources adding up to the cost and complexity #1182

Closed
mromascanu123 opened this issue Apr 3, 2024 · 2 comments
Labels
bug Something isn't working

Comments

@mromascanu123
Copy link

mromascanu123 commented Apr 3, 2024

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 v1.6.0
on linux_amd64

Terraform Version

Terraform v1.6.0
on linux_amd64

Additional information

No response

@mromascanu123 mromascanu123 added the bug Something isn't working label Apr 3, 2024
@fmichaelobrien
Copy link
Contributor

@sleighton2022
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants