Skip to content

Commit 527fddf

Browse files
lweberrulweberru
authored
Merge pull request #39 from stackitcloud/feat/lz-namespace-service-observability-demo
feat: central/shared kubernetes platform landing zone and optional namespace creation in app landing zone
2 parents 5198fbe + 0cdb6e9 commit 527fddf

45 files changed

Lines changed: 2695 additions & 44 deletions

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

‎.gitignore‎

Lines changed: 6 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -31,6 +31,7 @@ override.tf.json
3131

3232
# Include tfplan files to ignore the plan output of command: terraform plan -out=tfplan
3333
# example: *tfplan*
34+
*tfplan*
3435

3536
# Ignore CLI configuration files
3637
.terraformrc
@@ -42,4 +43,8 @@ terraform.rc
4243
openai.token
4344
.env
4445
.env.local
45-
.cache/
46+
.cache/
47+
48+
# Local persistent E2E runtime variables (canonical for this troubleshooting phase)
49+
src/config/e2e.tfvars
50+
src/config/e2e-bootstrap.override.tfvars

‎ISSUE_41_UPDATE.md‎

Lines changed: 28 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,28 @@
1+
# Issue 41 Update Draft
2+
3+
Title suggestion:
4+
Gateway API DNS extension gap in Terraform provider: temporary record-set bridge for Envoy Gateway
5+
6+
## Summary
7+
We migrated from NGINX ingress to Envoy Gateway / Gateway API (`Gateway` + `HTTPRoute`) for the namespace demo path.
8+
9+
The remaining platform/provider gap is Terraform support for `extensions.dns.gatewayApi`.
10+
Until this is available in the provider, DNS must be managed via Terraform `stackit_dns_record_set` resources.
11+
12+
## Current stable workaround
13+
- Discover Envoy-managed LoadBalancer service endpoint in-cluster via Terraform (`kubernetes_resources` + labels).
14+
- Create DNS record set in the corresponding landing-zone DNS zone:
15+
- `A` when an IP endpoint is available.
16+
- `CNAME` when a hostname endpoint is available.
17+
- Keep record creation guarded by a precondition that requires a resolvable endpoint.
18+
19+
## Why this replaced the first workaround idea
20+
Initial workaround ideas depended on provider features that were not consistently available in OpenTofu runtime schema / behavior.
21+
The record-set bridge is now purely Terraform-managed, deterministic, and validated in apply/plan cycles.
22+
23+
## Acceptance criteria for closing this issue
24+
- Terraform provider exposes and supports `extensions.dns.gatewayApi` end-to-end for Gateway API resources.
25+
- Existing record-set bridge can be removed without losing automated DNS convergence for Gateway API listeners.
26+
27+
## Requested provider capability
28+
Please add first-class Terraform support for DNS automation based on Gateway API listeners/hostnames (`extensions.dns.gatewayApi`) so manual record-set bridging is no longer necessary.

‎PR39_REVIEW_REPLIES.md‎

