`podman volume rename`

[cyqsimon]

Feature request description

Currently if I want to rename a volume, I need to create a new volume, copy/move over all its data, then remove the original volume. This seems to me unnecessarily roundabout for a somewhat common need.

Suggest potential solution

Add a podman volume rename command that renames the volume in-place.

Have you considered any alternatives?

The existing create-copy-remove dance. It's not ideal.

Additional context

No response

[Honny1]

I think this is reasonable.

[MayorFaj]

I am happy to look into this

[MayorFaj]

/assign

[MayorFaj]

I have some questions:

do we want;
rename to work even with stopped containers referencing the volume
OR
Error if any container references the volume

for volumes that uses local driver, or plugin driver
do we only want to allow rename for local driver, and error for plugin driver e.g; "rename not supported for driver nfs-plugin"

[cyqsimon]

Here's my two cents:

1. I'd like to see it fail fast (i.e. don't allow renaming when refcount > 0). For the dev (you) I imagine this would be much easier to implement since we've effectively eliminated a lot of edge cases; for the user, this would have a higher likelihood of exposing problems early (in e.g. custom scripting).
2. I've only ever used local volumes with podman, so I don't have an opinion on (or need for) other drivers.

[mheon]

For 2: I think local driver only is reasonable. We cannot really extend the API for volume plugins, and it does not support renaming.

For 1: given the lack of a volume ID as an unambiguous reference that we have in containers/pods, I think we have to limit it to unused volumes.

With those two constraints, implementing rename should be pretty simple; we even have a rewrite-volume-config already to accomplish it.

[MayorFaj]

Thanks

Looking at the RewriteVolumeConfig as the starting point. It's close to what we need, but it appears it only updates the VolumeConfig table. Since VolumeConfig.Name and VolumeState.Name have circular foreign keys (both DEFERRABLE INITIALLY DEFERRED), changing the name in just VolumeConfig causes a FK violation at commit time because VolumeState still has the old name.

So I added a dedicated RenameVolume method on State that updates both VolumeState and VolumeConfig within a single transaction. The rest follows the existing patterns; runtime-level validation (not in use, not mounted, not a plugin/image driver, not anonymous), filesystem os.Rename, and rollback if the DB update fails.

I'll have a PR up shortly.