summaryrefslogtreecommitdiff
path: root/cmd
diff options
context:
space:
mode:
authorMatthew Heon <mheon@redhat.com>2022-05-23 09:34:37 -0400
committerMatthew Heon <mheon@redhat.com>2022-05-23 11:21:15 -0400
commitb7dbc505b6a7fbc14ba559acab31baf7d37f8b62 (patch)
treea414225d4310c64b04eb07e757956b1ac067ef76 /cmd
parente9a114f5a59e4216ee08edadd5e6d8f30cbdbb78 (diff)
downloadpodman-b7dbc505b6a7fbc14ba559acab31baf7d37f8b62.tar.gz
podman-b7dbc505b6a7fbc14ba559acab31baf7d37f8b62.tar.bz2
podman-b7dbc505b6a7fbc14ba559acab31baf7d37f8b62.zip
Instead of erroring, clean up after dangling IDs in DB
For various (mostly legacy) reasons, Podman presently maintains a unified namespace for pods and containers - IE, we cannot have both a pod and a container named "test" at the same time. To implement this, we use a global database table of every pod and container ID (and another of every pod and container name). These entries should be added when containers/pods are added, and removed when containers/pods are removed, with the database's transactional integrity providing a guarantee that this is batched with the overall removal and that the DB should remain sane and consistent no matter what. As such, we treat a dangling ID as a hard error that stops the use of Podman. Unfortunately, we have someone run into this last Friday. I'm still not certain how exactly their DB got into this state, but without further clarification there, we can consider removing the error and making Podman instead clean up and remove any dangling IDs, which should restore Podman to a serviceable state. Drop an error message if we do this, though, because people should know that the DB is in a bad state. [NO NEW TESTS NEEDED] it is deliberately impossible to produce a configuration that would test this without hex-editing the DB file. Signed-off-by: Matthew Heon <mheon@redhat.com>
Diffstat (limited to 'cmd')
0 files changed, 0 insertions, 0 deletions