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 > > >> > > > > >
