Problem
Regional platform Kubernetes deployments exist, but namespace services are still wired to the non-regional module maps. Configurations with regional clusters therefore cannot automatically target their matching cluster for namespace onboarding.
Verified by source inspection on main at 2bb7c755692674ad619ffc46a0a17a781f019106. This is independent of private API reachability: it also affects publicly reachable regional clusters. No cloud apply was performed for this report.
Evidence
- providers.tf selects
one(keys(module.platform_kubernetes)) and configures the shared Kubernetes/Helm provider from that one non-regional cluster.
- main.tf uses
platform_kubernetes_eu01/eu02 and landing_zone_eu01/eu02 when regional connectivity is selected; the non-regional maps are empty in that mode.
- _landing-zone-kubernetes.tf still resolves project/DNS/Secrets Manager outputs through
module.landing_zone[...] and checks for a single non-regional platform cluster.
Desired behavior
Explicitly associate each namespace service with a supported platform cluster/region and resolve project outputs and provider instances accordingly. Until that is implemented, reject unsupported regional namespace combinations early with an actionable validation message.
Acceptance criteria
Related: #35 (original platform/namespace capability), #63 (regional infrastructure), #37 (separate private-endpoint reachability requirement). Resolving #37 alone does not fix the module/provider selection described here.
Problem
Regional platform Kubernetes deployments exist, but namespace services are still wired to the non-regional module maps. Configurations with regional clusters therefore cannot automatically target their matching cluster for namespace onboarding.
Verified by source inspection on
mainat2bb7c755692674ad619ffc46a0a17a781f019106. This is independent of private API reachability: it also affects publicly reachable regional clusters. No cloud apply was performed for this report.Evidence
one(keys(module.platform_kubernetes))and configures the shared Kubernetes/Helm provider from that one non-regional cluster.platform_kubernetes_eu01/eu02andlanding_zone_eu01/eu02when regional connectivity is selected; the non-regional maps are empty in that mode.module.landing_zone[...]and checks for a single non-regional platform cluster.Desired behavior
Explicitly associate each namespace service with a supported platform cluster/region and resolve project outputs and provider instances accordingly. Until that is implemented, reject unsupported regional namespace combinations early with an actionable validation message.
Acceptance criteria
Related: #35 (original platform/namespace capability), #63 (regional infrastructure), #37 (separate private-endpoint reachability requirement). Resolving #37 alone does not fix the module/provider selection described here.