Allow users to tag images in read/only image stores #881
Conversation
rhatdan
force-pushed
the
selinux
branch
3 times, most recently
from
b963fc0
to
9a8d594
Compare
|
@containers/podman-maintainers PTAL |
|
Alll sorts of test unhappiness @rhatdan |
Fixes: containers/podman#9412 Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
| if len(deduped) > 1 { | ||
| // Do not want to create image name in R/W storage | ||
| deduped = deduped[1:] | ||
| } |
There was a problem hiding this comment.
Can someone walk me through what's going on from line 2135 to 2140?
Why is the lock we take on 2136 read-write if the lock taken at line 2107 was read-only?
Why do we drop the first (and only the first) name of the possibly many names that the image record in the read-only store has attached to it when adding a record to the read-write store that will include the new name? What happens when someone calls us without exactly the set of names in i.Names?
There was a problem hiding this comment.
The first name is the existing image, the follow on names are the names being tagged.
Since we did not find the first name in the Read/Write store, but only in the Read/Only store, we want to add the new names to the readwrite store. We need the read/write lock now, so close the existing read/only lock and create a read/write lock, and then create images with the new name.
There was a problem hiding this comment.
The existing image can have had multiple names attached to it, and there's no requirement that SetNames() include more names than were already set on the image. That sort of explains the > 1 test for me, but it sounds like you're making an assumption here that isn't correct.
The read-write store was already locked for writing on line 2107. I still don't see the point of releasing the lock on line 2135 only to reacquire it on the very next line.
Fixes: containers/podman#9412
Signed-off-by: Daniel J Walsh dwalsh@redhat.com