Change the filter operation when search objects #5
Labels
No labels
Infrastructure
blocked
bug
config
discussion
documentation
duplicate
enhancement
go
help wanted
internal
invalid
kludge
observability
perfomance
question
refactoring
wontfix
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: TrueCloudLab/distribution#5
Loading…
Reference in a new issue
No description provided.
Delete branch ":fix/delete_image"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Close #4
Description of the problem:
The garbage collector was unable to delete data from containers after the image was deleted. This was due to the fact that the object deletion function of the frostfs driver did not delete objects recursively, that is, it did not delete objects in the path and its subpaths.
In fact, because of this, incorrect deletion of objects occurred not only at the garbage collection stage, but also at the object loading stage (after the image download is completed, temporary image loading objects are deleted), as well as at the stage of removing the object from the registry via the API (or another way).
Steps to verify the deletion functionality:
Step 1 - Create a container:
Step 2 - Add the container's cid to the cmd/registry/config-dev-frostfs.yml config. The final config for running distribution with dev-env looks like this:
Step 3 - Launch distribution:
Step 4 - Push the image to the registry:
Step 5 - Delete the image using the digest API:
Step 6 - Start the garbage collector:
When we call the garbage collector again, we will no longer see such an output, which indicates that the garbage collector has managed to delete the data:
We can also see how many objects are left in the container after deletion:
It is important to note that some objects may remain in the container, namely objects indicating symbolic links to image layers - this is normal (for such objects FilePath contains '_layers' and FileName = link)
The same sequence of steps can be done with a bucket, if in step 1 you create a bucket like this:
Signed-off-by: Roman Loginov r.loginov@yadro.com
b03c45115e
to88f2546136
@ -700,3 +700,3 @@
filters := object.NewSearchFilters()
filters.AddRootFilter()
filters.AddFilter(attributeFilePath, path, object.MatchStringEqual)
filters.AddFilter(attributeFilePath, path, object.MatchCommonPrefix)
Shouldn't we also do the same then ?
88f2546136
to101fea3485
@ -733,0 +748,4 @@
}
fileInf := newFileInfo(ctx, obj, "")
if fileInf.Path() == path || fileInf.Path()[len(path)] == '/' {
If something goes wrong (e.g. in
newFileInfo
) we theoretically can get panic infileInf.Path()[len(path)]
. So we have to usefileInf.Path() <= path
.Also we can write
And finally let's keep the similar comment
// Check if a key is a subpath (so that deleting "/a" does not delete "/ab").
101fea3485
to42eafd1fff
LGTM