Thanks everyone for your input. Any more thoughts on this from anyone else?
I agree that this should be fixed in 3.9, as the issue is marked as a blocker. I think we might need a small KIP for it though, are we ok to include a KIP for this in the 3.9 release? I'm aware that we are past the KIP freeze and close to the feature freeze date. Regards, Gantigmaa On Fri, Jul 12, 2024 at 7:51 PM Mickael Maison <mickael.mai...@gmail.com> wrote: > Hi Igor, > > I think getting the list of all registered brokers is an administrator > requirement. Typically end users are not interested in offline > brokers. As highlighted in the Jira, the main goal for retrieving this > information is to get broker Ids to unregister. On the other hand, I > see the DescribeCluster API more aimed towards regular users. > > As mentioned in the Jira, a stray registered broker will prevent > upgrading the cluster metadata version. For that reason, I think this > is definitively something we should fix in 3.9. > > Since the field is simply called "observers", as opposed to > "currentVoters", and the response contains the lastFetchTimestamp, I > wonder if the controller could return all nodes and have the client do > the online/offline logic. > > Thanks, > Mickael > > On Thu, Jul 11, 2024 at 5:13 PM Igor Soarez <i...@soarez.me> wrote: > > > > Hi all, > > > > I had left a comment on the JIRA earlier, and thanks to Mickael I was > made > > aware of this thread, so I'll share it here too: > > > > I agree it makes sense to make this information available through > RPCs, > > but the Quorum is probably not the right place to represent > registered (but inactive) > > brokers – Quorum represents only the Raft-like part of the cluster. > > > > I think it would make more sense to add a new field to > DescribeClusterResponse. > > I guess handleDescribeCluster filters out inactive brokers to > preserve the ZK-mode behavior. > > > > Thanks, > > > > -- > > Igor > >
