[Bug] gemini-enterprise: stage-1 apply always fails with "IP is already being used by another resource" — the stage-0 internal VIP is reserved without purpose = SHARED_LOADBALANCER_VIP

[JohnHales]

Bug Description

The blueprint splits ingress across two stages that are both meant to serve the same internal VIP: stage-0 builds the HTTP-to-HTTPS redirect on port 80, stage-1 builds the HTTPS front end on port 443. Both forwarding rules point at the single reserved internal address created in stage-0.

That address is reserved without a purpose:

# gemini-stage-0/network.tf:74-81
resource "google_compute_address" "gemini_enterprise_ip" {
  count        = var.deployment_type != "none" ? 1 : 0
  project      = var.main_project_id
  name         = "${var.prefix}-${var.deployment_type}-ip"
  region       = var.region
  subnetwork   = var.deployment_type == "internal" ? local.vpc_subnet_id : null
  address_type = local.ip_address_type      # "INTERNAL"
  # no purpose -> defaults to GCE_ENDPOINT
}

A GCE_ENDPOINT internal address can back exactly one resource. Sharing one internal IP across multiple forwarding rules requires purpose = "SHARED_LOADBALANCER_VIP". So stage-0 applies fine (its :80 rule claims the address), and stage-1 then fails 100% of the time on the :443 rule:

Error: Error waiting to create ForwardingRule: Error waiting for Creating ForwardingRule:
IP '10.2.1.2' is already being used by another resource.

  with google_compute_forwarding_rule.gemini_enterprise_forwarding_rule[0],
  on load_balancer.tf line 179

This is not a race or a stale-state problem — the two rules are simply not allowed to share a GCE_ENDPOINT address. Stage 1 creates 4 of its 5 resources (url map, HTTPS proxy, both IAP bindings) and then dies on the forwarding rule, leaving the deployment half-built.

Note the module author is aware of the purpose argument — network.tf:56 correctly sets purpose = "REGIONAL_MANAGED_PROXY" on the proxy-only subnet twenty lines earlier. It was simply never set on the VIP.

Environment and Deployment Context

• Stellar Engine Version/Commit: main at commit f64ce6cd (re-verified 2026-08-10)
• Deployment Type:
  • US Region Restricted (e.g., Access Policy constraint)
  • FedRAMP Medium
  • FedRAMP High
  • FedRAMP Moderate
  • DoD IL4
  • DoD IL5
  • Stand-alone / Custom
• FAST Stage (if applicable): N/A — this is a blueprint, not a FAST stage
  • Stage 0 (Bootstrap)
  • Stage 1 (Resource Management)
  • Stage 2 (Network Creation)
  • Stage 3 (Security and Audit)
• Affected Component:
  • blueprints/fedramp-high/gemini-enterprise/gemini-stage-0/network.tf:74-81 (the address)
  • blueprints/fedramp-high/gemini-enterprise/gemini-stage-0/load_balancer.tf:77-89 (:80 rule)
  • blueprints/fedramp-high/gemini-enterprise/gemini-stage-1/load_balancer.tf:179 (:443 rule)
• Terraform Version: 1.12.2 (pinned by deploy.sh via tfenv; the stage declares required_version >= 1.7.4)
• GCP Provider Version: hashicorp/google >= 6.21.0 (stage-0 declared constraint)

Steps to Reproduce

1. Deploy gemini-stage-0 with deployment_type = "internal" (Brownfield, shared VPC).
2. Confirm ${prefix}-http-forwarding-rule exists on port 80 bound to the reserved internal IP.
3. Run deploy.sh → Step 2 - Configure & Deploy Stage 1.
4. Apply fails on google_compute_forwarding_rule.gemini_enterprise_forwarding_rule[0] with IP '<vip>' is already being used by another resource.

Expected Behavior

Stage 0 and stage 1 both attach to the one reserved internal VIP — :80 for the redirect, :443 for the front end — and stage 1 applies cleanly.

Actual Behavior

Stage 1 creates four of its five resources (url map, HTTPS proxy, both IAP bindings) and then fails on the forwarding rule, leaving the deployment half-built. It fails on every attempt; it is not a race or a stale-state problem.

Relevant Logs and Errors

Observed live 2026-07-29 on a Brownfield / shared-VPC internal deployment:

Error: Error waiting to create ForwardingRule: Error waiting for Creating ForwardingRule:
IP '10.2.1.2' is already being used by another resource.

  with google_compute_forwarding_rule.gemini_enterprise_forwarding_rule[0],
  on load_balancer.tf line 179

Suggested Fix

Set purpose = "SHARED_LOADBALANCER_VIP" on google_compute_address.gemini_enterprise_ip when deployment_type == "internal". Note this forces address replacement on existing deployments, so the :80 forwarding rule must be replaced with it.

Alternatives Considered

Destroying the stage-0 :80 rule before applying stage-1 unblocks the apply immediately but loses the HTTP-to-HTTPS redirect the blueprint intends to provide.

Additional Context

Reproduced live 2026-07-29 on a Brownfield / shared-VPC internal deployment.