diff options
author | Matthew Heon <mheon@redhat.com> | 2022-05-23 09:34:37 -0400 |
---|---|---|
committer | Matthew Heon <mheon@redhat.com> | 2022-05-23 11:21:15 -0400 |
commit | b7dbc505b6a7fbc14ba559acab31baf7d37f8b62 (patch) | |
tree | a414225d4310c64b04eb07e757956b1ac067ef76 /cmd | |
parent | e9a114f5a59e4216ee08edadd5e6d8f30cbdbb78 (diff) | |
download | podman-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