Make complex object stored with EC expire correctly #1602

Merged
fyrchik merged 1 commit from a-savchuk/frostfs-node:ec-object-expiration into master 2025-02-03 11:52:01 +00:00
Member

Adopt changes introduced in TrueCloudLab/frostfs-sdk-go#319

Adopt changes introduced in https://git.frostfs.info/TrueCloudLab/frostfs-sdk-go/pulls/319
a-savchuk added the
blocked
label 2025-01-15 11:38:30 +00:00
a-savchuk force-pushed ec-object-expiration from 5fc53e9b06 to f660e8bc69 2025-01-15 11:40:24 +00:00 Compare
fyrchik requested changes 2025-01-15 11:54:47 +00:00
Dismissed
@ -261,2 +261,3 @@
func putExpirationEpoch(tx *bbolt.Tx, obj *objectSDK.Object, addr oid.Address, objKey []byte) error {
if expEpoch, ok := hasExpirationEpoch(obj); ok {
attributes := obj.Attributes()
if ech := obj.ECHeader(); ech != nil {
Owner

This complicates metabase: EC object MAY produce additional indexes, but we should clearly delimit it and not have custom logic for common object fields. There is a set of operations I should be able to perform on any type of objects.

This complicates metabase: EC object MAY produce _additional_ indexes, but we should clearly delimit it and not have custom logic for common object fields. There is a set of operations I should be able to perform on any type of objects.
Author
Member

After recent changes in PR in SDK, every object part and chunk has expiration epoch. This solution works well, I think I can't have unit test for this but I checked it in dev-env

After recent changes in PR in SDK, every object part and chunk has expiration epoch. This solution works well, I think I can't have unit test for this but I checked it in dev-env
@ -452,0 +463,4 @@
return extractExpirationEpoch(attributes)
}
func extractExpirationEpoch(attributes []objectSDK.Attribute) (uint64, bool) {
Owner

Without consulting with the SDK PR: I don't like this logic, we now have 2 functions that extract expiration epoch, it is very easy to use the wrong one. It is not obvious which one I should use in any given situation.

Without consulting with the SDK PR: I don't like this logic, we now have 2 functions that extract expiration epoch, it is very easy to use the wrong one. It is not obvious which one I should use in any given situation.
Author
Member

This changes are not needed anymore, removed

This changes are not needed anymore, removed
a-savchuk force-pushed ec-object-expiration from f660e8bc69 to e28586d027 2025-01-17 09:43:01 +00:00 Compare
a-savchuk force-pushed ec-object-expiration from e28586d027 to 30d4530b6d 2025-02-02 15:25:41 +00:00 Compare
a-savchuk changed title from WIP: metabase: Mark chunk's parent as expirable instead of chunk itself to WIP: Make complex object stored with EC expire correctly 2025-02-03 06:16:53 +00:00
a-savchuk force-pushed ec-object-expiration from 30d4530b6d to 9c4c5a5262 2025-02-03 11:29:22 +00:00 Compare
a-savchuk removed the
blocked
label 2025-02-03 11:31:27 +00:00
a-savchuk changed title from WIP: Make complex object stored with EC expire correctly to Make complex object stored with EC expire correctly 2025-02-03 11:31:28 +00:00
requested reviews from storage-core-developers, storage-core-committers 2025-02-03 11:31:56 +00:00
acid-ant approved these changes 2025-02-03 11:37:17 +00:00
fyrchik approved these changes 2025-02-03 11:47:12 +00:00
fyrchik merged commit 9c4c5a5262 into master 2025-02-03 11:52:01 +00:00
fyrchik referenced this pull request from a commit 2025-02-03 11:52:01 +00:00
fyrchik added this to the v0.45.0 milestone 2025-02-03 11:52:07 +00:00
fyrchik referenced this pull request from a commit 2025-02-04 10:32:24 +00:00
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: TrueCloudLab/frostfs-node#1602
No description provided.