HDDS-15063. Switch OM to the new Versioning Framework#10099
Merged
errose28 merged 14 commits intoApr 29, 2026
Conversation
…d small cleanups - Add ComponentVersionManager / HDDSVersionManager / OMVersionManager and related upgrade framework pieces (no OM production wiring). - Move @DisallowedUntilLayoutVersion onto preExecute for snapshot move requests; minor DN/doc/repair/freon cleanups. - Include HDDS-side renames and SCM wiring updates that accompany the version-manager refactor (no functional change on the HDDS side). - Keep LayoutVersionManager + AbstractLayoutVersionManager implementing it until OM wiring PR (HDDS matches feature except those two files). - Include OM wire-compatibility/doc/deprecation proto tweaks, OMStorage apparent-version init alignment, finalize-upgrade response naming, and a comment clarification in OzoneManagerRequestHandler (no OM prod wiring).
…ntVersion() for PR1 compile Made-with: Cursor
…Version() for PR1 compile Made-with: Cursor
…age#getLayoutVersion Made-with: Cursor
…g PR Made-with: Cursor
…ng PR Made-with: Cursor
errose28
added
the
zdu
* HDDS-14496-zdu: HDDS-14940. Create skeleton for ozone admin upgrade status command (apache#10011)
* HDDS-14496-zdu: HDDS-14826. Prepare OM to switch from LayoutVersionManager to ComponentVersionManager (apache#10098) HDDS-14896. Use separate container for clients in rolling-upgrade suite (apache#10032) HDDS-15034. Query SCM status for ozone admin upgrade status command (apache#10084) HDDS-14897. Add multiple S3 gateways to the rolling-upgrade suite (apache#10028) hadoop-ozone/ozone-manager/src/main/java/org/apache/hadoop/ozone/om/OMStorage.java hadoop-ozone/ozone-manager/src/main/java/org/apache/hadoop/ozone/om/OzoneManager.java hadoop-ozone/ozone-manager/src/test/java/org/apache/hadoop/ozone/om/TestOMStorage.java hadoop-ozone/ozone-manager/src/test/java/org/apache/hadoop/ozone/om/upgrade/TestOMUpgradeFinalizer.java
* HDDS-14496-zdu: HDDS-15126. Remove unused TestHDDSUpgrade (apache#10148)
Contributor
Author
|
Thanks @sodonnel for the review. Merging this into the feature branch so we can continue switching the other components over. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changes were proposed in this pull request?
This completely migrates OM to the new versioning framework. This includes:
OMVersionManagerinstead ofOMLayoutVersionManagerin all places.OMLayoutFeatureAspect, it exposed a bug where some existing snapshot requests had not applied the annotation topreExecuteand were checking against a default (always finalized)OMLayoutVersionManager. This buggy fallback path has been removed and the annotations moved to their correct spot.OzoneManagerVersioninstead ofOMLayoutFeaturefor all new versionsOMVersionManagerinstead ofBasicUpgradeFinalizer/OMUpgradeFinalizerandDefaultUpgradeFinalizationExecutorZDUUnused classes that were specific to OM are removed, but some classes like
BasicUpgradeFinalizerare still used by HDDS Components which have not been migrated yet.Note that upgrade actions can still only be bound to
LayoutFeatures. Because an annotation's field cannot be an interface likeComponentVersion, we cannot use the same annotation to bind upgrade actions to layout features and component versions. This does not cause any immediate problems since only existing versions tracked asLayoutFeatures have upgrade actions, but will need to be addressed in a follow-up so we can continue to add new upgrade actions.What is the link to the Apache JIRA
HDDS-15063
How was this patch tested?
New functionality within the version framework was unit tested in #10098. In this PR all existing upgrade tests are passing on my fork.