38 lines
1.8 KiB
Markdown
38 lines
1.8 KiB
Markdown
---
|
|
status: open
|
|
opened: 2026-09-22
|
|
located-in: []
|
|
fixed-by:
|
|
amended-design:
|
|
---
|
|
|
|
# 086 — Taking a module narrows a port the predecessor served, without saying so
|
|
|
|
## What was observed
|
|
|
|
In the adoption lab bed, 2026-09-22. A service found on the machine served its port to anyone,
|
|
and the predecessor's firewall allowed it from anywhere. The catalogue module that replaces it
|
|
declares the port reachable from the private network only. After the module was **taken**, the
|
|
mesh's guard refused that port from everywhere outside the private network. That is
|
|
[ADR 0103](../../02-DECISIONS/0103-what-an-adopted-node-holds-and-what-its-guard-refuses.md)
|
|
working as written: a taken module's published private-network ports are guarded. The service
|
|
answered over the private network, and the bed passed.
|
|
|
|
Nothing said the port had narrowed. Taking a module names the files and containers it replaces,
|
|
but not the ports whose reach changes. The converge preview names every narrowing, but the flip
|
|
comes after taking, so by then the change has already happened.
|
|
|
|
## Why it matters beyond this instance
|
|
|
|
On a machine in use, taking a module is the cutover for that service. If the predecessor served
|
|
the port publicly and the module says private, taking it closes the port to every client outside
|
|
the private network. Nothing warns the operator first. ADR 0100 promises that each step says what
|
|
it changes before it changes it, and for taking a module this one does not.
|
|
|
|
## Open questions
|
|
|
|
- Should taking a module preview the reach of each port it publishes, found firewall and guard
|
|
included, and ask for the same kind of confirmation as the flip?
|
|
- Or should taking refuse while a port of the module is reachable more widely than the module
|
|
declares, until the operator either changes the module's exposure or confirms the narrowing?
|