Hi, Jose, Thanks for the reply.
If I am adding a new voter and it takes a long time (because the new voter is catching up), I'd want to know if the request is indeed being processed. I thought that's the usage of uncommitted-voter-change. Also, I am still not sure about having multiple brokers reporting the same metric. For example, if they don't report the same value (e.g. because one broker is catching up), how does a user know which value is correct? Thanks, Jun On Thu, Mar 28, 2024 at 10:56 AM José Armando García Sancio <jsan...@confluent.io.invalid> wrote: > 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é >
