Hello Federico Please note that the topic-based RLMM is one of the possible implementations of RLMM. Hence, whatever solution we design here should: 1\ be explicit that this tooling only works for topic based RLMM 2\ specify the handling of the failure mode when topic based RLMM is not being used.
I would argue that Topic based RLMM cannot be treated the same as other internal topics. Topic based RLMM topic is an optional topic which can have any possible schema (depending on plugin implementation) whereas other internal topics are always guaranteed to be present with a fixed schema. In light of the above statements, the rejected alternative sounds better to me because: 1\ it provides the ability to dump logs for "any" RLMM implementation and not just topic based RLMM. 2\ we don't have to deal with schema evolution of topic based RLMM in this tool. That responsibility will be delegated to the decoder class which the operator can define using the flag "--value-decoder-class". Is there a reason that you are unable to use the rejected solution (which requires no changes) for debugging purposes? -- Divij Vaidya On Sat, Jun 15, 2024 at 4:43 PM Federico Valeri <fedeval...@gmail.com> wrote: > Hi all, > > I'd like to kick off a discussion for KIP-1057, that proposes to add > remote log metadata flag to the dump log tool, which is useful when > debugging. > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1057%3A+Add+remote+log+metadata+flag+to+the+dump+log+tool > > Thanks, > Fede >
