podman-mesh-provisioner

name	podman-mesh-provisioner
skill_type	skill
description	Podman Mesh Provisioner atomic skill. Provisions a Podman container control plane — rootful OR rootless — enabling the Podman API socket, wiring podman-compose, and registering remote hosts as Podman system connections over SSH, using container-manager-mcp. The Podman peer of swarm-mesh-provisioner and kubernetes-mesh-provisioner. Triggers on "provision podman", "rootless podman", "podman-compose cluster", "set up podman hosts".
domain	infrastructure
tags	["podman","rootless","podman-compose","cluster","overlay-net"]
requires	["container-manager-mcp","tunnel-manager-mcp"]

Podman Mesh Provisioner Skill

Stateless atomic operation to stand up a Podman-based container runtime — rootful or rootless — across one or more hosts, as a first-class peer to Docker Swarm and Kubernetes. Podman has no built-in clustering daemon; the "mesh" is the API socket + podman-compose locally and Podman system connections over SSH for remote hosts (the same Docker-over-SSH inventory model container-manager-mcp already uses).

Prerequisites

• container-manager-mcp — set CONTAINER_MANAGER_TYPE=podman and (optionally) COMPOSE_TOOL=podman-compose; it drives Podman socket/compose/host operations.
• tunnel-manager-mcp — remote command execution + the shared ~/.config/agent-utilities/inventory.yaml.

Inputs

• rootless (bool, default true) — rootless runs the Podman socket under the invoking user ($XDG_RUNTIME_DIR/podman/podman.sock, no daemon, better isolation); rootful uses the system socket (/run/podman/podman.sock) for host-network / low ports / shared volumes.
• hosts — inventory aliases to provision (default: the controller only).

Steps

Step 1: Select the Podman mode (rootful vs rootless)

Resolve the rootless input. For rootless, ensure lingering is enabled so the user socket survives logout (loginctl enable-linger <user>) and that subuid/subgid ranges exist for the user. For rootful, operations run against the system socket and require privileged access on the host.

Step 2: Enable the Podman API socket

Enable and start the Podman socket service so container-manager-mcp can speak the Podman API:

• Rootless: systemctl --user enable --now podman.socket → $XDG_RUNTIME_DIR/podman/podman.sock.
• Rootful: sudo systemctl enable --now podman.socket → /run/podman/podman.sock. Record the resolved socket path as CONTAINER_MANAGER_PODMAN_BASE_URL (unix://<socket>).

Step 3: Wire podman-compose

Confirm podman-compose (or podman compose) is available; set COMPOSE_TOOL=podman-compose so stack deploys route through Podman rather than Docker.

Step 4: Register remote hosts (multi-host mesh)

For each host in the inventory, register a Podman system connection over SSH so the controller can target it by alias: podman system connection add <alias> ssh://<user>@<host><socket>. This reuses the shared inventory (host/user/key) — no remote daemon or exposed TCP socket.

Step 5: Verify

Confirm podman info returns healthy on the controller and on each registered remote connection (rootless vs rootful matches the requested mode), and that a trivial podman run / podman-compose smoke deploy succeeds.

Execution

This is an atomic skill — run the steps above in order via container-manager-mcp (Podman socket/connection/info/run actions) and tunnel-manager-mcp (remote systemctl/loginctl/podman system connection commands). It is the orchestrator's Podman branch (peer to swarm-mesh-provisioner / kubernetes-mesh-provisioner); the caller picks the branch from the operator's chosen orchestrator.

Execution: If graph-os is reachable, offload via graph_orchestrate action=execute_agent (or the kg-delegate skill) so the per-host steps fan out; otherwise execute the steps natively in order against the two MCP servers above.