-
Notifications
You must be signed in to change notification settings - Fork 241
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Keep original MPU object etag after restore #5683
Conversation
Hello kerkesni,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 |
4635b80
to
a8c2e45
Compare
Waiting for approvalThe following approvals are needed before I can proceed with the merge:
|
8986a75
to
9781ee3
Compare
9781ee3
to
2d7ff35
Compare
When restoring an MPU, the object data might be PUT with a different number of parts, which in turn changes the etag of the object as it is calculated based on the etag of each uploaded part. We now keep the same etag in case of a restore to avoid breaking the expiration of the restored object as it checks the etag of the object before expiting. The new etag is kept in the metadata of the object and can be viewed with a head-object operation when passing the "x-amz-scal-archive-info" header. Issue: CLDSRV-564
Keep the version from lockfile, pending a proper release. It also seems "latest" changes cannot be integrated at the moment. Also, need to use specific version of typescript, as scubaclient does not (reportedly) support latest releases (5.x). Issue: CLDSRV-562
2d7ff35
to
38dd70e
Compare
/approve |
I have successfully merged the changeset of this pull request
The following branches have NOT changed:
Please check the status of the associated issue CLDSRV-564. Goodbye kerkesni. The following options are set: approve |
When restoring an MPU, the object data might be PUT with a different number of parts, which in turn changes the etag of the object as it is calculated based on the etag of each uploaded part.
We now keep the same etag in case of a restore to avoid breaking the expiration of the restored object as it checks the etag of the object before expiting.
The new etag is kept in the metadata of the object and can be viewed with a head-object operation when passing the
x-amz-scal-archive-info
header.The new etag field is added to the
x-amz-restore
section of the metadata, so it will be removed when the object expires.Issue: CLDSRV-564