openova/clusters
e3mrah 25f14469d3
fix(provisioner): map wizard's three-mode domain selector to tofu's binary pool/byo enum (#1069)
Caught live on omantel.biz re-provision (deploymentId ab0bf689620f4102):
tofu plan failed at exit 1 with:

  Error: Invalid value for variable
    on variables.tf line 296:
   296: variable "domain_mode" {
      ├────────────────
      │ var.domain_mode is "byo-manual"
    Domain mode must be 'pool' or 'byo'.

The wizard's StepDomain has three options (pool / byo-manual /
byo-api) so the UX can branch the operator into the right flow:

  - pool:        OpenOva owns the parent zone via Dynadot+PDM
  - byo-manual:  operator pastes NS records into their registrar
  - byo-api:     operator's registrar API drives NS automatically

The OpenTofu module's `variable "domain_mode"` validation only
accepts the binary pool/byo distinction — from the cloud-infra layer
(Hetzner servers, network, LB) NONE of those wizard distinctions
matter; tofu only needs to know whether to call Dynadot at apply
time. The three-mode wizard value was being written verbatim to the
tfvars without mapping.

Add `mapDomainModeForTofu(wizardMode)` helper:
  - "pool"      → "pool"
  - "byo-manual"→ "byo"
  - "byo-api"   → "byo"
  - empty       → "byo"  (test path that doesn't set the field)

Bump chart 1.4.83 → 1.4.84.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-07 11:26:50 +04:00
..
_template fix(provisioner): map wizard's three-mode domain selector to tofu's binary pool/byo enum (#1069) 2026-05-07 11:26:50 +04:00
contabo-mkt/tenants provision: deploy tenant e2e-wp-test (plan: m, apps: 1) 2026-05-06 02:23:14 +04:00
omantel.omani.works fix(bp-trivy): node-collector tolerates control-plane taint (closes #769) (#772) 2026-05-04 17:38:29 +02:00
otech.omani.works fix(bp-trivy): node-collector tolerates control-plane taint (closes #769) (#772) 2026-05-04 17:38:29 +02:00