Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow users to tag images in read/only image stores #881

Merged
merged 1 commit into from
Apr 28, 2021
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 31 additions & 0 deletions store.go
Original file line number Diff line number Diff line change
Expand Up @@ -2115,6 +2115,37 @@ func (s *store) SetNames(id string, names []string) error {
return ristore.SetNames(id, deduped)
}

// Check is id refers to a RO Store
ristores, err := s.ROImageStores()
if err != nil {
return err
}
for _, s := range ristores {
store := s
store.RLock()
defer store.Unlock()
if modified, err := store.Modified(); modified || err != nil {
if err = store.Load(); err != nil {
return err
}
}
if i, err := store.Get(id); err == nil {
// Unlock R/O lock and lock with R/W lock
// Previous defer.Unlock() will free the new lock.
ristore.Unlock()
ristore.Lock()
if len(deduped) > 1 {
// Do not want to create image name in R/W storage
deduped = deduped[1:]
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

_, err := ristore.Create(id, deduped, i.TopLayer, i.Metadata, i.Created, i.Digest)
if err == nil {
return ristore.Save()
}
return err
}
}

rcstore, err := s.ContainerStore()
if err != nil {
return err
Expand Down
5 changes: 5 additions & 0 deletions tests/stores.bats
Original file line number Diff line number Diff line change
Expand Up @@ -106,6 +106,11 @@ load helpers
[ "$status" -eq 0 ]
[ "$output" != "" ]

run storage --storage-opt ${STORAGE_DRIVER}.imagestore=${TESTDIR}/ro-root add-names -n newimage $lowerimage
[ "$status" -eq 0 ]
run storage --storage-opt ${STORAGE_DRIVER}.imagestore=${TESTDIR}/ro-root delete-image newimage
[ "$status" -eq 0 ]

# Create a container based on the lowerimage.
run storage --storage-opt ${STORAGE_DRIVER}.imagestore=${TESTDIR}/ro-root --debug=false create-container "$lowerimage"
[ "$status" -eq 0 ]
Expand Down