HDDS-15879. [Ozone Versioning] [T1] Metadata foundation - #10781
Conversation
| } | ||
|
|
||
| /** No-op when status is null (e.g. records without the new field). */ | ||
| public Builder setVersioningStatus(BucketVersioningStatus status) { |
There was a problem hiding this comment.
Nice work keeping the two fields in sync here! One spot that looks left behind:
OzoneManager#getBucketInfo copies only the legacy flag when resolving a link bucket:
Since SUSPENDED maps to flag=false, a suspended bucket read through a link would come back as UNVERSIONED. Should we also add .setVersioningStatus(realBucket.getVersioningStatus()) there?
There was a problem hiding this comment.
Nice catch, Updated, PTAL.
| * Returns the requested versioning status, or null if not being changed. | ||
| * @return BucketVersioningStatus | ||
| */ | ||
| public BucketVersioningStatus getVersioningStatus() { |
There was a problem hiding this comment.
Tiny one: toAuditMap() still only records IS_VERSION_ENABLED, so a status change via the new field would show up as isVersionEnabled=null in the audit log. Worth adding a versioningStatus entry while we're here?
| // absent on records that predate versioning support (treated as the null | ||
| // version). A delete marker has isDeleteMarker set and no data blocks. | ||
| // isNullVersion marks the single overwritable "null version" slot per key. | ||
| private final Long versionId; |
There was a problem hiding this comment.
Could we also add these three fields to isKeyInfoSame() (and toString())? Right now two records differing only in versionId, or a delete marker vs. a regular key, compare as equal. Looks like the follow-up tasks will rely on OmKeyInfo equality in tests; having this in the foundation would prevent false-positive assertions later. OmBucketInfo already includes the new status in both, so this would keep the two helpers consistent.
There was a problem hiding this comment.
Nice catch, Updated, PTAL.
|
@chungen0126 OEP file here: #10822 |
09d92b3 to
e89e8be
Compare
| processingPhase = RequestProcessingPhase.PRE_PROCESS, | ||
| requestType = Type.SetBucketProperty | ||
| ) | ||
| public static OMRequest disallowSetBucketPropertyWithVersioningStatus( |
There was a problem hiding this comment.
This gate covers SetBucketProperty, but CreateBucket carries the same BucketInfo.versioningStatus and persists it (OmBucketInfo.getFromProtobuf) with no matching OBJECT_VERSIONING validator — so a pre-finalized cluster would accept a CreateBucket that sets it, bypassing this contract (and the create path runs no canTransitionTo). Not triggerable yet since no client sends the field. Worth mirroring this validator on Type.CreateBucket, or a TODO + follow-up Jira.
There was a problem hiding this comment.
Good catch. Following S3 here: CreateBucket has no versioning parameter, versioning is only set on an existing bucket via PutBucketVersioning. So instead of the layout gate, T1.2 now rejects any CreateBucket carrying versioningStatus outright with INVALID_REQUEST. That covers post-finalization too, so I dropped the mirrored validator from T1.5.
1128ce3 to
e79471c
Compare
S3 gives a bucket three versioning states, while Ozone has a single isVersionEnabled boolean. This adds the three-state status alongside the flag rather than in place of it, so existing buckets and older clients go on working unchanged. BucketVersioningStatus holds the three states and the state machine that governs them: UNVERSIONED may move anywhere, but once versioning has been enabled or suspended a bucket can never return to UNVERSIONED. The proto gains a matching enum and an optional versioningStatus on both BucketInfo and BucketArgs. OmBucketInfo keeps the two representations in sync in both directions: a status derives the flag (ENABLED -> true), and a record carrying only the flag derives a status, so a bucket written before this change still answers getVersioningStatus(). Disabling the flag is the asymmetric case - it leaves an explicitly SUSPENDED status alone, since the state machine has no way back to UNVERSIONED. Nothing enforces the state machine yet; this commit only defines it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
A bucket's versioning status may only change along the state machine the previous commit defined. OMBucketSetPropertyRequest now checks the requested status against the one the bucket already holds and rejects with INVALID_REQUEST what the state machine forbids - the return to UNVERSIONED once versioning has been enabled or suspended. A request carrying only the legacy flag is mapped onto the same machine before that check: enabling always means ENABLED, while disabling means SUSPENDED, except on a bucket that is still UNVERSIONED, where it stays UNVERSIONED. The status is refused outright at bucket creation. S3 has no way to create a bucket already in a versioning state: CreateBucket carries no such parameter, and the state is set afterwards through PutBucketVersioning. versioningStatus sits on BucketInfo because that message is the bucket's on-disk record and the shape InfoBucket and ListBuckets return, not because CreateBucket needs it; honouring it there would let a caller land on any status in one step, with none of the above applied. Nothing populates the field on a create today, so the request is rejected rather than quietly ignored - ignoring it would leave a future caller believing it had created a versioned bucket. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Each section below was a separate commit; they are folded here so the task's review fixes land as one change. * Address comments * Use a 0x00 separator in versionedKeyTable dbKeys Key names in OBJECT_STORE buckets contain '/' verbatim, so a '/' separator interleaves a key's versions with those of keys nested under it, breaking the single-seek promotion and the merged ListObjectVersions order. * Do not derive a versioning status from the legacy flag Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
What changes were proposed in this pull request?
This is the first basic task of Ozone versioning, including the following points
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-15879
How was this patch tested?
unit test.