fediversity/fediversity

Watch

Fork 10

different deployment methods supported in panel #723

New issue

Open

opened 2026-02-10 13:02:17 +01:00 by kiara · 3 comments

kiara commented

2026-02-10 13:02:17 +01:00

Owner

ensure panel supports as first-class citizens each our deployment effects (ssh-hosts, tf-hosts, tf-incus-hosts), for either offering runtime-specific Nix configuration (our existing schema-generated form) as well as a way to pass runtime-specific settings such as Incus credentials
- given each such deployment method may similarly expose a schema (??), we could maybe do a schema-generated form to select deployment method as well - tho for each of them we might want to not directly expose the nixos-configuration sub-option, given that's the bit we've already had covered using our existing form.
~~long-term, we could extend this to support various NixOS deployment methods~~

- [ ] ensure `panel` supports as first-class citizens each our deployment effects (`ssh-hosts`, `tf-hosts`, `tf-incus-hosts`), for either offering [runtime-specific Nix configuration](https://git.fediversity.eu/Fediversity/meta/src/commit/7b828b497d3a7dff7ae84bf6c22ccf5063718ca8/architecture-docs/interactions.mmd#L46) (our existing schema-generated form) as well as a way to pass runtime-specific settings such as Incus credentials - given each such deployment method may similarly expose a schema (??), we could maybe do a schema-generated form to select deployment method as well - tho for each of them we might want to not directly expose the nixos-configuration sub-option, given that's the bit we've already had covered using our existing form. - ~long-term, we could extend this to support [various](https://nix.dev/tutorials/nixos/) NixOS [deployment](https://github.com/nix-community/nixos-generators) methods~

kiara added the

type: task

5 points

labels

2026-02-10 13:02:17 +01:00

kiara referenced this issue

2026-02-14 15:45:22 +01:00

panel allows specifying SSH key #383

kiara added a new dependency

2026-02-14 16:01:50 +01:00

#289 key features improving user experience supported

kiara referenced this issue

2026-02-14 16:05:34 +01:00

key features improving user experience supported #289

kiara referenced this issue

2026-06-08 16:28:30 +02:00

update or remove deployments #180

kiara self-assigned this

2026-06-08 16:48:20 +02:00

kiara referenced this issue

2026-06-08 21:15:50 +02:00

feat(panel): operator deployment-method selector + config-source pin (#723) #1071

kiara added the

ambition

front-end

label

2026-06-16 23:23:59 +02:00

kiara commented

2026-06-19 18:32:12 +02:00

Author

Owner

#1071 explores the challenges in this ambition

kiara commented

2026-06-20 19:16:14 +02:00

Author

Owner

how #972's insights inform #723 / #1071

#723 asks: panel should configure each deployment method (ssh-hosts, tf-hosts, tf-incus-hosts) as a first-class citizen — both their runtime-specific Nix config and runtime settings (Incus creds etc.). #1071 is the WIP that hit the wall and named it: "our UI cannot trivially configure a full nixos configuration ... nixos configurations consist of modules, which, as functions, cannot be trivially serialized." That is the same wall #972 hit.

The two issues are the same seam viewed from opposite trust directions:

	#972 (deploying vs deployed)	#723/#1071 (panel configures methods)
Question	which side owns the method selector + provider data?	how does the operator set method config from the UI?
Wall	method (`deployment_attribute`) is pinned with the config but is the provider's concern	a full nixos configuration / module can't cross the API as data
Root cause	method and config are coupled in one tree, but owned by different parties	same — the form can configure the data-model `configuration`, but not the method's module-shaped options (`nodes`, `ssh`)

So the boundary section already answers #1071's open design question. Three things carry over directly:

1. The config/method cut #972 ratified is exactly the cut #1071 needs. #972 establishes: the config-as-data (data model { enable, applications, ... }) is one thing; the method binding (which devShell, which executable, the TF_VAR_*/INCUS_HOST env) is a separate, provider-current thing. #1071 independently rediscovered this — its narrow first cut injects TF_VAR_*/INCUS_HOST/TF_HTTP_ADDRESS "overriding eval-time-baked Nix values without re-evaluating Nix." That is precisely #972's "provider-current DeployConfig, fed to the pinned tree, no foreign eval." #1071 built half the boundary already.

2. #1071's "can't configure a full nixos configuration" is the data-only-override expressiveness limit, verbatim. My spec's three-contract comparison says: data-only override can't introduce a new module (a module is a function, not data) — fine for settings skew, useless for new apps/methods. #1071 hits exactly that: runtime settings (Incus host/port — data) go through fine; the nixos-configuration / nodes submodule (module-shaped) does not. The spec already names why and the way out: import-by-path via a stable entry attribute, allowlist-gated. #1071's two proposed escapes ("rethink data-model.nix's configuration", "expose setups via evalOption as proper modules") are both attempts at that same attribute-addressable seam.

3. The #1097 allowlist re-ranking resolves #1071's parting worry. #1071 ends: "we may want to further consider the design/security considerations of exposing effect configuration options over the REST API." My re-evaluation answers it — the allowlist already bounds which trees may be evaluated, so exposing method config over the API is the same trust class as the deploy it gates. Settings (#1071's first cut) need no eval at all; module-shaped method config rides the allowlist-gated import-by-path. The security question #1071 left open is the one #972 closed.

The unifying frame: #972 wants the method selector to stop being frozen by the operator's pin; #723/#1071 wants the method config to be settable per-deployment from the UI. Both resolve the same way — separate the method binding from the config tree, address the config tree by a stable attribute, and let the allowlist (not "never eval") carry the trust. #1071's "deployment method that just exposes plain nixos configurations, plugged in wherever" (your earlier phrasing) is the method-agnostic seam the spec notes already half-exists in default.nix's nixosConfigurations.

<details> <summary> how #972's insights inform #723 / #1071 </summary> **#723** asks: panel should configure each deployment method (`ssh-hosts`, `tf-hosts`, `tf-incus-hosts`) as a first-class citizen — both their runtime-specific Nix config *and* runtime settings (Incus creds etc.). **#1071** is the WIP that hit the wall and named it: "our UI cannot trivially configure a full nixos configuration ... nixos configurations consist of modules, which, as functions, cannot be trivially serialized." That is *the same wall* #972 hit. The two issues are the **same seam viewed from opposite trust directions**: | | #972 (deploying vs deployed) | #723/#1071 (panel configures methods) | | ---------- | --------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | Question | which side owns the *method selector* + *provider data*? | how does the operator *set* method config from the UI? | | Wall | method (`deployment_attribute`) is pinned with the config but is the provider's concern | a full nixos configuration / module can't cross the API as data | | Root cause | **method and config are coupled in one tree, but owned by different parties** | **same** — the form can configure the data-model `configuration`, but not the method's module-shaped options (`nodes`, `ssh`) | So the boundary section already answers #1071's open design question. Three things carry over directly: **1. The config/method cut #972 ratified is exactly the cut #1071 needs.** #972 establishes: the *config-as-data* (data model `{ enable, applications, ... }`) is one thing; the *method binding* (which devShell, which `executable`, the `TF_VAR_*`/`INCUS_HOST` env) is a separate, provider-current thing. #1071 *independently rediscovered* this — its narrow first cut injects `TF_VAR_*`/`INCUS_HOST`/`TF_HTTP_ADDRESS` "**overriding eval-time-baked Nix values without re-evaluating Nix**." That is precisely #972's "provider-current `DeployConfig`, fed to the pinned tree, no foreign eval." #1071 built half the boundary already. **2. #1071's "can't configure a full nixos configuration" is the data-only-override expressiveness limit, verbatim.** My spec's three-contract comparison says: data-only override can't introduce a new module (a module is a function, not data) — fine for *settings skew*, useless for *new apps/methods*. #1071 hits exactly that: runtime *settings* (Incus host/port — data) go through fine; the *nixos-configuration / `nodes` submodule* (module-shaped) does not. The spec already names why and the way out: **import-by-path via a stable entry attribute**, allowlist-gated. #1071's two proposed escapes ("rethink `data-model.nix`'s `configuration`", "expose setups via `evalOption` as proper modules") are both attempts at that same attribute-addressable seam. **3. The #1097 allowlist re-ranking resolves #1071's parting worry.** #1071 ends: "we may want to further consider the design/security considerations of exposing effect configuration options over the REST API." My re-evaluation answers it — the allowlist already bounds *which trees* may be evaluated, so exposing method config over the API is the same trust class as the deploy it gates. Settings (#1071's first cut) need no eval at all; module-shaped method config rides the allowlist-gated import-by-path. The security question #1071 left open is the one #972 closed. **The unifying frame**: #972 wants the *method selector* to stop being frozen by the operator's pin; #723/#1071 wants the *method config* to be settable per-deployment from the UI. Both resolve the same way — **separate the method binding from the config tree, address the config tree by a stable attribute, and let the allowlist (not "never eval") carry the trust.** #1071's "deployment method that just exposes plain nixos configurations, plugged in wherever" (your earlier phrasing) *is* the method-agnostic seam the spec notes already half-exists in `default.nix`'s `nixosConfigurations`. <details>

kiara referenced this issue from a commit

2026-06-20 19:26:22 +02:00

docs(api): cross-link the #972 boundary to the panel-side #723/#1071

kiara referenced this issue

2026-06-21 10:22:29 +02:00

feat(tf-incus): deploy via incus exec, drop deployment SSH #1112

kiara referenced this issue from a commit

2026-06-21 10:22:48 +02:00

feat(tf-incus): deploy via `incus exec`, drop deployment SSH (#1112)

kiara commented

2026-06-21 10:27:30 +02:00

Author