[Gerrrt]

What changed

eden (141, BloodHound CE) is declared in tofu/, so the pipeline can rebuild it. This is the first half of #1443; ragnarok follows in its own PR.

• tofu/guests.tf: a bloodhound local with eden, in a new bloodhound pool, with ADR-0081's shape as build-the-bloodhound-guest.md §0 tabulates it:
  • the OS disk, EFI disk and cloud-init drive on local-lvm, without the template's ssd flag;
  • a 32 GiB data disk on large_data as scsi1;
  • 10.0.30.41/24 with the gateway and nameserver 10.0.30.1;
  • 4 cores and 8 GiB;
  • tags bloodhound and on-demand, and onboot off;
  • user garnet, with alexander's key beside phoenix's.
• tofu/modules/guest: four new inputs, each defaulting to what every other guest has, so the other 20 guests' plans don't change: os_disk_ssd, data_disks, ipv4 and dns_servers.
• tofu/variables.tf: eden_operator_key_file, with default ~/.config/proxmox/eden-garnet.pub on phoenix.
• identities.auto.tfvars.example: an eden placeholder MAC.
• build-the-bloodhound-guest.md §1 now builds from phoenix. It gains a once-only "bring the hand-built eden into the pipeline" step, and §10's teardown is a tofu destroy.
• provision-lab-guests.md §2 gets the /pool/bloodhound grant and its row. tofu/README.md lists the guest.

Why

Item 18 of the 2026-11-11 audit: eden was a hand qm clone 901 141, outside ADR-0076's pipeline. The owner chose to declare it, and to do it before ragnarok, which waits on the gandalf provider.

One change from #1443's plan. #1443 asked for an import that plans No changes. The repo's own record (build-the-lab-domain.md, step 4 of the rebuild) shows that importing a hand-built guest always plans a replace, because a running guest's clone can't be read back. ADR-0081 makes that acceptable for eden: its graph is derived data, it has no backup, and it is "rebuilt from this repository". So the runbook goes import → plan (expect exactly one replace, plus the pool) → destroy → apply. It then continues from §2, with §11 for the new age key.

Refs #1443

Blast radius

• eden itself. When the runbook's once-only step is run, it is destroyed and rebuilt. Its graph, its Postgres data and its age key go with it, as ADR-0081 accepts. Nothing else on Saruman changes.

• The other guests: their module inputs default to their current values. If tofu fmt/validate, or the first plan on phoenix, shows a change to any other guest, that is a bug in this PR and a stop.

• Nothing happens until someone runs it on phoenix. Merging changes no host.

• No change to network segmentation or firewall rules

• No new port published to a VLAN that could not already reach the service

• No credential added outside secrets/*.sops.yaml. The new file on phoenix holds a public key.

Verification

• All four changed .tf files parse with python-hcl2.

• tofu fmt -check and tofu validate were not run here: this session has no tofu and no Docker to run it in. CI's Lint job runs both.

• ./scripts/lint.sh: passed, 7 skipped (packer, tofu ×3, ansible-lint and the editorconfig-checker container). ec was run directly on the changed files and passed.

• python3 scripts/check_docs.py: OK. check-tracked-artefacts.sh: OK.

• The real proof is on phoenix: plan -target='module.guest["eden"]' after the import must show exactly one replace plus the bloodhound pool. A plain plan must show no change to any other guest.

• make validate was not run in full: no Docker here. lint, check_docs and the artefact check above were.

• Deployed to the lab and confirmed working: not yet. The runbook's once-only step on phoenix is the deploy.

• Docs updated (docs/, service README, or docs/roadmap.md)

---

Generated by Claude Code

[Copilot]

🟡 Changes recommended

The domain rebuild would destroy BloodHound’s disks, graph, and unbacked-up age key, while the migration instructions attempt an apply before importing the existing VM.

2 open issues

• Exclude BloodHound resources from domain rebuild destroys · New
• Clarify fresh-build versus migration command order · New

What changed in this PR

This PR brings eden, the BloodHound CE guest, into the OpenTofu provisioning pipeline. It implements the eden portion of #1443; ragnarok remains separate.

Changes:

• Declares eden’s storage, networking, resources, operator key and pool.
• Extends the guest module with optional disk and network settings while preserving existing defaults.
• Documents pipeline creation, destructive migration of the hand-built guest, and teardown.

File	Description
tofu/​variables.tf	Adds eden’s operator public-key file input.
tofu/​README.md	Lists eden among pipeline-managed guests.
tofu/​modules/​guest/​variables.tf	Defines optional disk and network inputs.
tofu/​modules/​guest/​main.tf	Implements additional disks and configurable network settings.
tofu/​identities.auto.tfvars.example	Adds an eden MAC placeholder.
tofu/​guests.tf	Declares eden and passes its settings into the guest module.
docs/​runbooks/​provision-lab-guests.md	Documents the BloodHound pool permission grant.
docs/​runbooks/​build-the-bloodhound-guest.md	Replaces manual provisioning with pipeline and migration procedures.

_{Review effort: Balanced}

[Gerrrt]

Validate configs failed for a reason this PR didn't cause. check_gosu_skip.sh couldn't pull ghcr.io/immich-app/postgres because ghcr.io rate-limited the request ("error from registry: retry-after … allowed: 44000/minute"). This PR touches only tofu/ and three runbooks, not the sensitive stack. Every other step in that job passed. I've re-run the failed job once; there's no fix to port, because the cause is the registry.

Lint passed on this head, which means tofu fmt -check and tofu validate accept the new module inputs and eden's entry.

---

Generated by Claude Code