Lines changed: 74 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,74 @@
1+
# PR 39 Review Replies (Copy/Paste)
2+
3+
Purpose: ready-to-post reply texts for each referenced review thread.
4+
Status basis: current branch state with validated plan/apply in E2E context.
5+
6+
## Ref 01, 02, 03 (Node pools)
7+
Implemented. We moved the default node pool model into variable defaults and kept the explicit separation between `system` and `application` pools. `allow_system_components` is only true in the `system` pool.
8+
9+
## Ref 04 (NGINX -> Gateway Controller)
10+
Implemented as an alternative with Envoy Gateway and Gateway API (`Gateway` + `HTTPRoute`).
11+
For DNS, we currently use Terraform-managed `stackit_dns_record_set` as a temporary bridge because provider-native support for `extensions.dns.gatewayApi` is still missing. This gap is tracked in Issue 41 (updated description).
12+
13+
## Ref 05 (Demo scope)
14+
Implemented. Namespace demo resources are optional and only active when demo flags are enabled. They are no longer an unavoidable default path.
15+
16+
## Ref 06 (null provider)
17+
Implemented. Active code no longer relies on `null_resource`/`hashicorp/null` for the reviewed paths.
18+
19+
## Ref 07 (Provider pinning)
20+
Implemented. Open provider constraints were replaced with planable version ranges (`~>`) across root/module provider definitions.
21+
22+
## Ref 08, 09 (Input validation location)
23+
Implemented. Input validations were moved into `variable.validation` where applicable; runtime checks are no longer used as the primary input-validation mechanism for these reviewed cases.
24+
25+
## Ref 10 (Deprecated API version)
26+
Implemented. Deprecated API usages from the reviewed scope were updated to supported versions.
27+
28+
## Ref 11 (Debug bastion module)
29+
Implemented. Debug bastion is now an isolated submodule (`modules/debug-bastion`) and integrated optionally from platform-kubernetes.
30+
31+
## Ref 12 (SNA egress routing)
32+
Implemented. Routing-table based default route via firewall next hop is modeled for SNA egress path.
33+
34+
## Ref 13 (Network file consolidation)
35+
Implemented. Relevant platform-kubernetes network files were consolidated into `2-network.tf`.
36+
37+
## Ref 14 (Naming suffix consistency)
38+
Implemented in the reviewed scope.
39+
40+
## Ref 15 (Grafana user/password outputs)
41+
Implemented with the agreed nuance: credentials are still used internally where needed for provisioning, but no longer exposed as broad root-level contract output. This keeps operation working while reducing unnecessary exposure.
42+
43+
## Ref 16, 17, 23 (SNA input simplification)
44+
Implemented. Input model uses `sna_enabled` and optional `sna_network_area_id` instead of the previous mode-string pattern.
45+
46+
## Ref 18 (Single-use local)
47+
Implemented in the reviewed scope.
48+
49+
## Ref 19 (depends_on placement)
50+
Implemented in the reviewed scope (moved to resource end for readability/style consistency).
51+
52+
## Ref 20 (Maintenance assignment)
53+
Implemented in the reviewed scope via simplified mapping.
54+
55+
## Ref 21 (SSH fallback expression)
56+
Implemented with improved readability and validation.
57+
58+
## Ref 22 (Kubernetes output usage)
59+
Implemented. Outputs were reduced to meaningful contract values; unnecessary broad/internal exposure was removed.
60+
61+
## Ref 24 (Root output contract)
62+
Implemented. Root outputs were trimmed to stable/public contract surface.
63+
64+
## Ref 25, 26 (providers.tf simplification)
65+
Implemented. Provider setup is reduced to necessary configuration for this stack.
66+
67+
## Ref 27 (Variable scope cleanup)
68+
Implemented. Variables were moved/kept according to module ownership and root API responsibilities.
69+
70+
## Ref 28 (namespace service enable semantics)
71+
Implemented. Presence of namespace-service object acts as activation signal; redundant enable semantics were removed from the reviewed API surface.
72+
73+
## Optional close-out note for PR thread
74+
All review points were addressed in code. The only non-finalized platform capability is provider-native `extensions.dns.gatewayApi`; until available, we use a Terraform-managed DNS record-set bridge (`stackit_dns_record_set`) documented in Issue 41.

‎PR39_REVIEW_TODO.md‎

