Dev VMs: point allod at the deployment's own repository registry #119

New issue

Closed

opened 2026-09-28 21:09:56 +01:00 by vnprc-agent · 1 comment

vnprc-agent commented

2026-09-28 21:09:56 +01:00

Let allod on a dev VM find the deployment's own repository registry, so that a command which reads a per-repository fact, such as allod site serve reading a site's preview_port, works for a repository that only the deployment's inventory lists.

Primary goals:

A private site serves with the plain command — allod site serve in a checkout the deployment's registry lists finds its port with no environment variable typed by hand.
Same pointer as the hypervisor — a dev VM is told where inventory lives the same way the hypervisor is, not by a second mechanism.
The public default is kept — a machine with only the public checkout still needs no configuration.

Current state

allod reads the registry from $INVENTORY/scripts/repositories.json when INVENTORY is set, and from allod/inventory/scripts/repositories.json under the work directory otherwise (allod/tools cmd/allod/registry.go, registryPath). The hypervisor's host module renders INVENTORY from nexus.provisioning.inventoryCheckout. Nothing renders it on a dev VM.

Observed on a dev VM of a deployment that keeps its own inventory beside the public one: INVENTORY is unset, so allod site serve in a site the deployment's registry lists, with a port, refuses with no preview port for <checkout>: give its entry in <work>/allod/inventory/scripts/repositories.json a preview_port, or pass --port. It names the public registry, which does not list the site and must not. With INVENTORY set by hand to the deployment's inventory checkout the same command serves.

The same holds for every registry lookup allod makes on a dev VM: allod patch ids, and allod site serve <site> by id.

Default and alternative

Default: the dev VM builder takes the inventory checkout as a parameter and renders INVENTORY into the session environment, as the hypervisor module does. The checkout is already one of the machine's registered repositories.

Alternative, only if the default proves awkward: allod looks for a deployment inventory at a second conventional path before falling back to the public one. It adds a second rule for where the registry is.

allod/tools git-hooks/setup-tracked-hooks reads the public path literally and ignores INVENTORY; whether it follows is tracked in allod/tools#108.

Validation

On a dev VM after a rebuild: echo $INVENTORY in a login shell and in a non-interactive ssh <vm> <command>, since allod site view starts the server that way.
allod site serve with no variable typed, in a site only the deployment's registry lists.

Scope

In: the dev VM's environment. Out: the registry reader in allod/tools, which already honours the variable.

Let `allod` on a dev VM find the deployment's own repository registry, so that a command which reads a per-repository fact, such as `allod site serve` reading a site's `preview_port`, works for a repository that only the deployment's inventory lists. Primary goals: - **A private site serves with the plain command** — `allod site serve` in a checkout the deployment's registry lists finds its port with no environment variable typed by hand. - **Same pointer as the hypervisor** — a dev VM is told where inventory lives the same way the hypervisor is, not by a second mechanism. - **The public default is kept** — a machine with only the public checkout still needs no configuration. ### Current state `allod` reads the registry from `$INVENTORY/scripts/repositories.json` when `INVENTORY` is set, and from `allod/inventory/scripts/repositories.json` under the work directory otherwise (`allod/tools` `cmd/allod/registry.go`, `registryPath`). The hypervisor's host module renders `INVENTORY` from `nexus.provisioning.inventoryCheckout`. Nothing renders it on a dev VM. Observed on a dev VM of a deployment that keeps its own inventory beside the public one: `INVENTORY` is unset, so `allod site serve` in a site the deployment's registry lists, with a port, refuses with `no preview port for <checkout>: give its entry in <work>/allod/inventory/scripts/repositories.json a preview_port, or pass --port`. It names the public registry, which does not list the site and must not. With `INVENTORY` set by hand to the deployment's inventory checkout the same command serves. The same holds for every registry lookup `allod` makes on a dev VM: `allod patch` ids, and `allod site serve <site>` by id. ### Default and alternative Default: the dev VM builder takes the inventory checkout as a parameter and renders `INVENTORY` into the session environment, as the hypervisor module does. The checkout is already one of the machine's registered repositories. Alternative, only if the default proves awkward: `allod` looks for a deployment inventory at a second conventional path before falling back to the public one. It adds a second rule for where the registry is. `allod/tools` `git-hooks/setup-tracked-hooks` reads the public path literally and ignores `INVENTORY`; whether it follows is tracked in allod/tools#108. ### Validation - On a dev VM after a rebuild: `echo $INVENTORY` in a login shell and in a non-interactive `ssh <vm> <command>`, since `allod site view` starts the server that way. - `allod site serve` with no variable typed, in a site only the deployment's registry lists. ### Scope In: the dev VM's environment. Out: the registry reader in `allod/tools`, which already honours the variable.

vnprc-agent referenced this issue from allod/tools

2026-09-29 01:08:30 +01:00

site serve and view: name the known sites when the id is missing or unknown #248

vnprc-agent referenced this issue from allod/tools

2026-09-29 01:08:31 +01:00

site serve and view: pick a free port when the registry gives none, and report a held port as taken #249

vnprc-agent commented

2026-09-29 01:17:32 +01:00

Author

This also blocks allod site view, which makes it more than a convenience.

view on the hypervisor starts the server by running allod site serve --port <n> <site> in the VM. There the id is looked up in the VM's registry before anything else (allod/tools cmd/allod/site_serve.go, sitePreviewSite). With INVENTORY unset that is the public registry, so for a site only the deployment's inventory lists, the command view runs ends with:

allod: unknown site: <site> has no entry in <work>/allod/inventory/scripts/repositories.json

Exit 1, measured on a dev VM by running that command with the variable unset. It fails even when a preview of that site is already running, because the lookup comes before the check for a running unit. So view cannot show such a site from the hypervisor until the VM can find the deployment's registry in a non-interactive ssh <vm> <command>.

This also blocks `allod site view`, which makes it more than a convenience. `view` on the hypervisor starts the server by running `allod site serve --port <n> <site>` in the VM. There the id is looked up in the VM's registry before anything else (`allod/tools` `cmd/allod/site_serve.go`, `sitePreviewSite`). With `INVENTORY` unset that is the public registry, so for a site only the deployment's inventory lists, the command `view` runs ends with: ``` allod: unknown site: <site> has no entry in <work>/allod/inventory/scripts/repositories.json ``` Exit 1, measured on a dev VM by running that command with the variable unset. It fails even when a preview of that site is already running, because the lookup comes before the check for a running unit. So `view` cannot show such a site from the hypervisor until the VM can find the deployment's registry in a non-interactive `ssh <vm> <command>`.