continuous-intelligence/acdl
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 128 Wiki Activity

feat(P34): decommission alias + CMDB validation (REQ-92, REQ-93, REQ-94)

Browse Source 
---ci---
project: acdl
phase: 34
milestone: v1.8
status: execute
---/ci---

- DynamoDB acdl-change-requests table added to terraform/platform/main.tf
  (PK changeRequestId, SK submittedAt, SSE via CMK, PITR).
- validate_change_request Lambda action added to contract_ingestor.py:
  queries CMDB, asserts status=approved + consumerRepo match.
- decommission_transform() added to contract_resolver.py: zeroes all
  counts (desired_count, min/max_capacity) + sets deletion_protection=false.
- Decommission mode added to deploy pipeline + both deploy workflows
  (mode: decommission + changeRequestId input). Byte-identical.
- run_platform.sh --decommission flag: validates CR, resolves with
  deletion_protection=false (step 1), then decommission_transform
  (step 2). HITL SRE gates documented.
- docs/consumer-guide.md: new "Decommissioning a stack" section with
  CR request, trigger, 2-step HITL SRE gates, CMK deletion window, uptime.

Tests: +14 (318 -> 332). All pass.
This commit is contained in:
Jon Chery
2026-07-22 22:18:28 +00:00
parent 491ba78768
commit 134f85d2df
10 changed files with 458 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/consumer-guide.md
+58 -1
View File
@@ -319,4 +319,61 @@ per-module extension points. Common examples:
| Environments | [environments/](environments/) | Platform-managed environments + onboarding. |
| Versioning | [pipeline/versioning](pipeline/versioning) | The `uses:` tag + module versioning. |
| Platform README | `README.md` | How the platform works + how to run the platform repo locally. |
| Credentials & zero-trust | `README.md#credentials--zero-trust` | The OIDC/ABAC default + static-key override model. |
| Credentials & zero-trust | `README.md#credentials--zero-trust` | The OIDC/ABAC default + static-key override model. |
## Decommissioning a stack
When a consumer needs to tear down a deployed stack, the platform provides
a **decommission mode** on the same deploy pipeline. The decommission
process is a 2-step pipeline with **HITL SRE gates** to prevent accidental
destruction:
1. **Request a change request (CR):** Contact the platform team to create a
change request in the platform CMDB (DynamoDB `acdl-change-requests`
table). The CR must be approved before decommission can proceed. The CR
includes the consumer repo, contract ID, and the reason for decommission.
2. **Trigger decommission:** Update the consumer's deploy workflow call to
use `mode: decommission` with the `changeRequestId` input:
```yaml
uses: acdl/.github/workflows/deploy.yml@v1.8
with:
contract: .acdl/contract.yaml
mode: decommission
changeRequestId: "CR-2026-001"
```
3. **Step 1 — Disable deletion protection (HITL SRE gate):** The pipeline
validates the CR ID against the CMDB (status must be `approved`). Then
it resolves the contract with `deletion_protection: false` injected into
all resources and runs `terraform plan` + `terraform apply`. This
removes the `prevent_destroy` lifecycle meta-argument from all resources.
**An SRE must approve this step** via the GitHub environment
`decommission-gate-sre`.
4. **Step 2 — Zero counts + destroy (HITL SRE gate):** The pipeline applies
`decommission_transform` which sets all scalable counts to 0
(`desired_count=0`, `min_capacity=0`, `max_capacity=0`) and
`deletion_protection=false` on all resources. Then it runs
`terraform plan` + `terraform apply` which destroys all resources (now
that deletion protection is off and counts are zeroed). **A second SRE
must approve this step** via the GitHub environment
`decommission-destroy-sre`.
5. **Confirmation:** The pipeline confirms the stack is destroyed
(terraform state is empty for the stack).
### What happens to the per-stack CMK?
The per-stack CMK is not immediately destroyed — it enters a deletion
window (default 30 days, configurable via the `deletion_window_days` input).
This ensures any encrypted data can still be decrypted during the deletion
window if needed. The CMK is permanently deleted after the window expires.
### What happens to the uptime monitoring?
The uptime monitoring stack (deployed with separate state) is not
automatically destroyed by the decommission. It must be destroyed
separately (or left running to monitor the decommissioned stack's
endpoints going dark).