Hi Jun, On Thu, Mar 28, 2024 at 10:35 AM Jun Rao <j...@confluent.io.invalid> wrote: > The following are the steps of AddVoter. The bulk of the time is probably > in step 5, but the updated VotersRecord won't be written until step 6. So, > ideally, the controller leader should report the pending voter as soon as > step 1. The brokers and non-leader controllers can't do that until after > step 6. Having multiple brokers report the same metric can be confusing > when there is inconsistency.
First, the replicas (leader, following voters and observers) will compute the metrics the same way. In other words, in the leader the uncommitted-voter-change metric will be true (1) from step 7 to after step 8. I added the metric to indicate to the operator if there are replicas that have updated their voters set to a value that is uncommitted value. The leader doesn't update its voters set until step 7. I don't think that we should add metrics to track the state of a specific RPC. Or if we do, it should be a seperate KIP where we have a mechanism for consistently tracking this state across all admin RPCs. What do you think? Thanks, -- -José
