Multicloud Module Repos — Overview
Cogrion provisions a tenant's network + Kubernetes cluster through two genuinely different operators, and the repo layout follows that split rather than collapsing everything into one toolchain.
The two paths
Automated path — Terraform, control-plane-driven
terraform-cogrion-aws-eks-managed-node-group replaces the old two-module split (terraform-workspace-infra-aws's workspace-cluster + workspace-cluster-bootstrap, which talked to each other via a cross-state data.terraform_remote_state read). The new repo combines cluster + bootstrap into one module, one tofu state.
- Driven by
control-plane's Temporal orchestration (aws.provider.ts'sprepareTfVars,stackInfra.activities.ts) - Runs under the
cogrion-automation-hubrole chain — no human credentials in the loop - Registered in
control-plane's catalog as theaws-eks-managed-node-groupresource type, reachable through a real workspace-creation flavor - Consolidating into one state removes a destroy-ordering bug class structurally: the old split's cross-state read could throw when a dependency's
ResourceStatewas missing (e.g. after a partial/failed apply) instead of falling back to empty outputs for destroy
Manual/interactive path — CLI, customer- or ops-driven
cogrion-cli replaces cogrion-bootstrap. It's a Typer/Rich/Questionary CLI (auth, cluster, deploy command groups) following the Vercel/gh CLI UX pattern — clean nesting, --json for CI, interactive prompts, spinners for long cloud ops.
- Used by a human (BYOC customer or a Cogrion operator) to connect to and operate a cluster outside the control-plane's automated flow
- Runs under whatever credentials the operator has locally — a different trust boundary than the automation-hub chain
- Next real work: porting
cogrion-bootstrap's register/helm/addons/provider logic intocluster connectanddeploy run
Why two repos, not one
The Terraform module and the CLI aren't parallel implementations of the same thing — they serve different operators against different trust boundaries:
| Automated path | Manual path | |
|---|---|---|
| Repo | terraform-cogrion-aws-eks-managed-node-group | cogrion-cli |
| Predecessor it replaces | terraform-workspace-infra-aws | cogrion-bootstrap |
| Operator | control-plane's Temporal workers | A human at a terminal |
| Credentials | cogrion-automation-hub role chain (SSO → hub role → cross-account role) | Operator's own (customer or Cogrion ops) |
| Trigger | Workspace-creation flavor in control-plane's catalog | Explicit CLI invocation |
| State | Terraform/tofu state | None — imperative, re-runnable |
Combining them into one tool would mean either running Temporal-orchestrated infrastructure changes under a human's ad hoc credentials, or making a human-facing CLI depend on the control-plane's internal orchestration — both blur a boundary that's deliberately kept sharp. Each side modernizes its own predecessor independently instead.
This same reasoning is what the module-combination rule in Module Catalog generalizes for splitting/combining Terraform modules within the automated path, across clouds.