Add ability to remove container and all its dependents

[dsedivec]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind feature

Description

I would like to be able to remove a container along with all of its dependent containers.

Steps to reproduce the issue:

1. podman create --name=alpha docker.io/alpine

2. podman create --name=bravo --net=container:alpha docker.io/alpine

3. podman rm -f alpha

Describe the results you received:

Error: container 41f2e5f2cf31e77e4281264d6137a0590536d607804d27ff73f779bfe9d9248d has dependent containers which must be removed before it: 15f02bce50a1fc6788b6b25166da96d90fcdbc256abd8cfdd487b4f17b1b49c4: container already exists

Describe the results you expected:

alpha and bravo containers are removed

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

While this would be really helpful when I'm working at the CLI, I also have a goal to let Ansible's podman_container restart a container with dependencies when necessary (e.g. image has been updated). In that case, later steps in the playbook will be creating/updating the dependent containers anyway.

I'm not married to --force being the switch used to do this, a new switch could be used.

Output of podman version:

podman version
Version:      3.1.2
API Version:  3.1.2
Go Version:   go1.16
Built:        Thu Apr 22 06:11:28 2021
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.20.1
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.0.27-2.fc34.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.27, commit: '
  cpus: 8
  distribution:
    distribution: fedora
    version: "34"
  eventLogger: journald
  hostname: mmhmm
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 5.11.13-300.fc34.x86_64
  linkmode: dynamic
  memFree: 782872576
  memTotal: 16676921344
  ociRuntime:
    name: runc
    package: runc-1.0.0-377.rc93.fc34.x86_64
    path: /usr/bin/runc
    version: |-
      runc version 1.0.0-rc93
      commit: 48389904331fdebba5e2db73147c067560a51d80
      spec: 1.0.2-dev
      go: go1.16
      libseccomp: 2.5.0
  os: linux
  remoteSocket:
    path: /run/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: false
    seccompEnabled: true
    selinuxEnabled: true
  slirp4netns:
    executable: ""
    package: ""
    version: ""
  swapFree: 16981417984
  swapTotal: 17179860992
  uptime: 357h 25m 26.72s (Approximately 14.88 days)
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
  - quay.io
store:
  configFile: /etc/containers/storage.conf
  containerStore:
    number: 5
    paused: 0
    running: 1
    stopped: 4
  graphDriverName: overlay
  graphOptions:
    overlay.mountopt: nodev,metacopy=on
  graphRoot: /var/lib/containers/storage
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "true"
  imageStore:
    number: 25
  runRoot: /run/containers/storage
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 3.1.2
  Built: 1619097088
  BuiltTime: Thu Apr 22 06:11:28 2021
  GitCommit: ""
  GoVersion: go1.16
  OsArch: linux/amd64
  Version: 3.1.2

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

podman-3.1.2-1.fc34.x86_64

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/master/troubleshooting.md)

Yes

[vrothberg]

Thanks for reaching out!

@mheon WDYT?

15f02bce50a1fc6788b6b25166da96d90fcdbc256abd8cfdd487b4f17b1b49c4: container already exists

I find the last wrapped error confusing in that context.

[mheon]

Sounds fine (finally get to include a recursive flag!) but will be a fair amount of work. The code for recursive start was already written, but the recursive start code is not.

…

On Mon, May 17, 2021 at 08:05 Valentin Rothberg ***@***.***> wrote: Thanks for reaching out! @mheon <https://github.com/mheon> WDYT? 15f02bce50a1fc6788b6b25166da96d90fcdbc256abd8cfdd487b4f17b1b49c4: container already exists I find the last wrapped error confusing in that context. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#10360 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3AOCFHQZJB3J7FHAVMIN3TOEBB5ANCNFSM447QLNZA> .

[mheon]

Recursive stop code, even

…

On Mon, May 17, 2021 at 08:47 Matthew Heon ***@***.***> wrote: Sounds fine (finally get to include a recursive flag!) but will be a fair amount of work. The code for recursive start was already written, but the recursive start code is not. On Mon, May 17, 2021 at 08:05 Valentin Rothberg ***@***.***> wrote: > Thanks for reaching out! > > @mheon <https://github.com/mheon> WDYT? > > 15f02bce50a1fc6788b6b25166da96d90fcdbc256abd8cfdd487b4f17b1b49c4: > container already exists > > I find the last wrapped error confusing in that context. > > — > You are receiving this because you were mentioned. > > > Reply to this email directly, view it on GitHub > <#10360 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AB3AOCFHQZJB3J7FHAVMIN3TOEBB5ANCNFSM447QLNZA> > . >

[rhatdan]

SGTM
--force is probably the correct flag to use, since we already use it for images and volumes.

[mheon]

I don't really like using force here. --force says "definitely get rid of this one container". If I do a podman rm --force myctr and it removes this container, but also four others, that's not really intuitive.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

I would prefer --depend over recurse.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[mheon]

Working on this now

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[1nF0rmed]

@mheon Are you still working on this issue? Any progress?

[jesselang]

Is this issue still available? I'd be up for taking a swing at it.

[mheon]

Sure, if you want to, you can take it.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@jesselang Did you ever get a chance to work on this?

[jesselang]

Apologies, no. I'm afraid I won't be able to get to it anytime soon. Feel free to hand it out to someone.

[RichardFevrier]

Hello @rhatdan I am wondering if this --depend argument will exists with some other commands like stop ...

I am in the case where I am running Docker containers thanks to Podman.
And every time that I need to docker-compose down with a container/service network dependency like presented in this issue I need to repeat the command until everything is properly stopped.

Thanks

[rhatdan]

Open a new issue for this.