Support Expiration Lifecycle #93

New issue

Open

opened 2025-12-28 17:36:16 +00:00 by sami · 4 comments

sami commented

2025-12-28 17:36:16 +00:00

Owner

Originally created by @KirillovDenis on GitHub (Aug 5, 2021).

Should we support lifecycle? https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html
I suppose there are some restriction (if we want to support it):

Support only Expiration actions (available Expiration actions and Transition actions) because s3-gw can not handle storage classes (or it will be?)
Expiration actions will only work in the context of the gateway, and the gateway must store the user's credentials

Originally created by @KirillovDenis on GitHub (Aug 5, 2021). Should we support lifecycle? https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html I suppose there are some restriction (if we want to support it): * Support only `Expiration actions` (available `Expiration actions` and `Transition actions`) because s3-gw can not handle storage classes (or it will be?) * `Expiration actions` will only work in the context of the gateway, and the gateway must store the user's credentials

sami added the

feature

labels

2025-12-28 17:36:16 +00:00

sami commented

2025-12-28 17:36:16 +00:00

Author

Owner

@realloc commented on GitHub (Aug 12, 2021):

We can't use NeoFS exipration attributes here, because in S3 the object lifecycle/expiration is mutable.

@realloc commented on GitHub (Aug 12, 2021): We can't use NeoFS exipration attributes here, because in S3 the object lifecycle/expiration is mutable.

sami commented

2025-12-28 17:36:16 +00:00

Author

Owner

@alexvanin commented on GitHub (Aug 26, 2021):

Good use case for serverless functions to handle actions after expiration.

@alexvanin commented on GitHub (Aug 26, 2021): Good use case for serverless functions to handle actions after expiration.

sami commented

2025-12-28 17:36:16 +00:00

Author

Owner

@KirillovDenis commented on GitHub (Jun 21, 2022):

Blocked by https://github.com/nspcc-dev/neofs-api/issues/226

@KirillovDenis commented on GitHub (Jun 21, 2022): Blocked by https://github.com/nspcc-dev/neofs-api/issues/226

sami commented

2025-12-28 17:36:16 +00:00

Author

Owner

@KirillovDenis commented on GitHub (Jun 21, 2022):

Still there are some questions:

Access rights.

We need a bearer token to be able to delete an object after appropriate tick happens.
We can store this info (address of the object with access box) in user-defined tick data https://github.com/nspcc-dev/neofs-api/issues/226)

Where we should store expiration object info:

In the version tree
- Pros: One request to tree service during head object request.
- Cons: Complicated logic to retrieve expiration info because the node in tree will be sibling for object version nodes
In the expiration tree
- Pros: Simple logic
- Cons: Additional request to the tree service on every head/get object request
Don't store expiration info at all and compute it on every request using cached lifecycle configuration
- Pros: There is not extra request to the tree service
- Cons: More CPU intensive every head/get object request

It seems we have to extend object/expiration info that stored in tree service by object size to be able to get rid of head request.

@KirillovDenis commented on GitHub (Jun 21, 2022): Still there are some questions: #### Access rights. We need a bearer token to be able to delete an object after appropriate tick happens. We can store this info (address of the object with access box) in user-defined tick data https://github.com/nspcc-dev/neofs-api/issues/226) #### Where we should store expiration object info: 1. In the `version ` tree - Pros: One request to tree service during head object request. - Cons: Complicated logic to retrieve expiration info because the node in tree will be sibling for object version nodes 2. In the `expiration` tree - Pros: Simple logic - Cons: Additional request to the tree service on every head/get object request 3. Don't store expiration info at all and compute it on every request using cached lifecycle configuration - Pros: There is not extra request to the tree service - Cons: More CPU intensive every head/get object request It seems we have to extend object/expiration info that stored in tree service by object size to be able to get rid of head request.