Bug Description
Three declared variables are never referenced anywhere in the blueprint's .tf. core_project_id (variables.tf line 23) and subnetwork_name (line 194) both have no default (required), so users are forced to supply values that do nothing — subnetwork_name even carries a tfvars-sample comment ("# Must already exist") implying it drives resource lookup, which it doesn't. google_compute_global_address_name (line 74) has a default and is silently unused. The cloudsql-instance module's PSA connectivity is resolved at the VPC level via psa_config.private_network, not subnet-scoped, so nothing in the resource graph ever needed subnetwork_name.
Environment and Deployment Context
- Stellar Engine Version/Commit:
main at commit 3728fc98 - Deployment Type:
- FAST Stage (if applicable): N/A — blueprint
- Affected Component:
blueprints/il5/postgresql/variables.tf (lines 23, 74, 194), terraform.tfvars.sample, README variable table - Terraform Version: 1.15.7
- GCP Provider Version:
hashicorp/google 6.50.0
Steps to Reproduce
grep -rn "var.core_project_id\|var.google_compute_global_address_name\|var.subnetwork_name" \
blueprints/il5/postgresql/
# → no matches
Expected Behavior
Declared variables — especially required ones — are consumed by a resource or module.
Actual Behavior
None of the three is referenced. Two are mandatory no-op inputs; all three appear in terraform.tfvars.sample and/or the README variable table, actively instructing users to populate values with no effect.
Relevant Logs and Errors
N/A — no runtime error; the inputs are silently discarded.
Additional Context
Fix: remove all three variables and their sample/README references, or wire them to the resources they were presumably intended for. blueprints/fedramp-high/postgresql is a symlink to this blueprint, so both FRH and IL5 consumers see the same misleading inputs. The same declared-but-never-read pattern exists at the FAST stage level (3-securitytenant_accounts) — filed separately.
Bug Description
Three declared variables are never referenced anywhere in the blueprint's
.tf.core_project_id(variables.tf line 23) andsubnetwork_name(line 194) both have no default (required), so users are forced to supply values that do nothing —subnetwork_nameeven carries a tfvars-sample comment ("# Must already exist") implying it drives resource lookup, which it doesn't.google_compute_global_address_name(line 74) has a default and is silently unused. Thecloudsql-instancemodule's PSA connectivity is resolved at the VPC level viapsa_config.private_network, not subnet-scoped, so nothing in the resource graph ever neededsubnetwork_name.Environment and Deployment Context
mainat commit3728fc98blueprints/il5/postgresql/variables.tf(lines 23, 74, 194),terraform.tfvars.sample, README variable tablehashicorp/google6.50.0Steps to Reproduce
Expected Behavior
Declared variables — especially required ones — are consumed by a resource or module.
Actual Behavior
None of the three is referenced. Two are mandatory no-op inputs; all three appear in
terraform.tfvars.sampleand/or the README variable table, actively instructing users to populate values with no effect.Relevant Logs and Errors
N/A — no runtime error; the inputs are silently discarded.
Additional Context
Fix: remove all three variables and their sample/README references, or wire them to the resources they were presumably intended for.
blueprints/fedramp-high/postgresqlis a symlink to this blueprint, so both FRH and IL5 consumers see the same misleading inputs. The same declared-but-never-read pattern exists at the FAST stage level (3-securitytenant_accounts) — filed separately.