Convert mssql from the module it replaces, not from a blank page #46

2026-09-23T18:22:45Z

jschoubben commented

2026-09-23 18:22:45 +00:00

Read against the predecessor's own module definition rather than inferred from a running container. Three things it says that this module did not:

It publishes 4848:1433, and its connections block is what hands every consumer localhost:4848. The module declared a bare 1433, so taking it would have moved the port every consumer had been told about.
Its data has lived in /services/mssql/data since it was installed — 4.6 GB, owned by uid 10001. The module declared db-data, so the engine would have started on an empty directory. db-data was not a convention either: only this module and mongodb used it, and both predecessors say data. Every other module in this catalogue already keeps the path its predecessor used.
The pin was three builds behind what the machine runs (16.0.4295.3).

With these, nothing moves at the cutover: same image, same port, same directory. The SA password stays an own secret, which matters — SQL Server sets it only at first initialisation, so a minted one would be wrong and the mesh would believe it was right.

One difference left deliberately: the predecessor's firewall rule opens 4848 to the private ranges, while this module says from: mesh. The found firewall stays in force while the node is adopted, so nothing closes now; it is a question for the flip, not for the cutover.

Read against the predecessor's own module definition rather than inferred from a running container. Three things it says that this module did not: - **It publishes `4848:1433`,** and its `connections` block is what hands every consumer `localhost:4848`. The module declared a bare `1433`, so taking it would have moved the port every consumer had been told about. - **Its data has lived in `/services/mssql/data`** since it was installed — 4.6 GB, owned by uid 10001. The module declared `db-data`, so the engine would have started on an empty directory. `db-data` was not a convention either: only this module and `mongodb` used it, and both predecessors say `data`. Every other module in this catalogue already keeps the path its predecessor used. - **The pin was three builds behind** what the machine runs (16.0.4295.3). With these, nothing moves at the cutover: same image, same port, same directory. The SA password stays an own secret, which matters — SQL Server sets it only at first initialisation, so a minted one would be wrong and the mesh would believe it was right. One difference left deliberately: the predecessor's firewall rule opens 4848 to the private ranges, while this module says `from: mesh`. The found firewall stays in force while the node is adopted, so nothing closes now; it is a question for the flip, not for the cutover.

jschoubben added 1 commit 2026-09-23 18:22:45 +00:00

Convert mssql from the module it replaces, not from a blank page cae0d00a7d

Read against hal/modules/mssql: the predecessor publishes 4848:1433 and its connections
block hands every consumer localhost:4848; its data has lived in /services/mssql/data
since it was installed — 4.6 GB of it. The nox module had 1433, db-data, and a pin three
builds behind, so taking it would have moved the port every consumer was told about,
started on an empty directory, and downgraded the engine at the same time.

db-data was not a convention: only this module and mongodb used it, and both predecessors
say data. Now nothing moves at the cutover.

jschoubben merged commit 9f2c678355 into main

2026-09-23 18:22:51 +00:00

jschoubben deleted branch convert/mssql-from-hal

2026-09-23 18:22:51 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-catalog#46