Manage volumes¶
This guide covers adding, changing, locking and removing a volume spec.
Volumes hold data, so two markers decide how far syslet may go: removalAllowed allows removing or recreating the unit, and reclaimPolicy decides whether the podman volume and its data go with it.
Know your defaults¶
What happens to a volume's data depends on how you set it up:
| Setup | Spec dropped | Spec changed |
|---|---|---|
| Default, CUE or JSON | Volume and data deleted | Recreated empty |
| Locked | Volume and data kept | Plan refused |
Lock every volume whose data matters.
Add a volume¶
This volume is unlocked: dropping or changing it deletes its data. To keep the data, lock it.
Mount it from a container in the same input:
The podman volume is created by the volume's service when the first container using it starts. A volume spec that no container references is valid, but nothing creates the podman volume.
Change a volume¶
Podman can't reconfigure a volume in place.
Changing [Unit] Description, removalAllowed or reclaimPolicy only rewrites the unit file.
Any other change means deleting the podman volume, with its data, and creating it again.
syslet only recreates the volume if the installed unit already has RemovalAllowed=true and ReclaimPolicy=Delete.
Otherwise the whole plan is refused:
| Text Only | |
|---|---|
To recreate it:
- Drop the volume from
#SysdefLock(in JSON, set"removalAllowed": trueand"reclaimPolicy": "Delete"), keep everything else, and apply. - Make the change, preview and apply.
On the second apply, syslet stops every running container that mounts the volume, stops the volume service, deletes the podman volume, writes the new unit and starts the containers again, which creates the new, empty volume. Lock the volume again afterwards if it should stay protected.
Setting the markers and the change in one apply doesn't work, because syslet reads the markers from the installed unit, not from your spec.
To keep the data, don't change the volume. Add a second volume under a new name, copy the data over with podman, point the containers at the new volume, then remove the old one.
Lock a volume¶
Lock the volume and apply:
Both markers live in [X-Syslet], so changing them rewrites the unit file without touching the volume or restarting containers.
A locked volume:
- is skipped, with its data intact, when its spec disappears from the input.
- refuses any meaningful change (see Change a volume).
Remove a volume¶
- Drop the volume from every container's
Volume=in the input. A volume that is still referenced fails validation. - Make sure the installed unit allows removal. If it's locked, drop it from
#SysdefLock(in JSON, set"removalAllowed": trueand choosereclaimPolicy), keep the spec, and apply once. - Drop the volume spec, preview and apply.
Steps 1 and 3 can go into the same change, and so can removing the container that uses the volume. Check the plan before applying:
Installed removalAllowed |
Installed reclaimPolicy |
Plan shows | Result |
|---|---|---|---|
false |
either | skipped |
Unit file and podman volume stay. |
true |
Retain |
removed |
Unit file deleted; podman volume and data stay, untracked. |
true |
Delete |
removed and Podman volumes to delete: |
Unit file and podman volume deleted. |
If a container that mounts the volume shows skipped in the same plan, don't apply: it would keep running on a volume you're deleting.
A retained volume can be deleted by hand later:
| Bash | |
|---|---|
Putting the spec back while a retained volume still exists reattaches the unit to it with the data intact. See Removing specs for the reasons behind the markers.