podman run --rm does not remove automatically created volumes

[neVERberleRfellerER]

/kind feature

Description

podman run --rm does not remove automatically created volumes. This is different from docker run --rm as described in https://docs.docker.com/engine/reference/run/#clean-up---rm .

Steps to reproduce the issue:

1. podman run --rm --name pg1 -d postgres

2. podman stop pg1

3. podman volume ls

Describe the results you received:
Automatically created volume. Every reproduction step leaves one more volume. Containers with more volumes leave behind more volumes.

Describe the results you expected:
No new volumes left behind after container started with --rm stops.

Additional information you deem important (e.g. issue happens only occasionally):
Happens always.

Output of podman version:

Version:            1.5.1
RemoteAPI Version:  1
Go Version:         go1.12.8
OS/Arch:            linux/amd64

Output of podman info --debug:

debug:
  compiler: gc
  git commit: ""
  go version: go1.12.8
  podman version: 1.5.1
host:
  BuildahVersion: 1.10.1
  Conmon:
    package: Unknown
    path: /usr/bin/conmon
    version: 'conmon version 2.0.0, commit: e217fdff82e0b1a6184a28c43043a4065083407f'
  Distribution:
    distribution: arch
    version: unknown
  MemFree: 10514563072
  MemTotal: 16743772160
  OCIRuntime:
    package: Unknown
    path: /usr/bin/runc
    version: |-
      runc version 1.0.0-rc8
      commit: 425e105d5a03fabd737a126ad93d62a9eeede87f
      spec: 1.0.1-dev
  SwapFree: 17179865088
  SwapTotal: 17179865088
  arch: amd64
  cpus: 16
  eventlogger: file
  hostname: myhost
  kernel: 5.2.11-arch1-1-ARCH
  os: linux
  rootless: true
  uptime: 1h 36m 52.75s (Approximately 0.04 days)
registries:
  blocked: null
  insecure: null
  search:
  - docker.io
  - registry.fedoraproject.org
  - quay.io
  - registry.access.redhat.com
  - registry.centos.org
store:
  ConfigFile: /home/user/.config/containers/storage.conf
  ContainerStore:
    number: 2
  GraphDriverName: overlay
  GraphOptions:
  - overlay.mount_program=/usr/bin/fuse-overlayfs
  GraphRoot: /home/user/.local/share/containers/storage
  GraphStatus:
    Backing Filesystem: btrfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  ImageStore:
    number: 9
  RunRoot: /run/user/1000
  VolumePath: /home/user/.local/share/containers/storage/volumes

Package info (e.g. output of rpm -q podman or apt list podman):

podman 1.5.1-1

Additional environment details (AWS, VirtualBox, physical, etc.):
physical

[mheon]

We changed this in the other direction in #3071 - need to figure out what's going on here.

[mheon]

Only volumes that are specified without a name are removed

Well, that simplifies matters. We don't have support for anonymous named volumes yet, I think.

[neVERberleRfellerER]

Now that I think about it, docker docs might not even have any power over this particular issue, since docs only deal with specified volumes, but my problem is with unspecified volumes (volumes created automatically by podman when -v was not specified). Not sure how docker handles unspecified volumes. Previously, I was under bad impression that automatically created volumes are anonymous volumes, but they are something different (and indeed, they are not supported by podman yet).

[github-actions]

This issue had no activity for 30 days. In the absence of activity or the "do-not-close" label, the issue will be automatically closed within 7 days.

[mheon]

This is actually fixed now - we landed support for anonymous volumes recently.

[Gigadoc2]

Do note that this now results in volumes created with older versions of podman (those that do not show up with a DRIVER in podman volume list) being deleted when used in combination with podman run --rm, even though they are explicitly named.

[mheon]

Will be fixed in 1.8.0. Unfortunately, that fix also has to go a little far to the other side (even unnamed volumes from old Podman versions will not be removed) - but this is safer than removing volumes that we shouldn't.

[Gigadoc2]

After having kind of lost a Nextcloud installation today, I fully agree with you on that 😅