Object expiration data in the tree service #141
Labels
No labels
P0
P1
P2
P3
good first issue
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/frostfs-s3-gw#141
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
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?
Is your feature request related to a problem? Please describe.
S3 Gateway provides a possibility to set an expiration for the objects. However the tree service and object service are not synced in the storage node. So expired object will not be removed from tree service, which may lead to unexpected listing results.
Describe the solution you'd like
Store expiration epoch of the object in the tree and ignore expired objects during listing.
Describe alternatives you've considered
Synchronize tree and object services in the node, which is not quite possible right now.
Maybe it shouldn't because gateway sends HEAD requests during listing. But anyway we are going to have dead records in the tree, which isn't a great thing.
Gateway can remove expired objects from the tree every time it sees it.
It is necessary to provide for such a scenario: there is an object with a expireAt=10, it is blocked by a lock with expireAt=20. Then the object will actually be deleted at epoch 20, not 10.
There may also be several locks with different expireAt.
@dkirillov please look at this in the case of #294.
I don't think S3 Gateway works with neither lock or expiration objects right now. If it does, then consider adding some more data to the tree nodes.
S3 Gateway doesn't work with expiration of user-uploaded object rigth now (we have #42 for that).
For locks the situation is little different: