| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
Hello francoisferrand,My role is to assist you with the merge of this
Status report is not available. |
Sorry, something went wrong.
Incorrect fix versionThe Fix Version/s in issue CLDSRV-917 contains:
Considering where you are trying to merge, I ignored possible hotfix versions and I expected to find:
Please check the Fix Version/s of CLDSRV-917, or the target |
Sorry, something went wrong.
❌ 5 Tests Failed:
To view more test analytics, go to the Test Analytics Dashboard |
Sorry, something went wrong.
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
| Back | FazBrowse Home | New Git URL |
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, 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 from there. Cloudserver writes no Kafka message itself, and a requeue keeps the flag set.
Resulting metadata for such a write:
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, 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, since validStorageClasses only holds uppercase values.
Issue: CLDSRV-917