Issue 101: taking a service its neighbours reach by container name cuts them off #87

2026-09-23T18:14:03Z

jschoubben commented

2026-09-23 18:14:03 +00:00

Found checking the third cutover, before running it. The service looked like the cleanest candidate yet — same image, same published port, same seven data directories, no configuration to overwrite. Every check the first two cutovers had taught agreed.

Then the network. Its neighbour reaches it as http://<service-name>/, over a network fifteen of the predecessor's services share. The module declares a network of its own, correctly — a shared catalogue cannot name a network one installation happens to have — so taking it would stop that name resolving, and the neighbour would fail the next time someone opened a document. Not at the cutover. Later.

The two services already migrated were safe by accident: both are reached through a host port, which survives a change of owner because the port is the machine's, not the network's. Nothing distinguished the cases.

This is the first constraint found that decides the order of the migration, and it cannot be answered by looking at the module — the answer is in the consumer's configuration, and the consumer has not been migrated.

Found checking the third cutover, before running it. The service looked like the cleanest candidate yet — same image, same published port, same seven data directories, no configuration to overwrite. Every check the first two cutovers had taught agreed. Then the network. Its neighbour reaches it as `http://<service-name>/`, over a network fifteen of the predecessor's services share. The module declares a network of its own, correctly — a shared catalogue cannot name a network one installation happens to have — so taking it would stop that name resolving, and the neighbour would fail the next time someone opened a document. Not at the cutover. Later. The two services already migrated were safe **by accident**: both are reached through a host port, which survives a change of owner because the port is the machine's, not the network's. Nothing distinguished the cases. This is the first constraint found that decides the **order** of the migration, and it cannot be answered by looking at the module — the answer is in the consumer's configuration, and the consumer has not been migrated.

jschoubben added 1 commit 2026-09-23 18:14:04 +00:00

Issue 101: taking a service reached by container name cuts its neighbours off 61e4e971a4

Found checking the third cutover rather than running it. The first two were safe by
accident — both are reached through a host port, which survives a change of owner.
This is the first constraint found that decides the order of the migration.

jschoubben merged commit ee2bdf220c into main

2026-09-23 18:14:09 +00:00

jschoubben deleted branch issues/101-a-service-reached-by-name-loses-its-network

2026-09-23 18:14:09 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/hq#87