CLDSRV-374 putMetadata API route is not updating null version properly#5167
Conversation
|
ping |
Hello nicolas2bert,My role is to assist you with the merge of this 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 |
|
ping |
ConflictA conflict has been raised during the creation of I have not created the integration branch. Here are the steps to resolve this conflict: $ git fetch
$ git checkout -B w/8.5/bugfix/CLDSRV-374/put-metadata-null origin/development/8.5
$ git merge origin/w/7.70/bugfix/CLDSRV-374/put-metadata-null
$ # <intense conflict resolution>
$ git commit
$ git push -u origin w/8.5/bugfix/CLDSRV-374/put-metadata-null |
Integration data createdI have created the integration data for the additional destination branches.
The following branches will NOT be impacted:
You can set option |
Waiting for approvalThe following approvals are needed before I can proceed with the merge:
|
lib/routes/routeBackbeat.js
Outdated
| // versionId | ||
| const options = { | ||
| versioning: bucketInfo.isVersioningEnabled(), | ||
| versioning, |
There was a problem hiding this comment.
It could be cleaner to
- prepare the final
versioningandversionIdfields to pass in options - build the
optionsobject with those two fields
There was a problem hiding this comment.
I did not change the existing logic much to have the change easily forwarded into development/8.x branches which have a slightly different logic.
lib/routes/routeBackbeat.js
Outdated
| if (versioning && !nullVersionId) { | ||
| // If the null version does not have a version id, it is a current null version. | ||
| // To update the metadata of a current version, versioning is set to false. | ||
| options.versioning = false; |
There was a problem hiding this comment.
Beware of this, as option fields are converted to strings when passed to Metadata (through the query string), there's a good chance that we interpret versioning: "false" as being true in Metadata, I'd rather recommend to not pass versioning at all if it is false. Metadata should have better parsing of its options on the other hand but I don't think it's done properly now.
048a10b to
56ffbb2
Compare
History mismatchMerge commit #048a10b191caa788ca526a2690d2a75177e0ad1a on the integration branch It is likely due to a rebase of the branch Please use the |
18e0f2b to
1df4eb9
Compare
lib/routes/routeBackbeat.js
Outdated
| // NOTE: When 'versioning' is set to true and no 'versionId' is specified, | ||
| // it results in the creation of a "new" version, which also updates the master. |
There was a problem hiding this comment.
Possibly this comment could fit better above if (versioning) {
| .then(() => done()); | ||
| }); | ||
|
|
||
| it('should update metadata of a current null version', done => { |
There was a problem hiding this comment.
Would you mind adding some similar tests on versioning-suspended buckets:
- when there is an existing null version
- when there is no existing null version
and make sure we only delete the data when a prior null version exists
There was a problem hiding this comment.
In S3C, the use of the "putMetadata" call is restricted to versioned buckets.
I will add tests for Zenko/Artesca branches that support PUT metadata for non-versioned buckets.
lib/routes/routeBackbeat.js
Outdated
| // - if a version ID is provided in the query string (updating MD of a specific version) OR | ||
| // - if no version ID provided and versioning is not enabled (updating MD of the master key), | ||
| // data locations are allowed to be removed as they will be overwritten. | ||
| (versionId || !versioning) && |
There was a problem hiding this comment.
I have a doubt that we may remove valid data in the following case, not completely sure, to be checked:
- versioning-suspended bucket
- no existing null version
I am thinking that if objMd is the metadata of the current master (a real version), we may remove the master's data and create a new null version, making the old master unreadable.
There was a problem hiding this comment.
If there is no existing null version, the object MD (objMd) of the null version will be undefined, resulting in the condition being false.
1df4eb9 to
f2e9446
Compare
f2e9446 to
16024d6
Compare
Incorrect fix versionThe
Considering where you are trying to merge, I ignored possible hotfix versions and I expected to find:
Please check the |
|
While it's not the preferred scenario, due to the urgent need to implement this fix in Artesca, we will initially integrate it into the development/8.7 branch and subsequently backport it to the development/7.x branches. |
Waiting for approvalThe following approvals are needed before I can proceed with the merge:
|
0f59a73 to
16434a4
Compare
| .then(() => done()); | ||
| }); | ||
|
|
||
| describe.only('null version', () => { |
There was a problem hiding this comment.
We eliminated the '.skip' modifier in the 'describe' section of the parent.
Initially, all tests were being skipped.
However, I unskipped them and only executed the null test for the time being.
To address the remaining routeBackbeat tests, I created a follow-up task CLDSRV-394, which is mentioned here: https://github.com/scality/cloudserver/pull/5167/files#diff-e346bc0177b28612b0892a923d8c1d33429b4d7a3c8bd955aadf6e3ccb701dcdR1281.
There was a problem hiding this comment.
It may cause confusion to have a committed .only test, usually we follow the pattern of skipping tests until they pass, I think we should follow this scheme here too, so skipping the rest of the tests in this suite and removing .only of the only test we'd like to activate may be more appropriate.
| it('should create a new null version if versioning suspended and no version', done => { | ||
| let objMD; | ||
| return async.series([ | ||
| next => s3.putBucketVersioning({ Bucket: bucket, VersioningConfiguration: { Status: 'Enabled' } }, |
There was a problem hiding this comment.
You don't need to enable versioning before suspending it, you can just put a versioning-suspended status on a nonversioned bucket (same for the other tests).
There was a problem hiding this comment.
Indeed, I simply prefer having it Enabled prior to Suspending it as it feels more instinctive to me.
However, as enabling it beforehand is not obligatory, I will eliminate that step.
| next), | ||
| next => s3.putBucketVersioning({ Bucket: bucket, VersioningConfiguration: { Status: 'Suspended' } }, | ||
| next), | ||
| next => s3.putObject({ Bucket: bucket, Key: keyName, Body: new Buffer(testData) }, next), |
There was a problem hiding this comment.
Is it useful to PUT and DELETE an object prior to using the backbeat PUT?
There was a problem hiding this comment.
For the test to be closer to reality and to be able "GET" the null version metadata that I will later "PUT".
| next), | ||
| next => s3.putBucketVersioning({ Bucket: bucket, VersioningConfiguration: { Status: 'Suspended' } }, | ||
| next), | ||
| next => s3.putObject({ Bucket: bucket, Key: keyName, Body: new Buffer(testData) }, next), |
There was a problem hiding this comment.
There's probably no need to PUT an object first before DELETE, as a DELETE would normally put a delete marker with a null version.
There was a problem hiding this comment.
Same reason as earlier.
Also, we create the object to GET its metadata.
In my opinion, this appears to be a more realistic scenario.
|
Thanks for the extensive test coverage @nicolas2bert |
16434a4 to
9205084
Compare
Instead of using the provided "null" value, the metadata "null version id" is now used when updating the metadata of a null version.
9205084 to
50cb6a2
Compare
|
@bert-e approve |
In the queueThe changeset has received all authorizations and has been added to the The changeset will be merged in:
The following branches will NOT be impacted:
There is no action required on your side. You will be notified here once IMPORTANT Please do not attempt to modify this pull request.
If you need this pull request to be removed from the queue, please contact a The following options are set: 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-374. Goodbye nicolas2bert. |
Revert 7e405ff, as it prevents creating new versions in versioned buckets when not specifying versionId. The proper fix was introduced later in [2] [1] #4655 [2] #5167 Issue: CLDSRV-394
Revert 7e405ff, as it prevents creating new versions in versioned buckets when not specifying versionId. The proper fix was introduced later in [2] [1] #4655 [2] #5167 Issue: CLDSRV-394
Revert 7e405ff, as it prevents creating new versions in versioned buckets when not specifying versionId. The proper fix was introduced later in [2] [1] #4655 [2] #5167 Issue: CLDSRV-394
Revert 7e405ff, as it prevents creating new versions in versioned buckets when not specifying versionId. The proper fix was introduced later in [2] [1] #4655 [2] #5167 Issue: CLDSRV-394
Revert 7e405ff, as it prevents creating new versions in versioned buckets when not specifying versionId. The proper fix was introduced later in [2] [1] #4655 [2] #5167 Issue: CLDSRV-394
Revert 7e405ff, as it prevents creating new versions in versioned buckets when not specifying versionId. The proper fix was introduced later in [2] [1] #4655 [2] #5167 Issue: CLDSRV-394
Revert 7e405ff, as it prevents creating new versions in versioned buckets when not specifying versionId. The proper fix was introduced later in [2] [1] #4655 [2] #5167 Issue: CLDSRV-394
Revert 7e405ff, as it prevents creating new versions in versioned buckets when not specifying versionId. The proper fix was introduced later in [2] [1] #4655 [2] #5167 Issue: CLDSRV-394
Revert 7e405ff, as it prevents creating new versions in versioned buckets when not specifying versionId. The proper fix was introduced later in [2] [1] #4655 [2] #5167 Issue: CLDSRV-394
Instead of using the provided "null" value, the metadata "null version id" is used when updating the metadata of a null version.
Note: In S3C, the use of the "putMetadata" call is restricted to versioned buckets.
Issue: CLDSRV-374