Hi Andrew Everything makes sense to me.
-Alieh On Thu, Jul 16, 2026 at 9:30 PM Andrew Schofield <[email protected]> wrote: > 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 > > > > >> > > > > > > > > > > > > > >
