-
Notifications
You must be signed in to change notification settings - Fork 19
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
ARSN-350 Missing Null Version in Lifecycle List of Non-Current Versions #2150
Conversation
Hello nicolas2bert,My role is to assist you with the merge of this Status report is not available. |
19c9ac1
to
98567d0
Compare
Waiting for approvalThe following approvals are needed before I can proceed with the merge:
|
98567d0
to
ae1fd6e
Compare
ae1fd6e
to
b9e1a1e
Compare
this.staleDate = this.getLastModified(value); | ||
return FILTER_ACCEPT; | ||
} | ||
|
||
const isCurrentVersion = this.masterKey === key && this.masterVersionId === versionId; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If delete markers are also candidates for expiration, they don't have an associated master key even though they can be current. The way to know whether they are current is if the previous key in the merged M+V listing is a different key, or if it's the very first key of the listing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Delete markers have a version ID that is correctly ordered.
- It doesn't matter if the current delete marker doesn't have a master when listing non-current versions.
The first version key in the listing should store the "delete marker" version and will be skipped.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, just to make sure, I added tests for delete marker here: scality/cloudserver#5231
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should also keep in mind that at some point, Artesca may enable null keys on Cloudserver (the change to allow V1 metadata to be more performant), and this listing algo doesn't seem to support them properly. Not needed urgently as currently Cloudserver on Artesca is hard-coded not to use null keys although the code is there, but we should probably track this in some way to avoid forgetting about it the day we decide to switch to null keys in Artesca.
This is where the compat mode (not to use null keys) is forcefully enabled today:
@jonathan-gramain Is there a ticket for Artesca to support "null keys"? |
@nicolas2bert it would be part of the work to use 8.x branches for S3C, I don't think there is an EPIC for this but it should go in there. I'll check this. The current Arsenal code for DelimiterVersions supports null keys, as it was forward-ported from 7.70 (for example: https://github.com/scality/Arsenal/blob/development/8.1/lib/algos/list/delimiterVersions.ts#L302) |
ConflictThere is a conflict between your branch Please resolve the conflict on the feature branch ( git fetch && \
git checkout origin/bugfix/ARSN-350/lifecycle-listing && \
git merge origin/development/8.1 Resolve merge conflicts and commit git push origin HEAD:bugfix/ARSN-350/lifecycle-listing |
Note: We only support the v1 bucket format for "list lifecycle" in Artesca. We made the assumption that the first version key stored the current/latest version, which is true in most cases except for "null" versions. In the case of a "null" version, the current version is stored in the master key alone, rather than being stored in both the master key and a new version key. Here's an example of the key structure: Mkey0: Represents the null version ID. VKey0<versionID>: Represents a non-current version. Additionally, we assumed that the versions for a given key were ordered by creation date, from newest to oldest. However, in Ring S3C, for non-current null versions, the metadata version ID is not part of the metadata key id. Therefore, the non-current null version is listed before the current version that has a version ID. Here's an example of the key ordering: Mkey0: Master version Vkey0: "null" non-current version VKey0<versionID>: Current version The listing was using only versions, but because those assumptions are incorrect, we now use both the master and the versions for each given key to ensure that we return the correct non-current versions.
732f398
to
7c4f461
Compare
Waiting for approvalThe following approvals are needed before I can proceed with the merge:
|
Codecov Report
@@ Coverage Diff @@
## development/8.1 #2150 +/- ##
===================================================
+ Coverage 64.34% 64.41% +0.06%
===================================================
Files 210 210
Lines 16381 16412 +31
Branches 3316 3324 +8
===================================================
+ Hits 10541 10572 +31
Misses 5825 5825
Partials 15 15
|
@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 ARSN-350. Goodbye nicolas2bert. |
Note: We only support the v1 bucket format for "list lifecycle" in Artesca.
We made the assumption that the first version key stored the current/latest version, which is true in most cases except for "null" versions. In the case of a "null" version, the current version is stored in the master key alone, rather than being stored in both the master key and a new version key. Here's an example of the key structure:
Mkey0
: Represents the null version ID.VKey0<versionID>
: Represents a non-current version.Additionally, we assumed that the versions for a given key were ordered by creation date, from newest to oldest. However, in Ring S3C, for non-current null versions, the metadata version ID is not part of the metadata key id. Therefore, the non-current null version is listed before the current version that has a version ID. Here's an example of the key ordering:
Mkey0
: Master versionVkey0
: "Null" Non-current versionVKey0<versionID>
: Current versionThe listing was using only versions, but because those assumptions are incorrect, we now use both the master and the versions for each given key to ensure that we return the correct non-current versions.