Hi Alieh, Thanks for your comments. AS01: I did look at the DescribeGroups RPC but, if we were creating that now, we would call it ClassicGroupDescribe. It really does contain all of the fields which are needed to describe a classic group such as member information and protocol. I didn't feel that bumping the version and introducing a GroupType would really solve that, so I've gone for a new RPC.
Listing groups is an expensive operation because you have to ask all brokers to list their groups, and you don't even know whether they are all group coordinator shards. At least with a describe operation, you just need to find the coordinator for that group ID and then you can describe it. I've updated the KIP with the rationale. I share your revulsion at the name DescribeGroupsGeneric :) We have occasionally renamed RPCs so I could rename DescribeGroups to ClassicGroupDescribe and then call the new one GroupDescribe. Let me know your thoughts. AS02: I went for a class in order to match the existing XxxGroupDescription classes. I could change them all over to be interfaces, but that's quite disruptive. Do you think that's worth it? I tend to think not. AS03: Done. AS04: Done. I have not yet created the JIRA and I'll do so once the vote passes. Thanks, Andrew On 2026/06/28 18:16:16 Alieh Saeedi via dev wrote: > Hi Andrew, > > Thanks for the KIP - decoupling export from reset is a real usability win. > A few comments, mostly on the generic-describe half. > > AS01: KIP-1043 deliberately unified group listing but kept describe > per-type; a cross-type describeGroups/GroupDescription moves in the other > direction, so it'd help to cover the relationship in Rejected Alternatives > - what changed since KIP-1043? As proposed, GroupDescription carries only > the common metadata (groupId/type/state/coordinator/authorizedOperations) > rather than unifying the richer per-type output, so it's really a > lightweight cross-type lookup - close to what GroupListing already exposes > (groupId()/type()/groupState()). Given that, could you walk through why a > brand-new RPC is needed rather than one of the cheaper routes? a) Reuse > listGroups() + existing per-type describe: it already returns the type, so > the CLI improvement might need no protocol change at all. b) Extend the > classic DescribeGroups RPC: it already returns group state and protocol > type and supports IncludeAuthorizedOperations; the only real gap for > cross-type discovery seems to be that its response carries no GroupType, > which a version bump could add - giving the same atomic by-id lookup > without a new apiKey. If a new RPC is still the right call, what rules > those two out (e.g. is it a routing/handler concern - the classic describe > path not knowing about consumer-protocol/share/streams groups)? Relatedly, > DescribeGroupsGeneric sits awkwardly next to the existing DescribeGroups > and matches neither the classic name nor the per-type <Type>GroupDescribe > convention (ConsumerGroupDescribe/ShareGroupDescribe/StreamsGroupDescribe). > > AS02: If we keep a public GroupDescription, could we make it an interface > with accessors rather than a class with a public constructor? A public > constructor freezes the signature, meaning adding a field later causes a > binary break. It'd also help to clarify its relationship to GroupListing, > which already exposes groupId()/type()/groupState(). > > AS03: Could the KIP explicitly state that the CSV produced by > --export-offsets is byte-compatible with what --reset-offsets --from-file > consumes? The value of the round-trip depends on existing scripts > continuing to work. > > AS04: --export-offsets omits --from-file from its reset-spec list, but the > asymmetry vs. --reset-offsets isn't explained - a one-line note would help. > > nit: The JIRA link is still the KAFKA-1 template placeholder. > > Thanks, > -Alieh > > On Fri, Jun 19, 2026 at 7:19 PM Andrew Schofield <[email protected]> > wrote: > > > Hi Jiunn-Yang, > > Thanks for your response. > > > > jy_01: Absolutely right. Fixed. > > > > jy_02: Yes, it should. Fixed. > > > > Thanks, > > Andrew > > > > On 2026/06/18 15:49:29 黃竣陽 wrote: > > > Hello Andrew, > > > > > > Thanks for this KIP, > > > > > > jy_01: The package name is incorrect. It should be > > org.apache.kafka.clients.admin > > > > > > jy_02: Should DescribeGroupsOptions include an > > includeAuthorizedOperations field? > > > All other Describe*GroupsOptions classes > > (Consumer/Share/Streams/Classic) expose this flag, > > > and GroupDescription already has an authorizedOperations() method. > > > > > > Best Regards, > > > Jiunn-Yang > > > > > > > Chia-Ping Tsai <[email protected]> 於 2026年6月18日 晚上11:04 寫道： > > > > > > > > hi Andrew > > > > > > > > thanks for this KIP. I've left a few comments > > > > > > > > chia_00: How do we handle the RPCs? Do they reuse existing ones or > > introduce something new? > > > > > > > > chia_01: Would you mind adding the discussion link to the KIP page? > > > > > > > > Best, > > > > Chia-Ping > > > > > > > > On 2026/06/17 06:34:11 Andrew Schofield wrote: > > > >> Hi, > > > >> I’d like to start discussion on a small KIP to improve the usability > > of the command-line tools for resetting group offsets. When implementing > > KIP-1323 and reviewing the PRs, it became clear that the usability of this > > area of Kafka isn’t great. This KIP improves the usability of these tools. > > > >> > > > >> > > https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/KAFKA/KIP-1359*3A*Improve*usability*of*resetting*group*offsets__;JSsrKysrKw!!Ayb5sqE7!vqzkXryZsqLU5Eri1k8vRp3gA7PbbwrrZ0LD0N8gE5AF8vr5TLUpw7Gsg3UZ-_Boxk7NdcOHfdTMmXx7xZp6hq4$ > > > >> > > > >> Thanks, > > > >> Andrew > > > >> > > > > > > > > >
