Expired locked object is unavailable #2

New issue

Closed

opened 2022-12-30 10:02:49 +00:00 by abereziny · 3 comments

abereziny commented

2022-12-30 10:02:49 +00:00

(Migrated from github.com)

for details please see https://github.com/nspcc-dev/neofs-node/issues/2099#issuecomment-1367541588

Pre-requisites:

Let say current epoch is 10
Upload object via gRPC with expiration lifetime at epoch 11
Lock this object until epoch 13

Steps:

Tick epoch until current epoch is 12
Try to get object

Current Behavior:

rpc error: read object header via client: status: code = 2049 message = object not found because object was expired.
It's stated that object is still locked and not deleted, but object is unavailable (which doesn't have any sense)

Behavior that have sense:

Object should be available because locks prevents it from being deleted. (from user perspective: lock expiration should override object expiration)

Current behavior have no sense because locks should prevent object from being deleted, however, from user perspective unavailable object is the same as deleted.

Tests

bd05aae585/pytest_tests/testsuites/object/test_object_lock.py (L260),L325

for details please see https://github.com/nspcc-dev/neofs-node/issues/2099#issuecomment-1367541588 # Pre-requisites: 1. Let say current epoch is 10 2. Upload object via gRPC with expiration lifetime at epoch 11 3. Lock this object until epoch 13 # Steps: 1. Tick epoch until current epoch is 12 2. Try to get object # Current Behavior: `rpc error: read object header via client: status: code = 2049 message = object not found` because object was expired. It's stated that object is still locked and not deleted, but object is unavailable (which doesn't have any sense) # Behavior that have sense: Object should be available because locks prevents it from being deleted. (from user perspective: lock expiration should override object expiration) Current behavior have no sense because locks should prevent object from being deleted, however, from user perspective unavailable object is the same as deleted. # Tests https://github.com/TrueCloudLab/frostfs-testcases/blob/bd05aae585f9609c8c863816b51067c81a1599ce/pytest_tests/testsuites/object/test_object_lock.py#L260,L325

fyrchik commented

2023-01-12 09:44:46 +00:00

(Migrated from github.com)

Let's research how S3/different protocols behave in this way.
Do we have any particular expectations in S3 protocol? cc @alexvanin @KirillovDenis

Let's research how S3/different protocols behave in this way. Do we have any particular expectations in S3 protocol? cc @alexvanin @KirillovDenis

KirillovDenis commented

2023-01-16 07:01:35 +00:00

(Migrated from github.com)

In aws s3 and miniolocked objects cannot be deleted

More details:

locks can be set only in versioned buckets
removing by expiration latest version in versioned bucket is just creating delete-marker (it doesn't delete original version)
removing by expiration specific version in versioned bucket waits for the lock to expire

https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock-managing.html#object-lock-managing-lifecycle
https://min.io/docs/minio/linux/administration/object-management/object-retention.html#interaction-with-lifecycle-management

In `aws s3` and `minio`locked objects cannot be deleted More details: * locks can be set only in versioned buckets * removing by expiration latest version in versioned bucket is just creating `delete-marker` (it doesn't delete original version) * removing by expiration specific version in versioned bucket waits for the lock to expire https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock-managing.html#object-lock-managing-lifecycle https://min.io/docs/minio/linux/administration/object-management/object-retention.html#interaction-with-lifecycle-management

👍 1