The packages port given at genesis is a node setting, not manifest text (hq issue 085) #21

2026-09-22T19:58:06Z

jschoubben commented

2026-09-22 19:58:06 +00:00

Fixes hq issue 085 on the installer's side. Merge first, then mesh-controller, then mesh-catalog.

Before: genesis rewrote the port into the builder's manifest text. Re-registering the builder from the catalogue put the old number back, and the forge's own module took over on the catalogue's port. On a machine where a predecessor holds that port, either one points the builder, and its registry credential, at the predecessor's forge.

Now:

The builder's manifest reaches the mesh byte for byte as the catalogue wrote it. The text rewrite is gone.
Genesis records the port as a per-node setting: the forge's own ports, and what the builder is told to dial. Both come from the single --packages-port input.
The forge's module is registered, not assigned, so the setting has a module row to hang on. Nothing of it runs. This also has the controller reserve that machine port, which it previously did not know about at all, so nothing else can be given it.
A genesis on the default port records nothing and registers nothing, exactly as before.
A re-run does not replace a forge manifest the mesh already has. Every other module add in the installer registers on purpose, because the manifest is what changes between runs. This one wants nothing from the checkout.

Reviewed independently: no must-fixes, six smaller ones applied.

Before this lands on a mesh already raised with a non-default packages port, give the builder its current port as a setting first, or registering the new catalogue's manifest drops it back to the default:

settings set builder '{"serves": {"port": <N>}}' --node <node>
push <node>

A mesh raised on the default port needs nothing.

Known and not fixed here, each recorded in hq: the forge's own address env value (088), a route contribution's port not following a moved port (089), and the forge module not being able to take over the forge genesis raises (090).

go build ./... && go vet ./... && go test ./... green.

Fixes hq issue 085 on the installer's side. **Merge first**, then mesh-controller, then mesh-catalog. Before: genesis rewrote the port into the builder's manifest text. Re-registering the builder from the catalogue put the old number back, and the forge's own module took over on the catalogue's port. On a machine where a predecessor holds that port, either one points the builder, and its registry credential, at the predecessor's forge. Now: - The builder's manifest reaches the mesh byte for byte as the catalogue wrote it. The text rewrite is gone. - Genesis records the port as a per-node setting: the forge's own `ports`, and what the builder is told to dial. Both come from the single `--packages-port` input. - The forge's module is **registered, not assigned**, so the setting has a module row to hang on. Nothing of it runs. This also has the controller reserve that machine port, which it previously did not know about at all, so nothing else can be given it. - A genesis on the default port records nothing and registers nothing, exactly as before. - A re-run does not replace a forge manifest the mesh already has. Every other `module add` in the installer registers on purpose, because the manifest is what changes between runs. This one wants nothing from the checkout. Reviewed independently: no must-fixes, six smaller ones applied. **Before this lands on a mesh already raised with a non-default packages port**, give the builder its current port as a setting first, or registering the new catalogue's manifest drops it back to the default: ``` settings set builder '{"serves": {"port": <N>}}' --node <node> push <node> ``` A mesh raised on the default port needs nothing. Known and not fixed here, each recorded in hq: the forge's own address env value (088), a route contribution's port not following a moved port (089), and the forge module not being able to take over the forge genesis raises (090). `go build ./... && go vet ./... && go test ./...` green.

jschoubben added 2 commits 2026-09-22 19:58:07 +00:00

The packages port given at genesis is a module's setting, like every other c4ce57997e

Every foundation port given at genesis became a per-node setting of the module
that binds it, except the package registry's: that one was fixed by rewriting
the builder's manifest when the installer registered it. Registering the builder
again from the catalogue undid it, and the forge's own module, when it took the
bootstrap forge over, came up on the catalogue's port — which on a machine where
a predecessor holds 3000 points the builder at the predecessor's forge.

So the rewrite is gone, and the port is recorded twice as a setting, both from
the one input:

- the forge's module is registered at genesis — not assigned, nothing of it runs
  — so the controller has something to hold `{"ports": {"3000": <given>}}`
  against. Assigning the forge later raises it on the port this machine was
  given, and its container, its filter rule, its opening, what it serves and
  what consumers are told all read it from there.
- the builder is given `{"serves": {"port": <given>}}`, which merges into the
  binding it carries in place of one nothing can resolve yet.

A genesis on the catalogue's port records nothing and registers nothing, so it
does exactly what it did before.

novox/hq 04-ISSUES/085, ADR 0100

A re-run does not replace the registered forge with whatever checkout it was given 744beb6c51

Registering a module is an overwrite. Recording the forge's port ran `module add`
every time, so a genesis re-run pointed at an older catalogue would replace the
manifest of a forge that is built and assigned — with a push a few lines later.
Registering is only here so a settings row has a module row to hang on, and that
row is already there on a mesh that knows the forge. So: ask first, and skip.

Two comments narrowed to what is true. What follows the node's setting is what
the mesh derives from a module's ports — its container mapping, its filter rule,
its opening and what it serves. The forge's own address in its runtime's
environment (hq 088) and its route contribution's port do not, and are already
wrong for any port the mesh assigned. And a settings layer is the module's, not
one resource's: a second mergeable file on the builder would be given `serves`
too.

novox/hq 04-ISSUES/085

jschoubben merged commit 9176aea6c4 into main

2026-09-22 19:59:47 +00:00

jschoubben deleted branch feat/packages-port

2026-09-22 19:59:47 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-host#21