diff options
author | Matthew Heon <matthew.heon@pm.me> | 2019-05-07 21:22:06 -0400 |
---|---|---|
committer | Matthew Heon <matthew.heon@pm.me> | 2019-05-07 21:28:22 -0400 |
commit | f5938be1f758abf71f3d91fcb82240220ecfad91 (patch) | |
tree | 0392ff8a9a61303ba82be53dd6226be69bd0313b /vendor/github.com/fsouza/go-dockerclient/LICENSE | |
parent | ff260f07e2be55c7fbda24b8727686fc55c650a6 (diff) | |
download | podman-f5938be1f758abf71f3d91fcb82240220ecfad91.tar.gz podman-f5938be1f758abf71f3d91fcb82240220ecfad91.tar.bz2 podman-f5938be1f758abf71f3d91fcb82240220ecfad91.zip |
Improve robustness of pod removal
Removing a pod must first removal all containers in the pod.
Libpod requires the state to remain consistent at all times, so
references to a deleted pod must all be cleansed first.
Pods can have many containers in them. We presently iterate
through all of them, and if an error occurs trying to clean up
and remove any single container, we abort the entire operation
(but cannot recover anything already removed - pod removal is not
an atomic operation).
Because of this, if a removal error occurs partway through, we
can end up with a pod in an inconsistent state that is no longer
usable. What's worse, if the error is in the infra container, and
it's persistent, we get zombie pods - completely unable to be
removed.
When we saw some of these same issues with containers not in
pods, we modified the removal code there to aggressively purge
containers from the database, then try to clean up afterwards.
Take the same approach here, and make cleanup errors nonfatal.
Once we've gone ahead and removed containers, we need to see
pod deletion through to the end - we'll log errors but keep
going.
Also, fix some other small things (most notably, we didn't make
events for the containers removed).
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
Diffstat (limited to 'vendor/github.com/fsouza/go-dockerclient/LICENSE')
0 files changed, 0 insertions, 0 deletions