Skip to content

Support explicit regional cluster targeting for landing-zone namespace services #80

Description

@lweberru

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

  • Namespace services can explicitly target supported regional clusters without accidental cross-cluster placement.
  • Landing-zone outputs resolve from the matching regional module instance.
  • Kubernetes/Helm operations use the selected cluster's provider context.
  • Missing/ambiguous cluster references fail before resource operations.
  • Plan tests cover public eu01/eu02 targets and preserve the existing single-cluster behavior.
  • Document provider-wiring and deployment-phase constraints.

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.

Activity

  1. added
    area:acceleratorAccelerator Terraform/OpenTofu roots, modules and examples
    priority:p2Important improvement; schedule after P1 and prerequisites
    effort:lArchitecture, lifecycle or multiple systems; split before implementation
    bugSomething isn't working
    on Oct 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:acceleratorAccelerator Terraform/OpenTofu roots, modules and examplesbugSomething isn't workingeffort:lArchitecture, lifecycle or multiple systems; split before implementationpriority:p2Important improvement; schedule after P1 and prerequisites

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions