Give CD its own Incus project #1638

New issue

Open

opened 2026-09-01 21:19:20 +02:00 by kiara · 0 comments

kiara commented

2026-09-01 21:19:20 +02:00

Owner

CD puts every Incus instance in the default project.

core/effects/tf/incus/common.nix:667 sets project = "default". That is the only place the value comes from. The graph gives it to the runners, and the runner scripts already read it as a variable with a default fallback:

core/effects/incus/run.sh
core/effects/tf/incus/host/await-incus.sh
core/effects/tf/incus/host/bridge-ip.sh
core/effects/tf/incus/host/register-ek.sh
core/effects/tf/incus/host/retire-ek.sh
core/effects/tf/incus/shared-store-state.sh

The plumbing thus accepts a different project. Only the value is constant.

Why a project of its own

Blast radius. In the default project, incus list and incus delete on the hypervisor show CD's instances together with every other instance on the host. A project makes a boundary that a person can see before they do a destructive command.
Names. Instance names must be unique in a project. A project of its own lets CD keep short names with no risk of a clash with an instance that a person made by hand.
Limits. Incus applies resource limits (limits.memory, limits.disk, ...) per project. While the instances stay in default, there is no way to cap what CD uses.

A project is not an access boundary today. Incus 7.0 LTS has no fine-grained authorization, so the deploy identity is an admin of the full server. This is an organizational and blast-radius boundary only.

Work

Make the project name an input of the graph, in place of the constant at common.nix:667.
Make the project (an incus_project resource) before the instances, and order the instances after it.
Move the instances that are live now, or make them again.

Step 3 is the risky one. A project change is not in place: incus move --project moves a stopped instance, and the OpenTofu state must follow the new resource addresses. A -plan on a dev host shows whether OpenTofu wants to move the instances or to replace them.

Assisted-by: Claude:claude-opus-5

CD puts every Incus instance in the `default` project. `core/effects/tf/incus/common.nix:667` sets `project = "default"`. That is the only place the value comes from. The graph gives it to the runners, and the runner scripts already read it as a variable with a `default` fallback: - `core/effects/incus/run.sh` - `core/effects/tf/incus/host/await-incus.sh` - `core/effects/tf/incus/host/bridge-ip.sh` - `core/effects/tf/incus/host/register-ek.sh` - `core/effects/tf/incus/host/retire-ek.sh` - `core/effects/tf/incus/shared-store-state.sh` The plumbing thus accepts a different project. Only the value is constant. ## Why a project of its own - Blast radius. In the `default` project, `incus list` and `incus delete` on the hypervisor show CD's instances together with every other instance on the host. A project makes a boundary that a person can see before they do a destructive command. - Names. Instance names must be unique in a project. A project of its own lets CD keep short names with no risk of a clash with an instance that a person made by hand. - Limits. Incus applies resource limits (`limits.memory`, `limits.disk`, ...) per project. While the instances stay in `default`, there is no way to cap what CD uses. A project is not an access boundary today. Incus 7.0 LTS has no fine-grained authorization, so the deploy identity is an admin of the full server. This is an organizational and blast-radius boundary only. ## Work 1. Make the project name an input of the graph, in place of the constant at `common.nix:667`. 2. Make the project (an `incus_project` resource) before the instances, and order the instances after it. 3. Move the instances that are live now, or make them again. Step 3 is the risky one. A project change is not in place: `incus move --project` moves a stopped instance, and the OpenTofu state must follow the new resource addresses. A `-plan` on a dev host shows whether OpenTofu wants to move the instances or to replace them. Assisted-by: Claude:claude-opus-5

kiara added a new dependency

2026-10-01 17:47:57 +02:00

#224 automated dev-ops workflows