nite/quadlet-migrator-skill
1
0
Fork 0
mirror of https://github.com/bestnite/quadlet-migrator-skill.git synced 2026-04-04 00:33:27 +00:00
Code Issues Activity

Add intra-pod listener reachability guidance

Browse Source 
Require sibling-facing pod services to listen on reachable addresses and preserve or generate upstream listen-address configuration when available.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
nite
2026-04-04 03:34:26 +11:00
parent 2f90be67c9
commit 068299e9b3
4 changed files with 7 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
SKILL.md
View File

@@ -126,6 +126,8 @@ Tasks in this phase:
- if one logical service contains multiple containers, prefer keeping them in the same `.pod` so they share one network namespace
- even when the source Compose topology uses bridge networking, prefer pod-based grouping over preserving bridge semantics mechanically
- containers in the same `.pod` can communicate over `127.0.0.1` / `localhost` because they share a network namespace
- when services in the same `.pod` must accept connections from sibling containers, ensure they listen on `127.0.0.1` or `0.0.0.0`; if they listen only on another interface, sibling containers in the pod may not be able to reach them
- when the upstream service supports configuring the listen address via environment variables or equivalent runtime settings, preserve or generate the necessary configuration instead of assuming the default bind address is correct
- when `Pod=` is set, never generate `AddHost=` entries whose purpose is sibling-container discovery inside that pod; intra-pod communication must use `127.0.0.1` / `localhost` instead
- `AddHost=` remains a host-to-IP override, not an intra-pod service-discovery mechanism; because upstream Quadlet supports `AddHost=` in both `[Container]` and `[Pod]`, do not claim that `Pod=` categorically forbids `AddHost=` unless the upstream reference says so for the specific case
- when containers are attached with `Pod=<name>.pod`, treat the pod's generated systemd service as the primary lifecycle unit; derive that service name from `ServiceName=` when present on the `.pod`, otherwise use Quadlet's default generated pod service name. Starting that pod service brings up the pod-managed containers, so do not add redundant per-container start commands for those child units in helper scripts