summaryrefslogtreecommitdiff
path: root/pkg/adapter/checkpoint_restore.go
diff options
context:
space:
mode:
authorMatthew Heon <matthew.heon@pm.me>2019-12-17 21:41:31 -0500
committerMatthew Heon <matthew.heon@pm.me>2019-12-17 21:41:31 -0500
commit88917e4a939f23bedf17fdf470ca1a2c387045eb (patch)
treeede5057e16b49eb81212bb2281eea56cd0f03e93 /pkg/adapter/checkpoint_restore.go
parentb2f05e0e84411f985fea66e9edff1fec8f26d28d (diff)
downloadpodman-88917e4a939f23bedf17fdf470ca1a2c387045eb.tar.gz
podman-88917e4a939f23bedf17fdf470ca1a2c387045eb.tar.bz2
podman-88917e4a939f23bedf17fdf470ca1a2c387045eb.zip
Remove volumes after containers in pod remove
When trying to reproduce #4704 I noticed that the named volumes from the Postgres containers in the reproducer weren't being removed by `podman pod rm -f` saying that the container they were attached to was still in use. This was rather odd, considering they were only in use by one container, and that container was in the process of being removed with the pod. After a bit of tracing, I realized that the cause is the ordering of container removal when we remove a pod. Normally, it's done in removeContainer() before volume removal (which is the last thing in that function). However, when we are removing a pod, we remove containers all at once, after removeContainer has already finished - meaning the container still exists when we try to remove its volumes, and thus the volume can't be removed. Solution: collect a list of all named volumes in use by the pod, and remove them all at once after every container in the pod is gone. This ensures that there are no dependency issues. Signed-off-by: Matthew Heon <matthew.heon@pm.me>
Diffstat (limited to 'pkg/adapter/checkpoint_restore.go')
0 files changed, 0 insertions, 0 deletions