HDDS-15417. Handle mixed datanode versions on the replication path#10570
Open
dombizita wants to merge 3 commits into
Open
HDDS-15417. Handle mixed datanode versions on the replication path#10570dombizita wants to merge 3 commits into
dombizita wants to merge 3 commits into
Conversation
…mment to getLowestCommonApparentVersion.
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
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?
Datanodes act in a client server relationship between themselves for replication. In general the replication process is quite simple - commands are sent to a datanode hosting a container replica (the replication client), and it is told to push/upload the data to another node (the replication server). Incompatible changes in this area can be handled in a similar way to write requests.
SCM knows the apparent version of all Datanodes since their last heartbeat. The last known apparent version of the target/server Datanode can be included in the replicate command sent by SCM to the source/client Datanode. It is always the job of the newer component to handle compatibility, whether it involves software or apparent version. If the source/client Datanode is newer in software or apparent version, it must "downgrade" its request to the lowest common apparent version supported by the server indicated by the SCM command. A newer target/server Datanode will not make incompatible changes to existing APIs, so old client Datanodes will continue to work.
Changes in this patch:
Used Claude Opus 4.6.
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-15417
How was this patch tested?
Green CI on my fork: https://github.com/dombizita/ozone/actions/runs/27760621062