terraform-patternslisted

# Terraform Patterns for Observability Backends ## Module Shape (all backends) Every generated module has exactly three files: - `main.tf` — all resources + provider block - `variables.tf` — all input variables - `outputs.tf` — key output values (dashboard URL, monitor IDs, SLO IDs) Header comment required in every `main.tf`: ```hcl # Generated by otel-as-code v0.1.0 on YYYY-MM-DD. # Re-run /otel-backend <vendor> to regenerate. # Drift detection: v2 roadmap. ``` Run `terraform fmt` and `terraform validate` immediately after writing the files. Emit the exact commands the user should run next (init, plan, apply) as a post-generation note. ### Service name → resource identifiers (sanitize, but ONLY in identifier positions) `service.name` is frequently an npm-scoped package name like `@myorg/web` (from `package.json#name`, confidence 0.97) — `@` and `/` are invalid in most resource identifiers. `terraform validate` does NOT catch this (the invalid string is inside an embedded YAML / a `uid` the provider accepts as an opaque string), so it only surfaces at `apply` against a live account. Derive a sanitized slug and use it in identifier positions: ```hcl locals { service_slug = trim(replace(lower(var.service_name), "/[^a-z0-9]+/", "_"), "_") } ``` - **Sanitize (use `local.service_slug`)** wherever the name becomes an *identifier*: a Grafana dashboard `uid` / rule-group `name`, a Prometheus/Dash0 `alert:` name, a Kubernetes `metadata.name`, any slug. Pick the separator