Lines changed: 174 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,174 @@
1+
# PR 39 Review TODO (Arbeitsliste)
2+
3+
Quelle: Review-Kommentare aus https://github.com/stackitcloud/stackit-landing-zone/pull/39
4+
Stand: 2026-06-17
5+
6+
Hinweis zur Nutzung:
7+
8+
- Pro Thema bitte genau eine Entscheidung markieren:
9+
- `[ ] Vorschlag umsetzen`
10+
- `[ ] Alternative wählen`
11+
- Bei `Alternative wählen` bitte eure Zielvariante unter `Alternative / Notiz` ergänzen.
12+
- `Ref` verweist auf die extrahierten Review-Kommentar-IDs (1..28).
13+
14+
## Offene Themen als Checkliste (nach Bereich)
15+
16+
### Architektur und Scope
17+
18+
1. [x] Ref 05 - Kubernetes-Demo nicht fest im Landing-Zone-Terraform
19+
Review-Thema: Die Demo sollte optional sein und nicht Teil des produktionsnahen Standardpfads.
20+
Vorgeschlagene Lösung: Demo-Ressourcen aus `src/namespace-service.tf` in optionales Submodul auslagern (`demo_enabled`), Default `false`.
21+
Entscheidung: [x] Vorschlag umsetzen [ ] Alternative wählen
22+
Alternative / Notiz:
23+
24+
2. [x] Ref 11 - Debug-Bastion als eigenes Modul
25+
Review-Thema: Debug-Bastion ist fachlich ein eigener Baustein.
26+
Vorgeschlagene Lösung: `src/modules/platform-kubernetes/5-debug-bastion.tf` in Submodul `modules/debug-bastion` auslagern und optional aufrufen.
27+
Entscheidung: [x] Vorschlag umsetzen [ ] Alternative wählen
28+
Alternative / Notiz:
29+
30+
### Ingress und Security
31+
32+
3. [x] Ref 04 - NGINX Ingress durch Gateway Controller ersetzen
33+
Review-Thema: NGINX-Ingress wurde aus Security-Gründen kritisch bewertet.
34+
Vorgeschlagene Lösung: Namespace-Service-Demo auf Gateway API Controller umstellen (Gateway/HTTPRoute). Wenn nicht sofort möglich: per Feature-Flag standardmäßig deaktivieren.
35+
Entscheidung: [ ] Vorschlag umsetzen [x] Alternative wählen
36+
Alternative / Notiz: Gateway API Controller bitte mittels Envoy Gateway umsetzen
37+
38+
### Terraform Core und Provider
39+
40+
4. [x] Ref 06 - null Provider durch terraform_data ersetzen
41+
Review-Thema: `null_resource` wird nicht mehr benötigt.
42+
Vorgeschlagene Lösung: `null_resource` auf `terraform_data` migrieren und `hashicorp/null` aus `required_providers` entfernen.
43+
Entscheidung: [x] Vorschlag umsetzen [ ] Alternative wählen
44+
Alternative / Notiz:
45+
46+
5. [x] Ref 07 - Provider-Versionen planbar pinnen
47+
Review-Thema: `>=`-Constraints sind zu offen und reduzieren Vorhersagbarkeit.
48+
Vorgeschlagene Lösung: Constraints auf planbare Ranges umstellen (z. B. `~>`), danach Lockfile bewusst aktualisieren.
49+
Entscheidung: [x] Vorschlag umsetzen [ ] Alternative wählen
50+
Alternative / Notiz:
51+
52+
6. [x] Ref 25, 26 - providers.tf fachlich vereinfachen
53+
Review-Thema: Provider-Setup und Region-Check wirken unnötig komplex.
54+
Vorgeschlagene Lösung: `src/providers.tf` auf notwendige Konfiguration reduzieren, Region-Check entfernen oder in Input-Validation verlagern.
55+
Entscheidung: [x] Vorschlag umsetzen [ ] Alternative wählen
56+
Alternative / Notiz:
57+
58+
### Validierung und API-Design
59+
60+
7. [x] Ref 08, 09 - Input-Validierung an richtige Stelle verschieben
61+
Review-Thema: `check`-Blöcke wurden für Input-Validierung genutzt.
62+
Vorgeschlagene Lösung: Input-Validierung in `variable.validation` (oder gezielt `precondition`) verschieben; `check` nur für Laufzeit-/State-Prüfungen verwenden.
63+
Entscheidung: [x] Vorschlag umsetzen [ ] Alternative wählen
64+
Alternative / Notiz:
65+
66+
8. [x] Ref 28 - namespace_service.enabled vereinfachen/deprecaten
67+
Review-Thema: `enabled` ist redundant, wenn das Objekt selbst schon Aktivierung signalisiert.
68+
Vorgeschlagene Lösung: `namespace_service = null` als deaktiviert, Objekt gesetzt als aktiviert; `enabled` deprecaten und später entfernen.
69+
Entscheidung: [x] Vorschlag umsetzen [ ] Alternative wählen
70+
Alternative / Notiz:
71+
72+
9. [x] Ref 27 - Variablen-Scope bereinigen
73+
Review-Thema: Ein Variablenblock liegt laut Review im falschen Scope.
74+
Vorgeschlagene Lösung: Variable ins fachlich passende Modul verschieben; Root-Variablen nur für echte Root-API behalten.
75+
Entscheidung: [x] Vorschlag umsetzen [ ] Alternative wählen
76+
Alternative / Notiz:
77+
78+
### Kubernetes Platform, Netzwerk und Node-Pools
79+
80+
10. [x] Ref 01, 02, 03 - Default Node-Pools sauber modellieren
81+
Review-Thema: Default-Node-Pools sollten als Variable-Defaults definiert werden; Trennung in `system`/`application` wird gewünscht.
82+
Vorgeschlagene Lösung: `var.cluster.node_pools` mit strukturiertem Default, `allow_system_components = true` nur im `system`-Pool.
83+
Entscheidung: [x] Vorschlag umsetzen [ ] Alternative wählen
84+
Alternative / Notiz: separaten application node pool vorsehen.
85+
86+
11. [x] Ref 16, 17, 23 - SNA Input-Modell vereinfachen
87+
Review-Thema: `mode`-String plus zusätzliche locals gelten als unnötig.
88+
Vorgeschlagene Lösung: `sna_enabled` (bool) und optional `sna_network_area_id` als primäres Modell; `mode` deprecaten.
89+
Entscheidung: [x] Vorschlag umsetzen [ ] Alternative wählen
90+
Alternative / Notiz: Wir brauchen Dinge noch nicht deprecaten, sondern können vollständig umstellen, da wir ja noch nicht live waren.
91+
92+
12. [x] Ref 12 - SNA Egress-Routing über Firewall klarstellen
93+
Review-Thema: Ohne Routing-Tabelle könnte Internet-Traffic Firewall-Bypass haben.
94+
Vorgeschlagene Lösung: Routing-Pfad fachlich fixieren und ggf. dedizierte Routing-Tabelle + Default-Route via Firewall umsetzen.
95+
Entscheidung: [x] Vorschlag umsetzen [ ] Alternative wählen
96+
Alternative / Notiz:
97+
98+
13. [x] Ref 13 - Netzwerkdateien zusammenführen
99+
Review-Thema: `2-dns-zones.tf`, `2-network-area-membership.tf`, `2-sna-network.tf` sollen konsolidiert werden.
100+
Vorgeschlagene Lösung: Zusammenführen in `2-network.tf` als Struktur-Refactor ohne Logikänderung.
101+
Entscheidung: [x] Vorschlag umsetzen [ ] Alternative wählen
102+
Alternative / Notiz:
103+
104+
14. [x] Ref 10 - Deprecated API-Version aktualisieren
105+
Review-Thema: Verwendete API-Version wurde als deprecated markiert.
106+
Vorgeschlagene Lösung: Auf aktuelle, unterstützte Version aktualisieren und gegen Provider/API-Matrix verifizieren.
107+
Entscheidung: [x] Vorschlag umsetzen [ ] Alternative wählen
108+
Alternative / Notiz:
109+
110+
### Outputs und Verträge
111+
112+
15. [x] Ref 15 - Grafana User/Password nicht als Output
113+
Review-Thema: Zugangsdaten sollen nicht als Terraform-Output exponiert werden.
114+
Vorgeschlagene Lösung: Sensitive Outputs entfernen; Zugriff über Secrets Manager bzw. dokumentierten Abrufpfad.
115+
Entscheidung: [x] Vorschlag umsetzen [ ] Alternative wählen
116+
Alternative / Notiz:
117+
118+
16. [x] Ref 22 - Kubernetes-Output nur bei echter Nutzung
119+
Review-Thema: Output nur behalten, wenn es Downstream-Nutzung gibt.
120+
Vorgeschlagene Lösung: Nutzung nachweisen; ungenutzten Output entfernen oder klar als intern markieren.
121+
Entscheidung: [x] Vorschlag umsetzen [ ] Alternative wählen
122+
Alternative / Notiz:
123+
124+
17. [x] Ref 24 - Root Outputs auf Public Contract reduzieren
125+
Review-Thema: Teile in `src/outputs.tf` wirken ohne klaren Mehrwert.
126+
Vorgeschlagene Lösung: Outputs auf stabile Public-Contract-Schnitt minimieren; interne Felder streichen.
127+
Entscheidung: [x] Vorschlag umsetzen [ ] Alternative wählen
128+
Alternative / Notiz:
129+
130+
### Code-Style und Lesbarkeit
131+
132+
18. [x] Ref 18 - Single-use local entfernen
133+
Review-Thema: `local.effective_observability_instance_id` wird nicht wiederverwendet.
134+
Vorgeschlagene Lösung: Ausdruck inline setzen, nur mehrfach genutzte locals behalten.
135+
Entscheidung: [x] Vorschlag umsetzen [ ] Alternative wählen
136+
Alternative / Notiz:
137+
138+
19. [x] Ref 19 - depends_on ans Ressourcenende
139+
Review-Thema: Lesbarkeit nach HashiCorp-Style.
140+
Vorgeschlagene Lösung: Betroffene Ressourcen so umordnen, dass `depends_on` am Ende steht.
141+
Entscheidung: [x] Vorschlag umsetzen [ ] Alternative wählen
142+
Alternative / Notiz:
143+
144+
20. [x] Ref 20 - Maintenance-Zuweisung vereinfachen
145+
Review-Thema: 1:1 Mapping ist unnötig komplex.
146+
Vorgeschlagene Lösung: Direktzuweisung `maintenance = var.cluster.maintenance`, sofern Typen kompatibel sind.
147+
Entscheidung: [x] Vorschlag umsetzen [ ] Alternative wählen
148+
Alternative / Notiz:
149+
150+
21. [x] Ref 21 - Ausdruck für SSH-Key-Fallback vereinfachen
151+
Review-Thema: Der `try(trimspace(...), file(...))`-Ausdruck kann lesbarer sein.
152+
Vorgeschlagene Lösung: Ausdruck gemäß Vorschlag refactoren und mit Input-Validation kombinieren.
153+
Entscheidung: [x] Vorschlag umsetzen [ ] Alternative wählen
154+
Alternative / Notiz:
155+
156+
22. [x] Ref 14 - Naming-Konvention für Suffixe vereinheitlichen
157+
Review-Thema: Suffix `-obs` ist inkonsistent.
158+
Vorgeschlagene Lösung: Einheitliche Suffix-Strategie festlegen (`ohne`, `-default` oder `-common`) und referenzkonsistent umsetzen.
159+
Entscheidung: [x] Vorschlag umsetzen [ ] Alternative wählen
160+
Alternative / Notiz:
161+
162+
## Vorschlag für Umsetzung in Wellen
163+
164+
1. **Welle A (sicher, low risk)**: 18, 19, 20, 21, 14, 13
165+
2. **Welle B (API/Contract Changes)**: 01/02/03, 16/17/23, 28, 24, 27
166+
3. **Welle C (Security/Architecture)**: 04, 05, 11, 12, 15, 22, 25/26, 06, 07, 10
167+
168+
## Entscheidungsprotokoll
169+
170+
- Datum: 17.06.2026
171+
- Teilnehmer: Lukas Weberruß
172+
- Beschluss pro Ref-Gruppe: Alle Themen werden umgesetzt. Bei Ref 04 erfolgt die Umsetzung als Gateway API Controller mit Envoy Gateway.
173+
- Offene Fragen:
174+
- Nächster Implementierungs-PR:

‎README.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -24,4 +24,4 @@ Contributions are welcome! Please feel free to submit a Pull Request.
2424

2525
## 📄 License
2626

27-
This project is licensed under the Apache 2.0 License - see the [LICENSE](LICENSE) file for details.
27+
This project is licensed under the Apache 2.0 License - see the [LICENSE](LICENSE) file for details.

0 commit comments

Comments
 (0)