Thanks for the updates PoAn! LM6. Just a nit, under the --describe --state --verbose the header is fine but the example is still missing the --state argument.
LM7. Under the Proposed changes for kafka-share-groups.sh, should we clearly mention that the KIP adds a new --verbose option? I think it's confusing because it's presented as if the option already exists and we're only changing the output (which is the case for kafka-consumer-groups but not for kafka-share-groups) That's all on my side. Thanks! Lianet On Wed, Nov 20, 2024 at 11:12 PM PoAn Yang <yangp...@gmail.com> wrote: > Hi Lianet / Jeff, > > Thanks for review and suggestions. > > LM4: At group level, the protocol field is from ModernGroup#protocolType. > It’s a string. > The value is defined in different places like ShareGroup#PROTOCOL_TYPE and > ConsumerProtocol#PROTOCOL_TYPE. > In KIP-1043 < > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=305171038#KIP1043:Administrationofgroups-kafka-groups.sh>, > the kafka-groups.sh also shows protocol like “classic” / “consumer” / > “share”. > I agree it’s better to use a type like GroupProtocol enum, but I would > like to align the format with kafka-groups.sh. > How about we use another Jira to add “SHARE” to GroupProtocol and change > return type of ModernGroup#protocolType? > > LM5 / JK1: Sorry, I misunderstood LM3, so I deleted —state in the title. > You’re correct. I would like to use `—describe —state —verbose` to show > group level information. > For `—describe —verbose`, it will show output as same as `—describe > —offsets —verbose`, > because `—describe` also shows output as same as `—describe —offsets`. > > JK2: Yes, I only use consumer group in the sample output, but the classic > group will use the same format as well. > > Thanks, > PoAn > > > On Nov 21, 2024, at 8:28 AM, Jeff Kim <jeffkb...@apache.org> wrote: > > > > Hi PoAn, > > > > Thanks for the KIP. I have some questions: > > > > JK1: (Realized this is similar to LM5) On `--describe --verbose` > proposed changes - doesn't `--describe $group` default to printing the > offsets? Perhaps you're referring to the `--state` argument? Also, would > that mean the default `--describe $group --verbose` command would not print > the added field to `--offsets verbose` (leader-epoch) or would it? > > > > JK2: Looking at ConsumerGroupCommand.java, the existing "ASSIGNMENT" > column under `--members --verbose` does group the topic partitions by topic > but does not prefix the grouping with the topic name like you're proposal: > "my_topic:0,1;new_topic:0,1". Should we do apply the same format for the > classic group as well? > > > > > > > > On 2024/11/20 21:32:41 "Lianet M." wrote: > >> Hello PoAn, just of couple more minor comments: > >> > >> LM4. Regarding the new “protocol” field added to MemberDescription. > Should > >> we consider reusing the existing GroupProtocol enum instead of String? > >> (It’s the one we use from the consumer side to refer to the protocol in > >> use, just missing Share I notice). > >> > >> LM5. Regarding the change to the output for kafka-consumer-groups, the > >> command shown does not include the —state option, but the output shows > >> state info (state, #members, epochs). I would guess that we want to > modify > >> the output only when we describe a group with the —state —verbose > option, > >> is my understanding right? If my understanding is right we’re just > missing > >> adding the —state in the example, and the KIP does not introduce any > >> changes to the —describe —verbose option. (If not, it would mean a > bigger > >> change to the output of —describe —verbose which I expect is not the > >> intention?) > >> > >> Thanks! > >> > >> Lianet > >> > >> > >> On Wed, Nov 20, 2024 at 2:12 AM PoAn Yang <yangp...@gmail.com> wrote: > >> > >>> Hi Chia-Ping, > >>> > >>> Thanks for the review and suggestions. > >>> > >>> CI0: Thanks for the reminder. Update validVersions in > >>> ConsumerGroupDescribeRequest to 0-1. > >>> > >>> CI1: Yes, I use `ConsumerGroupMember#useClassicProtocol` to check > whether > >>> a member in consumer group uses “classic” or “consumer” protocol. > >>> > >>> CI2: Yes, a member in share group always uses “share” protocol. > >>> > >>> CI3: Add a table to show meaning of “classic”, “consumer”, and “share” > >>> protocol. > >>> > >>> BTW, the vote thread is in > >>> https://lists.apache.org/thread/rb25tf75tzf4c7jqqldlo5jh9w8chsq6. > >>> > >>> Thanks, > >>> PoAn > >>> > >>>> On Nov 20, 2024, at 11:46 AM, Chia-Ping Tsai <chia7...@apache.org> > >>> wrote: > >>>> > >>>> hi PoAn > >>>> > >>>> CI0: We have to bump the version of ConsumerGroupDescribeRequest as > >>> well, so server can distinguish the new and old behavior. > >>>> > >>>> CI1: the type of new filed is string, so I guess you plan to use > >>> `ConsumerGroupMember#useClassicProtocol` [0] flag to return either > >>> "classic" or "consumer", right? > >>>> > >>>> CI2: `MemberDescription` is used by `ShareGroupDescription` too, so > the > >>> new filed protocol in shared group is always "shared", right? > >>>> > >>>> CI3: Could you consider adding a table to show the value of the > protocol > >>> field in each case? Andrew has a beautiful table in KIP-1043 that > lists all > >>> possible protocol names. > >>>> > >>>> [0] > >>> > https://github.com/apache/kafka/blob/441a6d0b790f4a17b454caeea7588a6b90fbd9db/group-coordinator/src/main/java/org/apache/kafka/coordinator/group/modern/consumer/ConsumerGroupMember.java#L454 > >>> > >>>> > >>>> Best, > >>>> Chia-Ping > >>>> > >>>> On 2024/11/19 15:45:16 PoAn Yang wrote: > >>>>> Hi David, > >>>>> > >>>>> Thanks for the reminder. > >>>>> > >>>>> DJ4: Add related content to the KIP. > >>>>> Bump validVersions in ConsumerGroupDescribeResponse to “0-1”. > >>>>> Add a new field “Protocol” to ConsumerGroupDescribeResponse. > >>>>> > >>>>> Thanks, > >>>>> PoAn > >>>>> > >>>>>> On Nov 19, 2024, at 3:57 PM, David Jacot > <dja...@confluent.io.INVALID> > >>> wrote: > >>>>>> > >>>>>> Hi PoAn, > >>>>>> > >>>>>> DJ4: Could you please also include the required changes to the > >>>>>> ConsumerGroupDescribed API in the public interface section? We > >>> basically > >>>>>> need to bump the version, add the new field, etc. > >>>>>> > >>>>>> Thanks, > >>>>>> David > >>>>>> > >>>>>> On Mon, Nov 18, 2024 at 5:40 AM PoAn Yang <yangp...@gmail.com> > wrote: > >>>>>> > >>>>>>> Hi David, > >>>>>>> > >>>>>>> DJ4: Add a new field protocol to MemberDescription, > >>>>>>> so the command line tool can show protocol information when users > >>> describe > >>>>>>> members. > >>>>>>> > >>>>>>> If there is no further suggestion, I will start a vote thread > today. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> PoAn > >>>>>>> > >>>>>>>> On Nov 15, 2024, at 11:50 PM, David Jacot > >>> <dja...@confluent.io.INVALID> > >>>>>>> wrote: > >>>>>>>> > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> DJ2: Using "-" sounds good to me. > >>>>>>>> > >>>>>>>> DJ3: That seems reasonable to me. > >>>>>>>> > >>>>>>>> DJ4: Why not add it right now? I don't want to change the output > of > >>> the > >>>>>>>> tool too many times. > >>>>>>>> > >>>>>>>> Best, > >>>>>>>> David > >>>>>>>> > >>>>>>>> On Fri, Nov 15, 2024 at 3:23 PM PoAn Yang <yangp...@gmail.com> > >>> wrote: > >>>>>>>> > >>>>>>>>> Hi David / Andrew, > >>>>>>>>> > >>>>>>>>> Thanks for review. Thanks Andrew for picking up > >>> kafka-share-groups.sh > >>>>>>>>> implementation. > >>>>>>>>> I will handle kafka-consumer-groups.sh. > >>>>>>>>> > >>>>>>>>> DJ3: After discussing with @Chia-Ping Tsai, we think that using > new > >>>>>>> format > >>>>>>>>> is more clear. > >>>>>>>>> > >>>>>>>>> The new format will be like > >>>>>>>>> > >>>>>>> > >>> > <topic-name1>:<partition-id1>,<partition-id2>;<topic-name2>:<partition-id1>,<partition-id2> > >>>>>>>>> > >>>>>>>>> Using colon(:) to concat topic name and partition IDs. > >>>>>>>>> Using comma(,) to concat partition IDs within same topic name. > >>>>>>>>> Using semicolon(;) to concat topic strings. > >>>>>>>>> > >>>>>>>>> AS3: Fix it with kafka-share-groups.sh. Thanks. > >>>>>>>>> > >>>>>>>>> If there is no further suggestion, I will start a vote thread > next > >>>>>>> Monday. > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> PoAn > >>>>>>>>> > >>>>>>>>>> On Nov 14, 2024, at 9:05 PM, Andrew Schofield < > >>>>>>>>> andrew_schofield_j...@outlook.com> wrote: > >>>>>>>>>> > >>>>>>>>>> Hi PoAn, > >>>>>>>>>> DJ2: I was just going to comment that "-" would be a more > >>> appropriate > >>>>>>>>> missing value, but > >>>>>>>>>> you got there first. > >>>>>>>>>> > >>>>>>>>>> AS3: The examples for kafka-share-groups.sh include > >>>>>>>>> kafka-consumer-groups.sh in the > >>>>>>>>>> command line. > >>>>>>>>>> > >>>>>>>>>> If this is accepted in time, I'm happy to pick up the > >>> implementation of > >>>>>>>>> the share groups > >>>>>>>>>> part of this if it helps. > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> Andrew > >>>>>>>>>> > >>>>>>>>>> ________________________________________ > >>>>>>>>>> From: Frank Yang <yangp...@gmail.com> > >>>>>>>>>> Sent: 14 November 2024 10:48 > >>>>>>>>>> To: dev@kafka.apache.org <dev@kafka.apache.org> > >>>>>>>>>> Subject: Re: [DISCUSS] KIP-1099: Extend kafka-consumer-groups > >>> command > >>>>>>>>> line tool to support new consumer group > >>>>>>>>>> > >>>>>>>>>> Hi David, > >>>>>>>>>> > >>>>>>>>>> Thanks for the review and suggestion! I would like to get this > in > >>> AK > >>>>>>> 4.0 > >>>>>>>>> as well. I will do my best. > >>>>>>>>>> > >>>>>>>>>> DJ1: Update KIP to put GROUP-EPOCH and TARGET-ASSIGNMENT-EPOCH > >>> before > >>>>>>>>> #MEMBERS. > >>>>>>>>>> > >>>>>>>>>> DJ2: I prefer to follow current missing column value “-“. > >>> (reference < > >>>>>>>>> > >>>>>>> > >>> > https://github.com/apache/kafka/blob/18199028a672fd973ac37bf26316994babc2a6da/tools/src/main/java/org/apache/kafka/tools/consumer/group/ConsumerGroupCommand.java#L92 > >>>>>>>>>> ) > >>>>>>>>>> > >>>>>>>>>> DJ3: Update KIP to use CURRENT-EPOCH CURRENT-ASSIGNMENT > >>> TARGET-EPOCH > >>>>>>>>> TARGET-ASSIGNMENT. > >>>>>>>>>> Remove GROUP-EPOCH. > >>>>>>>>>> > >>>>>>>>>> For assignment value, it follows current output (reference < > >>>>>>>>> > >>>>>>> > >>> > https://github.com/apache/kafka/blob/18199028a672fd973ac37bf26316994babc2a6da/tools/src/main/java/org/apache/kafka/tools/consumer/group/ConsumerGroupCommand.java#L413-L418 > >>>>>>>> ). > >>>>>>>>> I think the form of `topicid-partitionid` is more clear. > >>>>>>>>>> If we would like to use this form, I will update both output in > >>>>>>>>> kafka-consumer-groups.sh and kafka-share-groups.sh. > >>>>>>>>>> > >>>>>>>>>> DJ4: It looks like DescribeGroupsResponseData only has protocol > >>> type at > >>>>>>>>> group level. > >>>>>>>>>> Both DescribeGroupsResponseData and > >>> ConsumerGroupDescribeResponseData > >>>>>>>>> don’t have protocol at member level. > >>>>>>>>>> Could we use a followup to add it? > >>>>>>>>>> > >>>>>>>>>> DJ5: Update KIP to put LEADER-EPOCH before CURRENT-OFFSET. > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> PoAn > >>>>>>>>>> > >>>>>>>>>>> On Nov 14, 2024, at 3:43 PM, David Jacot > >>> <dja...@confluent.io.INVALID > >>>>>>>> > >>>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>> Hi PoAn, > >>>>>>>>>>> > >>>>>>>>>>> Thanks for the KIP! I have a few minor comments/suggestions: > >>>>>>>>>>> > >>>>>>>>>>> DJ1: In the output of `--describe --verbose`, I would suggest > >>> putting > >>>>>>>>>>> `GROUP-EPOCH` and `TARGET-ASSIGNMENT-EPOCH` before `#MEMBERS`. > >>>>>>>>>>> DJ2: Continuing on the above, I assume that we will print out > N/A > >>> for > >>>>>>>>> the > >>>>>>>>>>> fields not supported by classic groups. Is this correct? > >>>>>>>>>>> DJ3: In the output of `--describe --members --verbose`, I > wonder > >>> if we > >>>>>>>>>>> should use the following order and terms: CURRENT-EPOCH > >>>>>>>>> CURRENT-ASSIGNMENT > >>>>>>>>>>> TARGET-EPOCH TARGET-ASSIGNMENT . I would remove the GROUP-EPOCH > >>>>>>> because > >>>>>>>>> it > >>>>>>>>>>> is already in the group description. The value `(0)` used for > the > >>>>>>>>>>> assignment is incorrect. Here I suppose that we will print out > the > >>>>>>> list > >>>>>>>>> of > >>>>>>>>>>> partitions in the form of `topicid-partitionid`. > >>>>>>>>>>> DJ4: Continuing on the above, I wonder if we should also add > the > >>>>>>>>> protocol > >>>>>>>>>>> used `classic` or `consumer`. For context, it is possible to > have > >>>>>>>>> `classic` > >>>>>>>>>>> members and `consumer` members in a `consumer` group during an > >>> online > >>>>>>>>>>> upgrade from the classic protocol to the consumer protocol. > Having > >>>>>>> this > >>>>>>>>>>> information may be handy for administrators. What do you think? > >>>>>>>>>>> DJ5: In the output of `--describe --offsets --verbose`, I would > >>>>>>> suggest > >>>>>>>>>>> putting `LEADER-EPOCH` closer to `CURRENT-OFFSET`. > >>>>>>>>>>> > >>>>>>>>>>> It would be great if we could get this one in AK 4.0 as it > >>> changes the > >>>>>>>>>>> output of the command. > >>>>>>>>>>> > >>>>>>>>>>> Thanks, > >>>>>>>>>>> DJ > >>>>>>>>>>> > >>>>>>>>>>> On Fri, Nov 1, 2024 at 7:40 AM Frank Yang <yangp...@gmail.com> > >>> wrote: > >>>>>>>>>>> > >>>>>>>>>>>> Hi Sean / Andrew / Lianet, > >>>>>>>>>>>> > >>>>>>>>>>>> Thanks for all your review and suggestions. > >>>>>>>>>>>> > >>>>>>>>>>>> AS1, LM1, LM4: Change to add KIP-848 information when users > give > >>>>>>>>> —verbose > >>>>>>>>>>>> option. > >>>>>>>>>>>> —describe —verbose: shows group epoch and target assignment > >>> epoch. > >>>>>>>>>>>> —describe —members —verbose: shows above information, member > >>> epoch, > >>>>>>> and > >>>>>>>>>>>> target assignment. > >>>>>>>>>>>> > >>>>>>>>>>>> AS2: Change to use MEMBER-EPOCH to align with KIP-848 > definition. > >>>>>>>>>>>> > >>>>>>>>>>>> LM2: For classic group, it doesn’t have epoch, so I use > Optional > >>>>>>>>> fields in > >>>>>>>>>>>> ConsumerGroupDescription. > >>>>>>>>>>>> For share group, it relies on KIP-848. It must have epoch, so > I > >>> use > >>>>>>> int > >>>>>>>>>>>> fields in ShareGroupDescription. > >>>>>>>>>>>> > >>>>>>>>>>>> LM3: Remove —state change. We can get group level information > by > >>>>>>>>> —describe > >>>>>>>>>>>> —verbose. > >>>>>>>>>>>> > >>>>>>>>>>>> SQ1: Add LEADER-EPOCH when users give —describe —offsets > >>> —verbose. > >>>>>>>>>>>> > >>>>>>>>>>>> Thanks. > >>>>>>>>>>>> PoAn > >>>>>>>>>>>> > >>>>>>>>>>>>> On Nov 1, 2024, at 5:08 AM, Lianet M. <liane...@gmail.com> > >>> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> Hello Frank, thanks for the KIP! A few comments: > >>>>>>>>>>>>> > >>>>>>>>>>>>> LM1. I strongly agree with Andrew's suggestion of moving this > >>> into a > >>>>>>>>>>>>> --verbose option. I expect someone would only attempt to make > >>> sense > >>>>>>> of > >>>>>>>>>>>> the > >>>>>>>>>>>>> epochs while debugging an issue, not while trying to view the > >>> group > >>>>>>> or > >>>>>>>>>>>>> member's info. (Also member-epoch makes more sense to me, > even > >>> more > >>>>>>>>> if we > >>>>>>>>>>>>> end up agreeing in a --verbose). Related to both issues, my > >>> take is > >>>>>>>>> that > >>>>>>>>>>>>> whoever is close to the protocol will expect member-epoch, > >>> whoever > >>>>>>> is > >>>>>>>>> not > >>>>>>>>>>>>> will probably won't even need to see the epochs at all. > >>>>>>>>>>>>> > >>>>>>>>>>>>> LM2. Why are the epochs defined as Optional (don't we expect > to > >>>>>>> always > >>>>>>>>>>>> have > >>>>>>>>>>>>> them? with 0 initially, defined on the broker side for the > group > >>>>>>> ones, > >>>>>>>>>>>> and > >>>>>>>>>>>>> client side for the member) > >>>>>>>>>>>>> > >>>>>>>>>>>>> LM3. Why is the KIP including the –state option in the > proposed > >>>>>>>>> changes? > >>>>>>>>>>>> ( > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>> > >>>>>>> > >>> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=327977411#KIP1099:Extendkafkaconsumergroupscommandlinetooltosupportnewconsumergroup---state > >>>>>>>>>>>>> ). > >>>>>>>>>>>>> I get that the output would change in that example, but it’s > not > >>>>>>>>> because > >>>>>>>>>>>> of > >>>>>>>>>>>>> any change to the –state option itself. It's because of the > >>> change > >>>>>>>>>>>> proposed > >>>>>>>>>>>>> to the –described (required with the --state), and the > changes > >>> to > >>>>>>>>>>>>> --describe are already explained above (seems confusing, got > me > >>>>>>>>> looking > >>>>>>>>>>>> for > >>>>>>>>>>>>> a change to the state filter which seemed unrelated). > >>>>>>>>>>>>> > >>>>>>>>>>>>> LM4. Group epoch and target assignment epoch are conceptually > >>> at the > >>>>>>>>>>>> group > >>>>>>>>>>>>> level. vs member epoch that lands at a member level. So > wonder > >>> if we > >>>>>>>>>>>> should > >>>>>>>>>>>>> show them accordingly (ex. using the --verbose option) > >>>>>>>>>>>>> –describe –verbose => shows group epoch and target assignment > >>> epoch > >>>>>>>>>>>>> –describe –members –verbose => shows member epoch > >>> (along > >>>>>>>>>>>>> with group epoch and target assignment epoch) > >>>>>>>>>>>>> > >>>>>>>>>>>>> Thanks! > >>>>>>>>>>>>> > >>>>>>>>>>>>> Lianet > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Thu, Oct 31, 2024 at 7:30 AM Andrew Schofield < > >>>>>>>>>>>>> andrew_schofield_j...@outlook.com> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Hi PoAn, > >>>>>>>>>>>>>> Thanks for the KIP. I have a few comments. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> AS1: It seems to me that these new additions are most > useful to > >>>>>>>>> people > >>>>>>>>>>>>>> trying to understand > >>>>>>>>>>>>>> the progress of rebalancing in quite some detail. The > >>> information > >>>>>>> is > >>>>>>>>>>>>>> really not understandable > >>>>>>>>>>>>>> for most users who do not have deep knowledge of > KIP-848/932. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> As a result, I suggest for kafka-share-groups.sh that you > add a > >>>>>>>>>>>> --members > >>>>>>>>>>>>>> --verbose option > >>>>>>>>>>>>>> and only include the new information in the output for that > >>> option, > >>>>>>>>>>>> rather > >>>>>>>>>>>>>> than changing the > >>>>>>>>>>>>>> non-verbose --members output. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I also make a similar suggestion for > kafka-consumer-groups.sh > >>>>>>>>> --members > >>>>>>>>>>>>>> and only add the > >>>>>>>>>>>>>> new information for the --verbose output. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> AS2: I strongly suggest that you use MEMBER-EPOCH instead of > >>>>>>>>>>>>>> CONSUMER-EPOCH. > >>>>>>>>>>>>>> I think it's more confusing not following the terminology of > >>> the > >>>>>>>>> KIPs. > >>>>>>>>>>>> For > >>>>>>>>>>>>>> one thing, > >>>>>>>>>>>>>> we already have "member" in the admin client such as > >>>>>>>>> MemberDescription. > >>>>>>>>>>>>>> It's not a > >>>>>>>>>>>>>> new term. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>> Andrew > >>>>>>>>>>>>>> ________________________________________ > >>>>>>>>>>>>>> From: PoAn Yang <pay...@apache.org> > >>>>>>>>>>>>>> Sent: 25 October 2024 13:55 > >>>>>>>>>>>>>> To: dev@kafka.apache.org <dev@kafka.apache.org> > >>>>>>>>>>>>>> Subject: Re: [DISCUSS] KIP-1099: Extend > kafka-consumer-groups > >>>>>>> command > >>>>>>>>>>>> line > >>>>>>>>>>>>>> tool to support new consumer group > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Hi Lucas, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Thanks for the review! > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 1) Yes, I add related change for kafka-share-groups.sh to > the > >>> KIP. > >>>>>>>>> Could > >>>>>>>>>>>>>> you take a look? Thanks for the suggestion. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 2) We use CONSUMER-ID as member ID. If we use MEMBER-EPOCH > >>> here, > >>>>>>>>> users > >>>>>>>>>>>> may > >>>>>>>>>>>>>> confuse what is different between CONSUMER and MEMBER. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>> PoAn > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On 2024/10/23 13:28:17 Lucas Brutschy wrote: > >>>>>>>>>>>>>>> Hi Frank, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> thanks for the KIP! > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> 1) For consistency, should we do the same for > >>>>>>>>>>>>>>> kafka-share-groups.sh, ShareGroupDescription, etc. ? Even > if > >>> we do > >>>>>>>>> not > >>>>>>>>>>>>>>> implement it right now if the share group implementation > may > >>> still > >>>>>>>>> be > >>>>>>>>>>>>>>> incomplete, it may make sense to include it in the KIP. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> 2) Why call it CONSUMER-EPOCH, not MEMBER-EPOCH? That would > >>> seem > >>>>>>>>> more > >>>>>>>>>>>>>>> consistent. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Cheers, > >>>>>>>>>>>>>>> Lucas > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On Wed, Oct 23, 2024 at 2:41 PM Frank Yang < > >>> yangp...@gmail.com> > >>>>>>>>> wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Hi all, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> I would like to kick off the discussion of KIP-1099. This > KIP > >>>>>>>>> enhances > >>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>> kafka-consumer-groups tools to include state which is > >>> introduced > >>>>>>> by > >>>>>>>>>>>>>> KIP-848. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> KIP-1099: Extend kafka-consumer-groups command line tool > to > >>>>>>> support > >>>>>>>>>>>> new > >>>>>>>>>>>>>>>> consumer group - Apache Kafka - Apache Software Foundation > >>>>>>>>>>>>>>>> < > >>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>> > >>>>>>> > >>> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1099%3A+Extend+kafka-consumer-groups+command+line+tool+to+support+new+consumer+group > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> cwiki.apache.org > >>>>>>>>>>>>>>>> < > >>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>> > >>>>>>> > >>> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1099%3A+Extend+kafka-consumer-groups+command+line+tool+to+support+new+consumer+group > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> [image: favicon.ico] > >>>>>>>>>>>>>>>> < > >>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>> > >>>>>>> > >>> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1099%3A+Extend+kafka-consumer-groups+command+line+tool+to+support+new+consumer+group > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> < > >>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>> > >>>>>>> > >>> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1099%3A+Extend+kafka-consumer-groups+command+line+tool+to+support+new+consumer+group > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Thank you, > >>>>>>>>>>>>>>>> PoAn > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>>>> > >>>>> > >>>>> > >>> > >>> > >> > >
