fediversity/fediversity

Watch

Fork 10

NixOS modules' options exposed #195

New issue

Open

opened 2025-02-24 11:54:55 +01:00 by kiara · 3 comments

kiara commented

2025-02-24 11:54:55 +01:00

Owner

As a Fediversity user,
I want Fediversity to expose NixOS service modules' configuration options,
so that I may better control my deployments.

notes

Any options exposed to the user may increase the risk of backward-incompatible changes, see #629. Moreover, migrating those exposed thru settings may need the applications' schemas (#627) to migrate.
Potential copes (may not scale well) against migrations include:
- patching needed configuration options from build to run-time
- minimize exposed options in favor of hard-coding sane defaults
  - to facilitate this approach: using abstractions, including contracts (#369) or custom ones

implementation notes

may need better conversion from nix option modules (#626).
definition of done: our currently implemented applications (can) expose their full nixos modules in the form, or whatever subsets thereof could make sense in our setting (#1245).
- NixOS modules are exposed as module-schema-generated JSON-Schema build by flake attribute core#frontend-configuration-schema as exposed thru our existing REST end-point, based on data-model.nix's front-end configurations which exposes applications' operator-facing options.
- used nixpkgs revision is our nixpkgs pin in npins/sources.json as normal, i.e. different versions (relevant in #100) remain out of scope here
- changing implementations of module-schema we handle by accordingly updating nix-module-form to account for these changes

**As** a Fediversity user, **I want** Fediversity to expose NixOS service modules' configuration options, **so that** I may better control my deployments. ## notes - Any options exposed to the user may increase the risk of backward-incompatible changes, see #629. Moreover, migrating those exposed thru `settings` may need the applications' schemas (#627) to migrate. - Potential copes (may not scale well) against migrations include: - patching needed configuration options from build to run-time - minimize exposed options in favor of hard-coding sane defaults - to facilitate this approach: using abstractions, including contracts (#369) or custom ones ### implementation notes - may need better conversion from nix option modules (#626). - **definition of done**: our currently implemented applications (can) expose their full nixos modules in the form, or whatever subsets thereof could make sense in our setting (#1245). - NixOS modules are exposed as `module-schema`-generated JSON-Schema build by flake attribute `core#frontend-configuration-schema` as exposed thru our existing REST end-point, based on `data-model.nix`'s front-end configurations which exposes applications' operator-facing options. - used nixpkgs revision is our nixpkgs pin in `npins/sources.json` as normal, i.e. different versions (relevant in #100) remain out of scope here - changing implementations of [module-schema](https://git.fediversity.eu/fediversity/module-schema) we handle by accordingly updating `nix-module-form` to account for these changes

~~kiara referenced this issue 2025-02-25 12:09:46 +01:00~~

Hosting providers can update their operators' deployments #159

~~kiara referenced this issue 2025-02-26 04:52:48 +01:00~~

Hosting providers can update their operators' deployments #159

kiara referenced this issue

2025-03-11 12:59:24 +01:00

separate panel into django back vs front #145

kiara added a new dependency

2025-04-01 20:52:43 +02:00

#224 automated dev-ops workflows

~~kiara referenced this issue 2025-04-07 21:46:57 +02:00~~

decouple mono-repo #303

kiara referenced this issue

2025-04-08 16:47:01 +02:00

reference front-end is decoupled from version of configuration module #304

kiara referenced this issue

2025-04-30 08:26:16 +02:00

client-side form validation #216

kiara referenced this issue

2025-05-01 08:54:54 +02:00

generate Python data models from module options #285

kiara added the

type unclear

label

2025-05-01 12:19:25 +02:00

~~kiara referenced this issue 2025-05-15 20:14:11 +02:00~~

API specification published #334

kiara added

type: user story

and removed

type unclear

labels

2025-05-27 14:35:34 +02:00

kiara changed title from ~~use json schema as common language between components~~ to expose configuration options from schema

2025-05-27 14:36:52 +02:00

kiara changed title from ~~expose configuration options from schema~~ to upstream configuration options exposed through schema

2025-06-01 13:34:31 +02:00

kiara added a new dependency

2025-06-01 13:35:04 +02:00

#289 key features improving user experience supported

kiara removed a dependency

2025-06-01 13:35:16 +02:00

#224 automated dev-ops workflows

kiara changed title from ~~upstream configuration options exposed through schema~~ to upstream configuration options exposed

2025-06-01 13:35:24 +02:00

kiara referenced this issue

2025-06-09 21:10:43 +02:00

initial focus on single application for development #327

~~kiara referenced this issue 2025-06-09 23:00:55 +02:00~~

application offering delegated #369

kiara referenced this issue

2025-06-10 20:05:14 +02:00

key features improving user experience supported #289

~~kiara referenced this issue 2025-11-10 23:25:29 +01:00~~

add conversion from TF #584

kiara added a new dependency

2025-12-02 13:00:50 +01:00

#331 pydantic enum warning: Expected enum but got str

kiara referenced this issue

2025-12-02 16:56:27 +01:00

Configure applications #610

kiara added a new dependency

2025-12-02 17:07:59 +01:00

#610 Configure applications

kiara added the

infinite points

label

2025-12-03 01:30:37 +01:00

kiara changed title from ~~upstream configuration options exposed~~ to NixOS modules' options exposed

2025-12-03 15:15:40 +01:00

kiara added the

3 points

label

2025-12-03 15:15:56 +01:00

kiara added a new dependency

2025-12-03 15:16:18 +01:00

#159 Hosting providers can update their operators' deployments

kiara added a new dependency

2025-12-03 15:16:33 +01:00

#626 nix to json schema coverage

kiara removed the

infinite points

label

2025-12-03 15:16:45 +01:00

kiara added a new dependency

2025-12-03 15:18:38 +01:00

#627 applications' configuration options exposed

kiara removed a dependency

2025-12-03 17:34:14 +01:00

#627 applications' configuration options exposed

kiara removed a dependency

2025-12-03 17:49:44 +01:00

#159 Hosting providers can update their operators' deployments

kiara added a new dependency

2025-12-03 17:49:54 +01:00

#629 schema updates automated

kiara removed a dependency

2025-12-03 21:27:11 +01:00

#629 schema updates automated

kiara referenced this issue

2026-02-16 15:07:10 +01:00

application offering delegated #369

kiara added the

ambition

configure-applications

label

2026-06-11 15:55:55 +02:00

kerstin self-assigned this

2026-07-01 15:30:30 +02:00

kiara added a new dependency

2026-07-01 15:32:22 +02:00

#627 applications' configuration options exposed

kerstin commented

2026-07-14 15:22:03 +02:00

Member

In the meeting on 2026-07-14 @toonn, @kiara and I talked about the problem of some NixOS options depending on config, like e.g. the default value of services.mastodon.redis.host.

This is a problem since we wanna show a form based on jsonschema to the operator, but that jsonschema can't be dependend on the operators input (what eventually becomes the value of config) for latency reasons.

We figured that it is a practical way to move forward for now, by making the jsonschema of a form only dependend on the current nixpkgs checkout, not on the user supplied form input.

That implies that we have to generate jsonschema from NixOS options at runtime (since the Nixkpgs checkout of a deployment changes at runtime), but we can easily cache these, since the Nixpkgs checkout only changes ~once a day.

In the meeting on 2026-07-14 @toonn, @kiara and I talked about the problem of some NixOS options depending on `config`, like e.g. the default value of [`services.mastodon.redis.host`](https://search.nixos.org/options?channel=26.05&query=mastodon.redis.host&type=options#show=option%253Aservices.mastodon.redis.host). This is a problem since we wanna show a form based on jsonschema to the operator, but that jsonschema can't be dependend on the operators input (what eventually becomes the value of `config`) for latency reasons. We figured that it is a practical way to move forward for now, by making the jsonschema of a form only dependend on the current nixpkgs checkout, *not* on the user supplied form input. That implies that we have to generate jsonschema from NixOS options at runtime (since the Nixkpgs checkout of a deployment changes at runtime), but we can easily cache these, since the Nixpkgs checkout only changes ~once a day.

toonn commented

2026-07-14 16:15:04 +02:00

Member

If we don't have the Hosting Provider configure in Nix then backend or frontend would have to do this set difference or get an explicit description of options to show to the Operator somehow.

Agree, with one caveat, some options are expected to be set by the Hosting Provider and should not be shown to Operators. If the Hosting Provider config is in Nix then we could implement this by doing a set difference between the module options and the Hosting Provider's config and we'd generate the schema based on that instead. Not quite as static but the Hosting Provider shouldn't change too frequently, hopefully? If we don't have the Hosting Provider configure in Nix then backend or frontend would have to do this set difference or get an explicit description of options to show to the Operator somehow.

👍 1

kiara commented

2026-07-14 17:18:25 +02:00

Author

Owner

since #1071 we have some type of schema diffing like that based on configuration set by the hosting provider

kerstin added a new dependency

2026-07-16 14:17:12 +02:00

#1209 API route for delivering JSON Schema from NixOS module options

kiara referenced this issue

2026-07-20 11:51:53 +02:00

API route for delivering JSON Schema from NixOS module options #1209