CLDSRV-917: allow writing objects directly to a cold location - #6264
CLDSRV-917: allow writing objects directly to a cold location#6264francoisferrand wants to merge 1 commit into
Conversation
Hello francoisferrand,My role is to assist you with the merge of this Available options
Available commands
Status report is not available. |
Incorrect fix versionThe
Considering where you are trying to merge, I ignored possible hotfix versions and I expected to find:
Please check the |
❌ 5 Tests Failed:
View the full list of 5 ❄️ flaky test(s)
To view more test analytics, go to the Test Analytics Dashboard |
555417e to
73b5a05
Compare
Users had no way to store an object in a cold location without first writing it hot and waiting for a lifecycle transition rule to kick in, which is impractical when the intent is known upfront. PutObject, CreateMultipartUpload and CopyObject now accept the name of a cold location in x-amz-storage-class. The data is still written to the hot location as usual, but the object is stamped with the cold storage class and flagged as transition-in-progress, so the lifecycle queue populator picks it up from the oplog and drives the transition. No Kafka message is written by cloudserver itself, and a requeue keeps the flag. This is gated by a new off-by-default `enableDirectToCold` option (ENABLE_DIRECT_TO_COLD). Which identities may use a given storage class is left to the existing s3:x-amz-storage-class IAM condition key. Also drops the dead CLDSRV-639 lowercase/uppercase storage class handling in CreateMultipartUpload: the value is validated beforehand, so it can be stored as-is. Issue: CLDSRV-917
73b5a05 to
fa0442f
Compare
Users had no way to store an object in a cold location without first writing it hot and waiting for a lifecycle transition rule to kick in — impractical when the intent is already known at write time.
PutObject,CreateMultipartUploadandCopyObjectnow accept the name of a cold location inx-amz-storage-class. The data is still written to the hot location as usual, but the object is stamped with the cold storage class and flagged as transition-in-progress, so the lifecycle queue populator picks it up from the oplog and drives the transition from there. Cloudserver writes no Kafka message itself, and a requeue keeps the flag set.Resulting metadata for such a write:
x-amz-storage-classdataStoreNamearchivex-amz-scal-transition-in-progresstruex-amz-scal-transition-timeoriginOpPut/CompleteMultipartUpload/Copy)Gated by a new off-by-default
enableDirectToColdoption (ENABLE_DIRECT_TO_COLD). Which identities may use a given storage class is left to the existings3:x-amz-storage-classIAM condition key, so there is no new authorization code here.Also drops the dead CLDSRV-639 lowercase/uppercase storage class juggling in
CreateMultipartUpload— the value is validated beforehand, so it can just be stored as-is. That code could never match anyway, sincevalidStorageClassesonly holds uppercase values.Issue: CLDSRV-917