Define improvements to compose manifest workloads when targeting typical targets(Docker/Podman) #168
Description
Feature description
Improve guidance and normative requirements for Application Developers authoring Compose‑defined workloads such that a single Compose file is portable and deployable across:
- Compose‑Docker–based devices
- Compose‑Podman–based devices (including podman compose and podman‑compose)
This feature ensures Compose workload definitions are runtime‑agnostic, deterministic, and compatible with common industrial edge device constraints.
Provide adequate technical acceptance criteria(s) associated with this feature below:
Further clarify Compose defined workloads to ensure definitions are compatible across both Compose-docker and Compose-podman device types.
- Define requirements to ensure the compose file is compatible across both types of deployments.
Although not required, it is highly encouraged to provide feature use-cases below:
Podman is a common device implementation for standalon devices, ensure our compose defined workloads can be deployed to both Compose-Docker and Compose-Podman implementations.
Additional information
Items that were brought up within the Plugfest:
- Fully qualified image names
- Docker accepts fully qualified image names without issue.
- Podman requires or strongly prefers them for deterministic and secure pulls.
- Using fully qualified names improves portability rather than creating divergence.
- Avoid container_name unless truly required
- Docker works correctly without container_name.
- Podman behaves more predictably without it, especially when using podman‑compose.
- Avoiding explicit container names removes lifecycle and naming collisions without breaking Docker behavior.
- Explicit ports, networks, and volumes
- Docker Compose already encourages explicit definitions.
- Podman requires this more often due to rootless execution, SELinux, and different networking behavior.
- Explicit configuration is portable Compose, not Podman‑specific Compose.