Define whether fleet registries collect guest declarations #65

New Issue

alexion · 2026-08-25T11:27:26-04:00

alexion commented

2026-08-25 11:27:26 -04:00

Problem

The current registry collector treats the fleet as top-level NixOS hosts only.
It reads self.nixosConfigurations.<host>.config.registry and does not collect registry declarations from guest interiors such as config.containers.<guest>.config.registry.

That was easy to miss because existing guest address and route entries are published by host-side guest helper code.
Service modules enabled only inside guests can publish local guest registry entries, but those entries are invisible to self.lib.registry.collect { hosts = self.nixosConfigurations; }.

PR 64 works around this for registry.stable-uid by keeping stable UID declarations unconditional in service modules.
That makes top-level host evaluations publish the allocations even when the service itself only runs inside a guest.
This is acceptable for that PR, but it leaves the broader meaning of fleet registries underspecified.

Options discussed

Keep specific registries using unconditional host-visible declarations when host-side consumers need the values.
This is small and works for stable UIDs, but it does not fix guest registry collection.
Publish selected guest values outward through host-side guest wiring.
This avoids a broad collector change, but risks one-off plumbing and duplicated ownership rules.
Refactor registry collection so guests are fleet members too.
This better matches the word fleet and would let guest-local registry declarations participate in the collected registry, but it needs explicit naming, collision, and recursion handling.

Acceptance shape for a future fix

A future design should decide whether fleet registry collection includes guest interiors.
If it does, the implementation should define how guest keys are named, how duplicate guest names across hosts are handled, and how cycles are avoided when guests also receive the collected registry special arg.

— Claude

## Problem The current registry collector treats the fleet as top-level NixOS hosts only. It reads `self.nixosConfigurations.<host>.config.registry` and does not collect registry declarations from guest interiors such as `config.containers.<guest>.config.registry`. That was easy to miss because existing guest address and route entries are published by host-side guest helper code. Service modules enabled only inside guests can publish local guest registry entries, but those entries are invisible to `self.lib.registry.collect { hosts = self.nixosConfigurations; }`. PR 64 works around this for `registry.stable-uid` by keeping stable UID declarations unconditional in service modules. That makes top-level host evaluations publish the allocations even when the service itself only runs inside a guest. This is acceptable for that PR, but it leaves the broader meaning of fleet registries underspecified. ## Options discussed 1. Keep specific registries using unconditional host-visible declarations when host-side consumers need the values. This is small and works for stable UIDs, but it does not fix guest registry collection. 2. Publish selected guest values outward through host-side guest wiring. This avoids a broad collector change, but risks one-off plumbing and duplicated ownership rules. 3. Refactor registry collection so guests are fleet members too. This better matches the word fleet and would let guest-local registry declarations participate in the collected registry, but it needs explicit naming, collision, and recursion handling. ## Acceptance shape for a future fix A future design should decide whether fleet registry collection includes guest interiors. If it does, the implementation should define how guest keys are named, how duplicate guest names across hosts are handled, and how cycles are avoided when guests also receive the collected `registry` special arg. — Claude

alexion closed this issue

2026-08-29 17:22:01 -04:00

This repo is archived. You cannot comment on issues.

1 Participants

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: alexion/dotfiles#65