diff options
author | Valentin Rothberg <rothberg@redhat.com> | 2020-10-01 14:17:02 +0200 |
---|---|---|
committer | Valentin Rothberg <rothberg@redhat.com> | 2020-10-01 18:30:20 +0200 |
commit | 04dddbbf7f85824f4917ff8f62eed27301088090 (patch) | |
tree | 9c72cd46bcb30f57948530c77759a842a595d9e7 /cmd/podman | |
parent | c70f5fb19bb411f81183d025d18bbf1e8cdc0938 (diff) | |
download | podman-04dddbbf7f85824f4917ff8f62eed27301088090.tar.gz podman-04dddbbf7f85824f4917ff8f62eed27301088090.tar.bz2 podman-04dddbbf7f85824f4917ff8f62eed27301088090.zip |
remote: fix name and ID collisions of containers and pods
Fix the look up of containers and pods in the remote client. User input
can refer to both, names or IDs of containers and pods, so there is a
fair chance of collisions (e.g., "c1" name with a "c1...." ID).
Those collisions are well handled (and battle tested) in the local
client which is directly using the libpod backend. Hence, the remote
client should not attempt to introduce its own logic to prevent bugs and
divergence between the local and the remote clients. To prevent
collisions such as in #7837, do a container/pod inspect on the
user-provided input to find the corresponding ID and eventually do full
ID comparisons to avoid potential collisions with names.
Note that this has a cost that I am not entirely happy with. Looking at
issue #7837, the collisions are happening when removing the two
containers. Remote container removal is now very chatty with the server
as it first queries for all containers, then iterates over the provided
names or IDs and does a remote inspect to figure out the IDs and find a
matching container object. However, remote removal could just pass the
names and IDs directly to the batch removal endpoint. Querying for all
containers could be prevented if the batch removal endpoint would remove
all if the slice is empty.
In other words, the bug is fixed but there's room for performance
improvements.
Fixes: #7837
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Diffstat (limited to 'cmd/podman')
0 files changed, 0 insertions, 0 deletions