Hello devs, I am writing this to propose a public tooling API for offline Raft log operations.
There is currently a gap for downstream projects that need to safely inspect or repair Raft log segments. Projects can often read enough information to proceed, but when they need deeper interaction with segment metadata and entry rewrite logic, they are forced to: - use filename parsing or regex-based logic - rely on internal *ratis-server* classes/packages - duplicate implementation logic that may diverge from Ratis internals over time. The proposal is to provide a tooling contract through *ratis-server-api* so applications can interact with Ratis data using stable APIs. One example for this use-case is RATIS-2281 <https://issues.apache.org/jira/browse/RATIS-2281>. Today, Ozone may need to infer segment boundaries and perform low-level rewrite mechanics itself. This is fragile because implementation details may change as Ratis evolves. I see Nicholas has a proposal for SegmentedRaftLog v2 <https://issues.apache.org/jira/browse/RATIS-2370> which has scope for this. If this proposal is good to have I can start working in parallel to get some basic implementation done for the existing APIs. Inputs are really welcome on this. Thanking you, Abhishek
