errose28 opened a new pull request, #10443: URL: https://github.com/apache/ozone/pull/10443
**DRAFT** Requires https://github.com/apache/ozone/pull/10366, https://github.com/apache/ozone/pull/10367, https://github.com/apache/ozone/pull/10368, https://github.com/apache/ozone/pull/10370, https://github.com/apache/ozone/pull/10376, and #10437 to be merged. This PR contains those changes as well. ## What changes were proposed in this pull request? Create a new `ReconVersionManager` and corresponding upgrade action provider to manage Recon's versions and finalization. By switching Recon to the same framework as other components, we are able to remove a large amount of custom upgrade code that was previously unique to Recon. Recon currently handles finalization differently than other components and this is unchanged by this PR: - Recon finalizes automatically on startup. The move of the apparent version to match its software version is only to run reformatting actions. - Recon never used the component version framework previously, so we can switch its `ReconLayoutFeature` class to `ReconVersion implements ComponentVersion` with no migration concerns - Recon also has an `HDDSVersion` the same as SCM and Datanode inside its `NodeManager` implementation, which is stored in a VERSION file. ### Existing Issues Fixed - Before this PR, the persisted HDDS version in Recon was never updated, so it would remain at the software version Recon was first initialized in. This just happened to work because Recon's `NodeManager` was only depending on apparent version (MLV before the switch) for debug logging. - This may not be true going forward, so this PR finalizes the HDDS version with the Recon version on startup. - In HDDS-15482 we should finalize this HDDS Version when Recon sees a finalized Datanode to keep Recon's HDDS version in sync with SCM and Datanode. - HDDS-15482 will also add logging based on the software/apparent version matrix between SCM and Recon. The existing logging has been removed for now. - The standard in the upgrade framework is that `INITIAL_VERSION` serializes to `0`, and represents the state before any upgrade framework was introduced, meaning no version is found on disk. `-1` is the in-memory serialized value representing an unknown/future version in the `ComponentVersion` framework. - Recon was using `-1` as the in-memory placeholder to represent no version on disk, and then `INITIAL_VERSION = 0` as the first version to introduce the upgrade framework. The creates a conflict with the standard versioning framework - Recon had an upgrade action tied to `INITIAL_VERSION`, which ran because initialization moved from version `-1` to `0`. - To fix this, Recon's initialization code now reads no version being present as the initial `0` version. The upgrade action tied to version `0` was merged into version `1`'s upgrade action, so it will still run if upgrading to this version from an old version before the versioning framework. - Recon previously ran upgrade actions and apparent version increases in the same SQL transaction. This is no longer required after #10442 which allows us to use shared `ComponentVersionManager` code for this. ## What is the link to the Apache JIRA HDDS-15374 ## How was this patch tested? Unit tests for new Recon version manager added. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
