Skip to content

Conversation

@sumitagrawl
Copy link
Contributor

@sumitagrawl sumitagrawl commented Jan 19, 2025

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.

  1. Make use of OM managed index as IndexManager class which will generate index, save commit index, on leader change action to update index
  2. Persist Index in TransactionInfoTable as #OMINDEX during doubleBuffer commit operation
  3. Support OMLayout Feature flag for handling upgrade and reinit on finalize

Flow:
ClientRequest: --> OmExecutionFlow --> generate index and add to Request ---> submit to ratis
Ratis: ApplyTransaction --> retrieve index and update ExecutionContext --> perform operation

Usages:

  1. It will simplify applying om db from production environment to local for debug purpose, as ratis index impact will not cause failure to start.

  2. Will be used for pre-ratis execution feature

Refer (HDDS-11898. design doc leader side execution) for Index generation and Step-by-step incremental changes for existing flow

Parent 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?

  • Unit test case
  • Existing integration test for any impact

@sumitagrawl sumitagrawl added the om-pre-ratis-execution PRs related to https://issues.apache.org/jira/browse/HDDS-11897 label Jan 19, 2025
@sumitagrawl sumitagrawl marked this pull request as ready for review February 17, 2025 14:46
@adoroszlai adoroszlai marked this pull request as draft February 17, 2025 14:54
@adoroszlai
Copy link
Contributor

Sorry for cancelling the workflow. I will resolve conflicts after HDDS-12277 and trigger CI.

@adoroszlai adoroszlai self-assigned this Feb 17, 2025
Copy link
Contributor

@adoroszlai adoroszlai left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @sumitagrawl for the patch.

@sumitagrawl
Copy link
Contributor Author

@adoroszlai resolved all comments and fixed license header changes, please review again

@adoroszlai
Copy link
Contributor

fixed license header changes

I have already fixed license headers, see:

@sumitagrawl sumitagrawl marked this pull request as ready for review February 19, 2025 16:16
@adoroszlai
Copy link
Contributor

Thanks @sumitagrawl for addressing my comments. I'll let others review as well.

}
index.set(initIndex);
commitIndex.set(initIndex);
if (ozoneManager.getVersionManager().needsFinalization()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated

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();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As every OM has its IndexGenerator, which works independently, could you explain a little bit here, what the onLeaderChange actually do?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ratis generate termIndex for below cases:

  1. transaction update via applyTransaction()
  2. 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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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
Copy link
Contributor Author

@ChenSammi updated the comments and code, plz review again

@ChenSammi
Copy link
Contributor

ChenSammi commented Mar 3, 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 sumitagrawl marked this pull request as draft March 20, 2025 05:56
@sumitagrawl
Copy link
Contributor Author

@ChenSammi Please review the changes done for fix

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?

As change, ExecutionControlRequest parameter is added, and leader will append index generated before submit the request. This will resolve the above problem.

@adoroszlai
Copy link
Contributor

Should this be targeted at the feature branch?

@adoroszlai adoroszlai closed this Jun 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

om-pre-ratis-execution PRs related to https://issues.apache.org/jira/browse/HDDS-11897

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants