showuon commented on PR #16491: URL: https://github.com/apache/kafka/pull/16491#issuecomment-2205215597
> Yep, ignoring the broker id can pass the reserved ids check but it fails on the default node.id. Sorry, I don't understand what you mean here. Enabling the `broker.id.generation.enable`, we'll Ignore the broker ID config. "But it fails on the default node.id" <-- what does it mean? > Explicitly defining the "broker.id=generated id" can update node.id to run Kraft components in zk broker but it fails on reserved ids check. "but it fails on reserved ids check" <-- what does it mean? If the generated ID should already within the reserved range, why do we need another check? > Regarding the second point from @chia7712 , I'm thinking the potential drawbacks of allowing node.id to be mutable. Currently, if node.id is not set, but broker.id is set, we'll set node.id=broker.id. So, we can add, if `broker.id.generation.enable` is enabled, and broker.id, node.id not set, we set them. > IMHO, could these changes lead to inconsistencies in cluster coordination and communication? Might they also cause any unpredictable behavior? Could you explain more about the inconsistencies in cluster coordination and communication situation? I might miss something. Thanks. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
