Uh oh!
There was an error while loading. Please reload this page.
HDDS-11901. use om managed index for handling request - #7722
HDDS-11901. use om managed index for handling request#7722sumitagrawl wants to merge 11 commits into
Conversation
adoroszlai
commented
Feb 17, 2025
Sorry for cancelling the workflow. I will resolve conflicts after HDDS-12277 and trigger CI. |
Uh oh!
There was an error while loading. Please reload this page.
adoroszlai
left a comment
There was a problem hiding this comment.
Thanks @sumitagrawl for the patch.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
sumitagrawl
commented
Feb 19, 2025
@adoroszlai resolved all comments and fixed license header changes, please review again |
adoroszlai
commented
Feb 19, 2025
I have already fixed license headers, see: |
adoroszlai
commented
Feb 19, 2025
Thanks @sumitagrawl for addressing my comments. I'll let others review as well. |
| } | ||
| index.set(initIndex); | ||
| commitIndex.set(initIndex); | ||
| if (ozoneManager.getVersionManager().needsFinalization()) { |
There was a problem hiding this comment.
Should check whether this specific feature needs finalization, instead of a general needsFinalization check, as needsFinalization will return true once there is new feature added and not finalized.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
| LOG.info("{}: leader changed to {}", groupMemberId, newLeaderId); | ||
| // if the node is leader (can be ready or not ready, need update index) | ||
| if (ozoneManager.getOmRatisServer().checkLeaderStatus() != OzoneManagerRatisServer.RaftServerStatus.NOT_LEADER) { | ||
| indexGenerator.onLeaderChange(); |
There was a problem hiding this comment.
As every OM has its IndexGenerator, which works independently, could you explain a little bit here, what the onLeaderChange actually do?
There was a problem hiding this comment.
Since every OM has its IndexGenerator which works independently, could it be possible that for the same TermIndex transaction, its index has different value on different OM? If this happens, what will be the consequence?
There was a problem hiding this comment.
Ratis generate termIndex for below cases:
- transaction update via applyTransaction()
- notifyConfigChange for case of ratis internal book-keeping
IndexGenerate will generate index in pre-ratis execution for every incoming request at leader node.
So both can have different value, where mostly ratis index will be faster side.
OM will use OM index for purpose of objectId and updateId generation as used currently.
TermIndex will be used to handle replay of ratis log pending, and ensure nodes are in sync in upgrade prepare cases.
So use case will be separated and hence will not have impact.
There was a problem hiding this comment.
@ChenSammi I got the problem,
Since every node generate the index on request execution, so there is a possibility of different index value. All nodes should get index from common place in this case, will work over this to handle.
sumitagrawl
commented
Feb 25, 2025
@ChenSammi updated the comments and code, plz review again |
Per we offline discussion, I suggest to start a feature branch for all these pre-ratis execution changes, as the idea of keeping both pre-ratis execution and current per-ratis execution work is really a ideal state. But mixing the code makes it complex, hard to understand clearly, and easy to go wrong on many edge cases, for example, this new Index should not the turned on until only the OM leader will call the IndexGenerator#nextIndex(). A feature branch will save the master from broken due to intermediate development state, cases not covered, bugs, etc. |
sumitagrawl
commented
Mar 20, 2025
@ChenSammi Please review the changes done for fix
As change, ExecutionControlRequest parameter is added, and leader will append index generated before submit the request. This will resolve the above problem. |
adoroszlai
commented
Apr 3, 2025
Should this be targeted at the feature branch? |
What changes were proposed in this pull request?
Remove dependency with ratis index for OM functionality for request object. Introduced IndexManager that will keep track of OM index and provide next index for request execution.
#OMINDEXduring doubleBuffer commit operationOMLayout Feature flagfor handling upgrade and reinit on finalizeFlow:
ClientRequest: --> OmExecutionFlow --> generate index and add to Request ---> submit to ratis
Ratis: ApplyTransaction --> retrieve index and update ExecutionContext --> perform operation
Usages:
It will simplify applying om db from production environment to local for debug purpose, as ratis index impact will not cause failure to start.
Will be used for pre-ratis execution feature
Refer (HDDS-11898. design doc leader side execution) for
Index generationandStep-by-step incremental changes for existing flowParent Jira:
https://issues.apache.org/jira/browse/HDDS-11897
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-11900
How was this patch tested?