OCF_HEARTBEAT_PODMAN(7)

💅 OCF_HEARTBEAT_PODMAN(7) — like, the Podman container resource agent, bestie

okay so this is a page from the OCF resource agents manual, and honestly? it's giving container-manager realness. sit down, grab a boba, we're gonna go through it together 🧋✨

---

🌸 NAME 🌸

ocf_heartbeat_podman — the Podman container resource agent. that's it, that's the name, she's iconic 💅

---

✨ SYNOPSIS ✨

podman [start | stop | monitor | meta-data | validate-all]

like, you literally just call her with one of those and she handles it, no cap 🫶

---

🎀 DESCRIPTION 🎀

so the podman HA resource agent creates and launches a podman container, all based off a podman image you supply. and the way she works? containers managed by this agent are both created and removed when the agent runs its start and stop actions. so like, she's not just vibing in the background — she's very much a main character who shows up and also leaves. periodt 💀

---

🔥 SUPPORTED PARAMETERS 🔥

okay this is the part where you gotta pay attention because these are the knobs you're turning. one bullet per param, no skipping, we're doing all of them:

• image — the podman image to base this container off of. (required, string, no default) — yes bestie, required, you literally cannot skip this one 🙈
• name — the name to give the created container. by default this will be that resource's instance name. (optional, string, no default)
• allow_pull — allow the image to be pulled from the configured podman registry when the image does not exist locally. NOTE, this can drastically increase the time required to start the container if the image repository is pulled over the network. (optional, boolean, no default) — so like, network pull = slow start, plan accordingly ⏳
• run_opts — add options to be appended to the podman run command which is used when creating the container during the start action. this option allows users to do things such as setting a custom entry point and injecting environment variables into the newly created container. note the -d option is supplied regardless of this value to force containers to run in the background. (optional, string, no default)

⚠️ NOTE: do not explicitly specify the --name argument in the run_opts. this agent will set --name using either the resource's instance or the name provided in the name argument of this agent. like, she's got it handled, don't fight her on this 💅

• run_cmd — specify a command to launch within the container once it has initialized. (optional, string, no default)
• mount_points — a comma separated list of directories that the container is expecting to use. the agent will ensure they exist by running mkdir -p. (optional, string, no default) — she's proactive, we love that for her ✨
• monitor_cmd — specify the full path of a command to launch within the container to check the health of the container. this command must return 0 to indicate that the container is healthy. a non-zero return code will indicate that the container has failed and should be recovered. (optional, string, no default)

😭 Note: using this method for monitoring processes inside a container is not recommended, as containerd tries to track processes running inside the container and does not deal well with many short-lived processes being spawned. ensure that your container monitors its own processes and terminates on fatal error rather than invoking a command from the outside. like, let her self-regulate, she's got this 🌸

• force_kill — kill a container immediately rather than waiting for it to gracefully shutdown. (optional, boolean, no default) — no chill, just vibes 💀
• reuse — allow the container to be reused once it is stopped. by default, containers get removed once they are stopped. enable this option to have the particular one persist when this happens. (optional, boolean, default 0)
• drop_in_dependency — use transient drop-in files to add extra dependencies to the systemd scopes associated to the container. during reboot, this prevents systemd to stop the container before pacemaker. (optional, boolean, no default) — she's keeping the order of operations, very organized 👑

---

🌈 SUPPORTED ACTIONS 🌈

this resource agent supports the following actions (operations), and yes, each one has a suggested minimum timeout, don't @ me:

• start — starts the resource. suggested minimum timeout: 90s. ⭐
• stop — stops the resource. suggested minimum timeout: 90s. ⭐
• monitor — performs a detailed status check. suggested minimum timeout: 30s. suggested interval: 30s. 👀
• meta-data — retrieves resource agent metadata (internal use only). suggested minimum timeout: 5s. 🫣
• validate-all — performs a validation of the resource configuration. suggested minimum timeout: 30s. ✅

---

🦋 EXAMPLE CRM SHELL 🦋

the following is an example configuration for a podman resource using the crm(8) shell — copy it, love it, ship it:

primitive p_podman ocf:heartbeat:podman \
  params \
    image=string \
  op monitor timeout="30s" interval="30s" depth="0"

---

💜 EXAMPLE PCS 💜

and here's the same energy with pcs(8):

pcs resource create p_podman ocf:heartbeat:podman \
  image=string \
  op monitor timeout="30s" interval="30s" OCF_CHECK_LEVEL="0"

---

👑 SEE ALSO 👑

• http://clusterlabs.org/ — go touch grass on the clusterlabs site, iykyk 🌱

---

🍓 AUTHOR 🍓

ClusterLabs contributors (see the resource agent source for information about individual authors). absolute icons, all of them 🫶

---

and that's the whole page bestie, you ate that 💅✨

🌸 so yeah — this was resource-agents version UNKNOWN, dated 10/01/2026, from the OCF_HEARTBEAT_PODMAN(7) page. mwah, go forth and containerize 💖