Hi David, Thanks for your response. I really don't like an API response whose error message is a significant part of the interface. If we have code that checks for specific error messages and takes different actions, we've got it wrong. If we are just displaying the error text or adding it to an exception, that's fine.
I think the tricky part here is that a "consumer group" could actually be a modern consumer group or a classic consumer group. How about this? The DescribeGroups API is used to describe classic groups only. A new version of the response (v6) adds an error message. It would be very weird to populate the error message for an error code of NONE, so v6 makes two changes: a) If the group ID exists but it's not a classic group, the error code INCONSISTENT_GROUP_TYPE is returned along with an error message such as "Group %s is not a classic group". b) If the group ID does not exist, the error code GROUP_ID_NOT_FOUND is returned along with an error message such as "Group %s not found". Formerly, this used to return error code NONE and bogus dead group. Admin#describeConsumerGroups first uses the ConsumerGroupDescribe API: a) If the group ID is a modern consumer group, the error code NONE is returned along with the group description. b) If the group ID exists but it's not a modern consumer group, the error code INCONSISTENT_GROUP_TYPE is returned along with an error message such as "Group %s is not a consumer group". c) If the group ID does not exist, the error code GROUP_ID_NOT_FOUND is returned along with an error message such as "Group %s not found". In case (b), the admin client then uses the DescribeGroups API to see whether the inconsistent group is a classic group or not. The bogus dead group is no longer used in the admin client interface. If the group doesn't exist, it's an exception. Admin#describeShareGroups uses the ShareGroupDescribe API: a) If the group ID is a share group, the error code NONE is returned along with the group description. b) If the group ID exists but it's not a share group, the error code INCONSISTENT_GROUP_TYPE is returned along with an error message such as "Group %s is not a share group". c) If the group ID does not exist, the error code GROUP_ID_NOT_FOUND is returned along with an error message such as "Group %s not found". Admin#describeClassicGroups uses the DescribeGroups v6 API: a) If the group ID is a classic group, the error code NONE is returned along with the group description. b) If the group ID exists but it's not a classic group, the error code INCONSISTENT_GROUP_TYPE is returned along with an error message such as "Group %s is not a classic group". c) If the group ID does not exist, the error code GROUP_ID_NOT_FOUND is returned along with an error message such as "Group %s not found". There is no bogus dead group. Having run through these scenarios, they would work almost the same if GROUP_ID_NOT_FOUND was used in the place of INCONSISTENT_GROUP_TYPE. Personally, I prefer the separate error code and consequently exception because you don't have to look inside the error message to figure out what went wrong. But actually, making it all use GROUP_ID_NOT_FOUND would give the same experience to the operator using the command line tools. If you're still convinced that GROUP_ID_NOT_FOUND is preferable, I'll change the KIP to remove the new error code. DL12: I will deprecate Admin#listConsumerGroups in this KIP, and remove Admin#listShareGroups from KIP-932, along with related tidying up that results from this. Thanks, Andrew ________________________________________ From: David Jacot <dja...@confluent.io.INVALID> Sent: 22 October 2024 11:08 To: dev@kafka.apache.org <dev@kafka.apache.org> Subject: Re: [DISCUSS] KIP-1043: Administration of groups Hi Andrew, Please excuse me for my delayed response. Thanks for the update. Overall, I am fine with the KIP, except for the INCONSISTENT_GROUP_TYPE error. We have three methods to describe groups: 1) Admin#describeClassicGroup (added by the KIP) 2) Admin#describeConsumerGroup 3) Admin#describeShareGroup With your proposal: 1) returns a group in a dead state if the group does not exist and if the group has the wrong type. This is the current behavior. 2.1) if the group is a classic group, ConsumerGroupDescribe returns INCONSISTENT_GROUP_TYPE, so we call DescribeGroup which returns the group or an empty group if it does exist. 2.2) if the group is a share group, ConsumerGroupDescribe returns INCONSISTENT_GROUP_TYPE, so we call DescribeGroup which returns an empty group in the dead state. We must call DescribeGroup because we don't know the correct type so we must check. 3) returns INCONSISTENT_GROUP_TYPE if the group has the wrong type. Hence new INCONSISTENT_GROUP_TYPE error is propagated to the user only with Admin#describeShareGroup. Admin#describeConsumerGroup never returns it based on my current understanding. It does not seem that useful in the current state and more importantly it is inconsistent. At minimum, we should ensure that the new error code is used everywhere, even by the DescribeGroups API, in order to be consistent. Note that it is still a bit weird to return INCONSISTENT_GROUP_TYPE because it would be the only error returned. I am not really happy with how we designed this API in the first place. Alternatively, we could also extend the DescribeGroup API to return GROUP_ID_NOT_FOUND with an error message. It would achieve the same end result while keeping an existing error code used by all the other APIs for this purpose. Personally, I prefer the latter. Regarding DJ12, I think that we should deprecate them in this KIP because they are deprecated because of it. It does not make sense to do another KIP just to deprecate them in my opinion. Best, David On Wed, Oct 2, 2024 at 6:21 PM Andrew Schofield < andrew_schofield_j...@outlook.com> wrote: > Hi David, > Thanks for your replies. > > DJ2: OK. > > DJ3: I've added AdminClient.describeClassicGroups to the KIP. I added > ClassicGroupDescription and ClassicGroupState too. I did consider using > GroupState directly, but all of the other XXXGroupDescription have > their own specific XXXGroupState so I went for consistency. > > DJ6: I'll try again to justify the new INCONSISTENT_GROUP_TYPE error code. > Consider the RPCs and errors codes when trying to describe a consumer > group and actually the group ID is taken by a share group. > > ConsumerGroupDescribe returns error code GROUP_ID_NOT_FOUND (69). > This means the group ID is not a modern consumer group, but we don't know > whether it's a classic consumer group. > > DescribeGroups never uses GROUP_ID_NOT_FOUND. Instead, it just fakes up > a (classic) consumer group with a state of Dead and returns OK. Because > this > is an ancient RPC response, it does not currently include an ErrorMessage. > > Admin.describeConsumerGroups uses these two RPCs and it cannot currently > work out when a group ID exists and has the wrong group type. > > I think the cleanest way to handle this is to have XXXGroupDescribe return > a new error code, INCONSISTENT_GROUP_TYPE. I personally think that > just adding it to the XXXGroupDescribe responses is sufficient. It's never > in any doubt what the situation is with any other RPCs. > > I'm happy to consider alternatives if you have any in mind, but I've > wrestled with this for a while and I think this suggestion is sound. > > DJ7: I've removed --describe from kafka-topics.sh and made --list output a > table. > > DJ10: Although it slightly offends me, I have added isSimpleConsumerGroup > to GroupListing. This method is now present in GroupListing, > ConsumerGroupDescription and ClassicGroupDescription. I think > that will do the job. A simple consumer group is GroupType.CLASSIC > with an empty protocol, and you can use Admin.describeConsumerGroups > or Admin.describeClassicGroups to describe it. > > DJ12: I will propose a new KIP that deprecates > Admin.listXXXGroups and related classes, and also deprecates > kafka-xxx-groups.sh --list. > > Thanks, > Andrew > > ________________________________________ > From: David Jacot <dja...@confluent.io.INVALID> > Sent: 02 October 2024 08:54 > To: dev@kafka.apache.org <dev@kafka.apache.org> > Subject: Re: [DISCUSS] KIP-1043: Administration of groups > > Hi Andrew, > > Thanks for your replies. > > DJ1: Thanks for clarifying. Somehow, I was sure that the tool would at > minimum list those groups. > > DJ2: Oh, I see. Actually, removing it would break the admin client as > listConsumerGroups rely on it to filter groups. I think that we should just > keep it as it is. > > DJ3: AdminClient.describeClassicGroups sounds good to me. > > DJ4: Ack. > > DJ5: Ack. > > DJ6: I am not sure that I understand the issue that you're trying to solve > with the new error code. Could you please elaborate? Is the goal to avoid > the extra lookup if the group really does not exist? I agree that adding > the new code everywhere is a lot of work and this is why I did not > introduce it in the first place :). Personally, I don't like the > inconsistency between the APIs. It will be confusing. Hence I would do it > everywhere or nowhere but this is just my opinion. > > DJ7: In my opinion, we could just keep --list and always return a table. > For context, we did not change it to a table in kafka-consumer-groups when > we added the new filter for backward compatibility reasons. In this case, > it is a new tool so we could do it. > > DJ8: OK. > > DJ10: That's a good question. We have not really thought through how we > will handle those in the future. I don't like the Simple group type because > we don't have it on the server. The reason why I wanted to add > isSimpleConsumerGroup is because it would allow us to deprecate > listConsumerGroups. In the end, isSimpleConsumerGroup would only be true > for classic groups without a protocol type. > > DJ11: OK. > > DJ12: I also prefer option (a). I think that we should avoid having a list > method per type that we add. > > Best, > David > > On Mon, Sep 23, 2024 at 6:39 PM Andrew Schofield < > andrew_schofi...@live.com> > wrote: > > > Hi David, > > Thanks for your comments. > > > > DJ1: If I start the Confluent schema registry, it creates a classic group > > called "sr" using > > the protocol "sr" which is not included in the list from > > kafka-consumer-groups.sh. > > If I describe it using kafka-consumer-groups.sh, it says "Error: Consumer > > group 'sr' does not exist". > > > > If I start a distributed Kafka Connect worker, it creates a classic group > > called "connect-cluster" > > using the protocol "connect". Neither is this group included in the list > > from > > kafka-consumer-groups.sh. If I describe it using > kafka-consumer-groups.sh, > > it spews out > > an exception which contains "GroupId connect-cluster is not a consumer > > group(connect)". > > Quite why this appears to take a different error path is a mystery. > > > > So, I think that your understanding is not quite correct. It's worse. > This > > KIP is all about > > tidying this up and not making it worse as we add share groups and > streams > > groups. > > > > DJ2: I tend to agree about setting the protocol only for classic groups, > > but the ListGroups RPC > > already exists (this KIP does not change it) and we already do set the > > protocol type. For example, > > a modern consumer group uses "consumer" and a share group uses "share". I > > could omit the > > protocol type in the output from kafka-groups.sh without changing the > RPC. > > To remove it from > > the RPC would likely necessitate a version bump on ListGroups. Which do > > you prefer here? > > Do you agree about my assertion about the version bump? It's probably > > removing a piece of > > information which everyone ignores. > > > > DJ3: Yes, I think that AdminClient.describeClassicGroups would be > > appropriate, but > > AdminClient.describeGroups would need to be able to return information > > about all different > > kinds of groups, and I suggest that's not necessary. If you agree, I can > > add it. > > > > DJ4: See DJ12 option (a) below. Essentially, if we take this option, > maybe > > we don't introduce > > AbstractListGroupsResult at all because there would be no subclasses in > > the future, and its > > privacy becomes moot. > > > > DJ5: We could just have a single constructor. I have changed the KIP. > > > > DJ6: I think we need to be careful here not to bloat the amount of work > > unnecessarily. > > There's quite a cost to adding a new RPC version, conditionally returning > > a new error code, > > and adding tests to ensure that the old and new behaviour is correct. If > > we do this for about > > 10 RPCs, that's quite a lot of work with little benefit. Would anyone > > actually use LeaveGroup > > against a modern consumer group? With the KIP as written, the new error > > code is used for > > RPCs which describe groups only. > > > > I could understand adding it to Consumer|ShareGroupHeartbeat too, but I > > don't think it's > > necessary. This is because these RPC responses are modern and have > > ErrorMessage which > > can easily be used to populate the exception reason in the application. I > > think that > > GroupIdNotFoundException if a consumer application attempts to join a > > group of the wrong > > kind is OK if the exception also contains the string "Group XYZ is not a > > consumer group". > > An InconsistentGroupTypeException is probably a little better, but only > > marginally I think. > > > > ConsumerGroupDescribe is different. Because of the co-existence of > classic > > and modern > > consumer groups, and the way that the admin client drops through when it > > receives a > > GROUP_ID_NOT_FOUND error code from ConsumerGroupDescribe and then tries > > DescribeGroups to check for a classic group instead, I think we need a > new > > error code > > on the ConsumerGroupDescribe. > > > > Ultimately, if you're convinced that the new error code should be present > > for all RPCs served > > by the GC which are dependent on group type, I can change the KIP. I was > > careful to write > > the KIP in this way, but it's ultimately just my opinion. > > > > DJ7: In general, the tools use --list to return just a bare list of > > resource names as strings and > > then --describe to return a table of the resources. So, I've gone for > > consistency with > > kafka-topics.sh, kafka-consumer-groups.sh and others. I do note that > > specifically > > "kafka-consumer-groups.sh --list --state" returns a table. I think that > > one slipped through the > > cracks. > > > > DJ8: Hmm. I think I see what you mean by deprecating > > kafka-consumer-groups.sh --list. > > Essentially, it would encourage users to use kafka-groups.sh to list > > groups, and then only > > use kafka-consumer-groups.sh for operating on consumer groups. I wonder > if > > that would > > make a sensible and trivial follow-on KIP because we would make it simple > > to gauge > > opinions on deprecating an option which people are used to. > > > > DJ9: Yes, you are correct. I have updated the KIP accordingly. > > > > DJ10: Do you have an opinion about the future of simple consumer groups? > I > > imagine that > > classic consumer groups will disappear in AK 5.0, but it will still be > > possible to have a > > consumer which just commits offsets and does not engage in the consumer > > group protocol. > > I'm not convinced that isSimpleConsumerGroup should be in GroupListing. > > Maybe a group > > type of Simple would be better. What do you think? > > > > DJ11: It probably is slightly more convenient but I am a big fan of > > consistency. > > AdminClient.listConsumerGroups uses ListConsumerGroupsOptions for > > filtering the types > > and states of groups returned. AdminClient.listTopics uses > > ListTopicsOptions for the same > > purpose. This is why I prefer AdminClient.listGroups to use > > ListGroupsOptions for filtering. > > > > DJ12: I think there are two options here: > > > > Option (a): AdminClient.listGroups becomes the one true method for > listing > > groups. It returns > > instances of GroupListing, and GroupListing is sufficiently general to > > handle all types of groups. > > We introduce a new enum GroupState which is essentially the union of > > ConsumerGroupState > > and ShareGroupState. We deprecate AdminClient.listConsumerGroups and > > AdminClient.listShareGroups, and deprecate ConsumerGroupListing and > > ShareGroupListing. > > There would be no need to worry about the code duplication in > > ListConsumerGroupsResult, > > ListShareGroupsResult and ListGroupsResult because only the last of these > > would not be > > deprecated. As a result, introducing AbstractListGroupsResult now would > > not be worth the effort. > > We cannot deprecate ConsumerGroupState and ShareGroupState because they > > are used by > > AdminClient.describeConsumerGroups/describeShareGroups. We remove the > > deprecated > > interfaces in AK 5.0. > > > > Option (b): We keep AdminClient.listConsumerGroup/listShareGroups, in > > addition to > > AdminClient.listGroups. We do not deprecate ConsumerGroupListing and > > ShareGroupListing. > > > > Personally, I prefer option (a) but I wasn't convinced it would be a > > viable option. I wonder what you think. > > > > > > Thanks, > > Andrew > > > > > > ________________________________________ > > From: David Jacot <dja...@confluent.io.INVALID> > > Sent: 23 September 2024 13:57 > > To: dev@kafka.apache.org <dev@kafka.apache.org> > > Subject: Re: [DISCUSS] KIP-1043: Administration of groups > > > > Hi Andrew, > > > > Thanks for the KIP. I have some comments/questions: > > > > DJ1: In the motivation, you wrote the following: "You can’t see this > group > > in the list of consumer groups with the kafka-consumer-groups.sh tool, > but > > if you try to describe a consumer group called "connect-cluster" or even > > use this group ID with a consumer, you get an error.". My understanding > is > > that you can list those groups but you cannot describe them. Is my > > understanding correct? > > > > DJ2: Regarding the information returned by the ListGroups RPC, I wonder > if > > we should set the protocol only for classic groups. The protocol is > > actually a reference to the protocol type used in the classic protocol. I > > suppose that it is also fine to return the group type for the non-classic > > groups. > > > > DJ3: I wonder if we should also introduce Admin#describeGroups or > > Admin#describeClassicGroup. At the moment, it is impossible to describe > > classic groups which do not use the consumer protocol. What do you think? > > > > DJ4: Would it be possible to keep AbstractListGroupsResult private > somehow? > > I don't like to publish it as part of our public APIs because we have to > > maintain it over time. > > > > DJ5: Could we limit the number of constructors in GroupListing? I suppose > > that having only one should be fine. > > > > DJ6: I think that we should extend all the APIs to > > use INCONSISTENT_GROUP_TYPE if we introduce a new error code. For > instance, > > it would make sense for the DescribeGroup to follow the same pattern. > > Moreover, if we have it, it would also make sense for > > ConsumerGroupHearbeat, ShareGroupHeartbeat and > > JoinGroup/SyncGroup/Heartbeat to also use it in order to have a > consistent > > error across the board. What do you think? > > > > DJ7: I would remove the "--describe" from the new tool. We could just > make > > "--list" return the same information by default. "--describe" is used by > > other command line tools to describe resources so it may be confusing for > > users. > > > > DJ8: Should we deprecate "--list" in the kafka-consumer-group command > line > > tool? > > > > DJ9: ListOffsets RPC is not related to groups. I suppose that you means > > OffsetFetch/OffsetCommit. > > > > DJ10: Should we add isSimpleConsumerGroup to GroupListing? It is also a > > sort of group type. > > > > DJ11: What do you think about having listGroups(GroupType), > > listGroups(Set<GroupType>) and listGroups() instead of passing types via > > the options? It may be more convenient for users. > > > > DJ12: I wonder if we should deprecate ConsumerGroupListing > > and ShareGroupListing and their associate methods. If we have the above, > we > > don't need them anymore. What's your take on this? > > > > Best, > > David > > > > On Fri, Sep 13, 2024 at 10:53 AM Andrew Schofield < > > andrew_schofield_j...@outlook.com> wrote: > > > > > Hi Lucas, > > > Thanks for the review. I've updated the KIP with the suggestions > > > and will open up a vote soon. > > > > > > Thanks, > > > Andrew > > > > > > ________________________________________ > > > From: Lucas Brutschy <lbruts...@confluent.io.INVALID> > > > Sent: 11 September 2024 15:17 > > > To: dev@kafka.apache.org <dev@kafka.apache.org> > > > Subject: Re: [DISCUSS] KIP-1043: Administration of groups > > > > > > Hi Andrew, > > > > > > thanks for the KIP! > > > > > > It is looking good from my side! I like the simplification, and that > > > we added the new error but only of the Describe RPCs. It's a good > > > pragmatic improvement of the current state of things. > > > > > > I only have very minor comments: > > > - nit: In `GroupListing`, you seem to import `ShareGroupState` and > > > it's not clear why. > > > - The documentation for `--consumer` in the table is not enough. We > > > should make sure that the comment below the table is also included in > > > the command-line help of the CLI tool -- I was confused by this at > > > first. Possibly just explain it in terms of the equivalent sequence of > > > commands. > > > > > > From my point of view, this is ready for a vote. > > > > > > Cheers, > > > Lucas > > > > > > > > > > > > On Tue, Sep 3, 2024 at 2:56 PM Andrew Schofield > > > <andrew_schofield_j...@outlook.com> wrote: > > > > > > > > Hi, > > > > I’ve spent some time working with clusters containing groups of > > multiple > > > > types, fixing problems and improving error handling. > > > > > > > > I’ve simplified the KIP so that it just adds kafka-groups.sh and > > improves > > > > the error handling for describing groups of the wrong type. With the > > > other > > > > improvements I’ve already made, it seems to me that this is > sufficient > > to > > > > make working with groups of multiple types work nicely. > > > > > > > > I’d like to ask for another round of reviews before hopefully opening > > up > > > > a vote soon. > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1043%3A+Administration+of+groups > > > > > > > > Thanks, > > > > Andrew > > > > > > > > ________________________________________ > > > > From: Andrew Schofield <andrew_schofield_j...@live.com> > > > > Sent: 02 August 2024 15:00 > > > > To: dev@kafka.apache.org <dev@kafka.apache.org> > > > > Subject: Re: [DISCUSS] KIP-1043: Administration of groups > > > > > > > > Hi Lianet, > > > > Thanks for your comment. > > > > > > > > I’ve been digging more into the situation with describing groups in a > > > > broker with groups of multiple types. It’s a bit fiddly because of > the > > > > introduction of the modern consumer groups by KIP-848 and the > > > > need for the admin client to cope with both kinds of consumer groups > > > > and older brokers. > > > > > > > > If you use `kafka-consumer-groups.sh --describe --group MYSHARE` > > > > the output is: > > > > > > > > Error: Consumer group ‘MYSHARE’ does not exist. > > > > > > > > How does it get there? AdminClient.describeConsumerGroups > > > > is complicated. > > > > > > > > First, it uses the ConsumerGroupDescribe RPC which responds > > > > with GROUP_ID_NOT_FOUND (69) and an empty error message. > > > > The broker *could* fill in the error message to help with this > > situation > > > > but I don’t like that as a solution. Seems quite brittle. > > > > > > > > Then, it uses the DescribeGroups RPC in case it’s a classic consumer > > > > group. This responds with error code NONE (0) and makes the group > > > > look like a Dead consumer group. There is no error message field > > > > in that RPC at all, so we don’t have the option of using an error > > > > message to disambiguate. > > > > > > > > So, `kafka-consumer-groups.sh` thinks that it’s dealing with a dead > > > > consumer group and its output makes sense. > > > > > > > > My preferred course of action here is as you suggest to introduce > > > > the new error code, INVALID_GROUP_TYPE. If you use any of the > following > > > > RPCs with the wrong type of group, you get this response: > > > > > > > > * ConsumerGroupDescribe > > > > * ShareGroupDescribe > > > > * ConsumerGroupHeartbeat > > > > * ShareGroupHeartbeat > > > > > > > > The remaining RPCs for consumer groups, such as ListOffsets and > > > > TxnOffsetCommit continue to use `GROUP_ID_NOT_FOUND`. > > > > > > > > Does that make sense? Any further comments? > > > > > > > > Thanks, > > > > Andrew > > > > > > > > > On 23 Jul 2024, at 17:26, Lianet M. <liane...@gmail.com> wrote: > > > > > > > > > > Hello Andrew, > > > > > > > > > > Bringing here the point I surfaced on the KIP-1071 thread: > > > > > > > > > > I wonder if at this point, where we're getting several new group > > types > > > > >> added, each with RPCs that are supposed to include groupId of a > > > certain > > > > >> type, we should be more explicit about this situation. Maybe a > kind > > of > > > > >> INVALID_GROUP_TYPE (group exists but not with a valid type for > this > > > RPC) vs > > > > >> a GROUP_ID_NOT_FOUND (group does not exist). Those errors would > be > > > > >> consistently used across consumer, share, and streams RPCs > whenever > > > the > > > > >> group id is not of the expected type. > > > > > > > > > > > > > > > I noticed it on KIP-1071 but totally agree with you that it would > > make > > > more > > > > > sense to consider it here. > > > > > > > > > > LM9. Regarding the point of introducing a new INVALID_GROUP_TYPE vs > > > reusing > > > > > the existing INCONSISTENT_PROTOCOL_TYPE. My concern with reusing > > > > > INCONSISTENT_GROUP_PROTOCOL for errors with the group ID is that it > > > mixes > > > > > the concepts of group type and protocol. Even though they are > closely > > > > > related, we have 2 separate concepts (internally and presented in > > > output > > > > > for commands), and the relationship is not 1-1 in all cases. Also, > > the > > > > > INCONSISTENT_GROUP_PROTOCOL is already used not only for protocol > but > > > also > > > > > when validating the list of assignors provided by a consumer in a > > > > > JoinGroupRequest. Seems a bit confusing to me already, so maybe > > better > > > not > > > > > to add more to it? Just first thoughts. What do you think? > > > > > > > > > > Thanks, > > > > > Lianet > > > > > > > > > > On Fri, Jul 19, 2024 at 5:00 AM Andrew Schofield < > > > andrew_schofi...@live.com> > > > > > wrote: > > > > > > > > > >> Hi Apoorv, > > > > >> Thanks for your comments. > > > > >> > > > > >> AM1: I chose to leave the majority of the administration for the > > > different > > > > >> types of groups in their own tools. The differences between the > > group > > > > >> types are significant and I think that one uber tool that subsumes > > > > >> kafka-consumer-groups.sh, kafka-share-groups.sh and > > > > >> kafka-streams-application-reset.sh would be too overwhelming and > > > > >> difficult to use. For example, the output from describing a > consumer > > > group > > > > >> is not the same as the output from describing a share group. > > > > >> > > > > >> AM2: I think you’re highlighting some of the effects of the > > evolution > > > > >> of groups. The classic consumer group protocol defined the idea > > > > >> of protocol as a way of distinguishing between the various ways > > people > > > > >> had extended the base protocol - “consumer", “connect", and “sr" > are > > > the > > > > >> main ones I’ve seen, and the special “” for groups that are not > > using > > > > >> member assignment. > > > > >> > > > > >> For the modern group protocol, each of the proposed > implementations > > > > >> brings its own use of the protocol string - “consumer”, “share” > and > > > > >> “streams”. > > > > >> > > > > >> Now, prior to AK 4.0, in order to make the console consumer use > the > > > > >> new group protocol, you set `--consumer-property > > > group.protocol=consumer`. > > > > >> This tells a factory method in the consumer to use the > > > AsyncKafkaConsumer > > > > >> (group type is Consumer, protocol is “consumer") as opposed to the > > > > >> LegacyKafkaConsumer (group type is Classic, protocol is > “consumer”). > > > > >> In AK 4.0, the default group protocol will change and setting the > > > property > > > > >> will not be necessary. The name of the configuration > > “group.protocol” > > > > >> is slightly misleading. In practice, this is most likely to be > used > > > pre-AK > > > > >> 4.0 > > > > >> by people wanting to try out the new consumer. > > > > >> > > > > >> AM3: When you try to create a share group and that group ID is > > already > > > > >> in use by another type of group, the error message is “Group CG1 > is > > > not > > > > >> a share group”. It exists already, with the wrong type. > > > > >> > > > > >> AM4: This KIP changes the error behaviour for > > > `kafka-consumer-groups.sh` > > > > >> and `kafka-share-groups.sh` such that any operation on a group > that > > > finds > > > > >> the > > > > >> group type is incorrect reports “Error: Group XXX is not a > consumer > > > group” > > > > >> or > > > > >> equivalent for the other group types. This change makes things > much > > > easier > > > > >> to > > > > >> understand than they are today. > > > > >> > > > > >> AM5: That section is just clarifying what the behaviour is. I > don’t > > > think > > > > >> it had > > > > >> been written down before. > > > > >> > > > > >> Thanks, > > > > >> Andrew > > > > >> > > > > >>> On 18 Jul 2024, at 16:43, Apoorv Mittal < > apoorvmitta...@gmail.com> > > > > >> wrote: > > > > >>> > > > > >>> Hi Andrew, > > > > >>> Thanks for the KIP. The group administration is getting difficult > > > with > > > > >> new > > > > >>> types of groups being added and certainly the proposal looks > great. > > > > >>> I have some questions: > > > > >>> > > > > >>> AM1: The current proposal defines the behaviour for listing and > > > > >> describing > > > > >>> groups, simplifying create for `kafka-share-groups.sh`. Do we > want > > to > > > > >> leave > > > > >>> the other group administration like delete to respective groups > or > > > shall > > > > >>> have common behaviour defined i.e. leave to respective > > > > >>> kafka-consumer-groups.sh or kafka-share-groups.sh? > > > > >>> > > > > >>> AM2: Reading the notes on KIP-848, > > > > >>> > > > > >> > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/The+Next+Generation+of+the+Consumer+Rebalance+Protocol+%28KIP-848%29+-+Early+Access+Release+Notes > > > > >> , > > > > >>> which requires `--consumer-property group.protocol=consumer` to > > > enable > > > > >>> modern consumer group. But the listing for `classic` "type" also > > > defines > > > > >>> "protocol" as `consumer` in some scenarios. Is it intended or > > > `classic` > > > > >>> type should different protocol? > > > > >>> > > > > >>> AM3: The KIP adds behaviour for `kafka-share-groups.sh` which > > > defines > > > > >> the > > > > >>> `--create` option. Though it simplifies group creation, what > should > > > be > > > > >> the > > > > >>> error behaviour when the group with the same name exists but not > of > > > > >> "share" > > > > >>> group type? > > > > >>> > > > > >>> AM4: The GroupMetadataManager.java stores all groups in the same > > data > > > > >>> structure which means the name has to be unique across different > > > group > > > > >>> types. Do you think we should also change the error message for > > > existing > > > > >>> kafka-consumer-groups.sh and kafka-share-groups.sh to recommend > > > using new > > > > >>> kafka-groups.sh for extensive groups list? As currently the > > > individual > > > > >>> scripts will result in "Group already exists" while creating new > > > groups > > > > >> but > > > > >>> listing with respective utility will not yield the group. > > > > >>> > > > > >>> AM5: The KIP defines compatibility considerations for the > > ListGroups > > > RPC. > > > > >>> But it's unclear to me why it's needed as the client and server > > > > >> supporting > > > > >>> `kafka-groups.sh` will be post ListGroups v5 API anyways hence > > > > >> TypesFilter > > > > >>> will be supported in both client and server. Am I missing > something > > > here? > > > > >>> > > > > >>> Regards, > > > > >>> Apoorv Mittal > > > > >>> +44 7721681581 > > > > >>> > > > > >>> > > > > >>> On Wed, Jul 17, 2024 at 6:26 PM Andrew Schofield < > > > > >> andrew_schofi...@live.com> > > > > >>> wrote: > > > > >>> > > > > >>>> Hi Lianet, > > > > >>>> Thanks for your comments. > > > > >>>> > > > > >>>> LM5. Unfortunately, the protocol type has to be a string rather > > than > > > > >>>> an enumeration. This is because when people have created their > own > > > > >>>> extensions of the classic consumer group protocol, they have > > chosen > > > > >>>> their own protocol strings. For example, the Confluent schema > > > registry > > > > >>>> uses “sr” and there are other examples in the wild. > > > > >>>> > > > > >>>> LM6.1. It’s because of the difference between a parameterised > > > > >>>> type and a raw type. > > > > >>>> > > > > >>>> If I use: > > > > >>>> public class ListGroupsResult<T extends GroupListing> > > > > >>>> public class ListConsumerGroupsResult<ConsumerGroupListing> > > > > >>>> > > > > >>>> then ListGroupsResult (no type variable) is a raw type which > does > > > > >>>> not provide a type for the type variable. This causes compiler > > > warnings > > > > >>>> when the type is used, unless it’s used as > > > > >> ListGroupsResult<GroupListing>. > > > > >>>> > > > > >>>> However, this works better. > > > > >>>> public class AbstractListGroupsResult<T extends GroupListing> > > > > >>>> public class ListGroupsResult extends > > > > >>>> AbstractListGroupsResult<GroupListing> > > > > >>>> public class ListConsumerGroupsResult extends > > > > >>>> AbstractListGroupsResult<ConsumerGroupListing> > > > > >>>> > > > > >>>> I’ll change the KIP to use this. > > > > >>>> > > > > >>>> LM6.2. I was just pointing out a difference and you’re happy > > > > >>>> with it. That’s good. > > > > >>>> > > > > >>>> LM7. If you have a cluster with a mixture of classic and modern > > > > >>>> consumer groups, to list them all you could use this: > > > > >>>> > > > > >>>> bin/kafka-groups.sh --protocol consumer > > > > >>>> > > > > >>>> When there are no classic consumer groups, you could do: > > > > >>>> > > > > >>>> bin/kafka-groups.sh --group-type consumer > > > > >>>> > > > > >>>> However, this only gives a complete list if you don’t have any > > > classic > > > > >>>> consumer groups. > > > > >>>> > > > > >>>> As a result, I suggested --consumer so you don’t need to know > > > > >>>> or care about the existence of classic and modern consumer > groups. > > > > >>>> I think it helps, but you aren’t convinced I think, which tells > me > > > > >>>> more thinking needed here. > > > > >>>> > > > > >>>> Maybe adding --share would help, so only power users would > > > > >>>> use --group-type or --protocol to deal with the more complicated > > > > >>>> cases. > > > > >>>> > > > > >>>> LM8. It’s just not clear. I was trying to make the output the > same > > > > >>>> whether the group was created, or whether it already existed. In > > > > >>>> either case, there’s a share group in existence. The > > > > >>>> AlterShareGroupOffsets RPC doesn’t distinguish between the > > > > >>>> two cases in its response. > > > > >>>> > > > > >>>> Thanks, > > > > >>>> Andrew > > > > >>>> > > > > >>>>> On 16 Jul 2024, at 21:24, Lianet M. <liane...@gmail.com> > wrote: > > > > >>>>> > > > > >>>>> Hello Andrew, thanks for considering the feedback. Some > > follow-ups > > > and > > > > >>>>> other comments: > > > > >>>>> > > > > >>>>> LM4. Good point about the older RPC versions and therefore the > > > > >>>>> Optional<GroupType>, agreed. > > > > >>>>> > > > > >>>>> LM5. In GroupListing, should we use the existing > > > > >>>>> org.apache.kafka.clients.ProtocolType to represent the protocol > > > > >> (instead > > > > >>>> of > > > > >>>>> String). I don’t quite like the fact that the enum is inside > the > > > > >>>>> GroupRebalanceConfig though, feels like it should be a first > > level > > > > >>>> citizen. > > > > >>>>> > > > > >>>>> > > > > >>>>> LM6. Regarding the changes around ListGroupResults with > generics. > > > > >>>>> - LM6.1. What’s the need for keeping both, a base > > > > >>>>> AbstractListGroupsResult<T extends GroupListing> and the > > > > >> ListGroupsResult > > > > >>>>> extends AbstractListGroupsResult<GroupListing>? Would it work > if > > > > >> instead > > > > >>>> we > > > > >>>>> simply have a single ListGroupsResult<T extends GroupListing> > > from > > > > >> which > > > > >>>>> specific groups would inherit? I'm thinking of this: > > > > >>>>> > > > > >>>>> public class *ListGroupsResult<T extends GroupListing>* -> this > > > would > > > > >>>>> probably end up containing the implementation that currently > > > exists in > > > > >>>>> ListConsumerGroupsResult for #all, #errors and #valid, that all > > > group > > > > >>>> types > > > > >>>>> would be able to reuse if we use a generic T extends > GroupListing > > > > >>>>> > > > > >>>>> > > > > >>>>> public class *ListConsumerGroupsResult extends > > > > >>>>> ListGroupsResult<ConsumerGroupListing>* -> slim impl, agreed > > > > >>>>> > > > > >>>>> - LM6.2. Related to the concern of the javadoc for > > > > >>>>> ListConsumerGroupsResult. This class will inherit 3 funcs (all, > > > valid, > > > > >>>>> error), that have a common behaviour (and javadoc) regardless > of > > > the > > > > >>>>> generic type, so I expect it won’t be confusing in practice? We > > > will > > > > >> end > > > > >>>> up > > > > >>>>> with the java doc for, let’s say, ListConsumerGroupsResult#all > > > showing > > > > >>>> the > > > > >>>>> parent javadoc that aligns perfectly with what the #all does. > If > > > ever > > > > >> we > > > > >>>>> need a different behaviour/javadoc for any of the functions in > > the > > > > >> child > > > > >>>>> classes, we would have the alternative of overriding the func > and > > > > >>>> javadoc. > > > > >>>>> Makes sense? Not sure if I’m missing other readability issues > > with > > > the > > > > >>>>> javadocs you’re seeing. > > > > >>>>> > > > > >>>>> LM7. Looks better to me now with the added filter on the > > > kafka-group.sh > > > > >>>> for > > > > >>>>> the protocol. But then, the new –consumer filter achieves the > > same > > > as > > > > >>>>> –protocol CONSUMER right? If so, I wonder if it would just be > > > simpler > > > > >> to > > > > >>>>> support the --protocol as a way to achieve this? (sharing your > > > struggle > > > > >>>> on > > > > >>>>> how to get this right, but feels easier to discover and reason > > > about > > > > >> the > > > > >>>>> more we have filters based on the output, and not made up of > > > > >>>>> combinations....let's keep iterating and we'll get there :) ) > > > > >>>>> > > > > >>>>> LM8. Is the output wrong (or just not clear) in this example? > (It > > > > >> seemed > > > > >>>> to > > > > >>>>> me this was referring to the successful case where we create a > > new > > > > >> share > > > > >>>>> group, so I was expecting a "successfully created" kind of > > output) > > > > >>>>> > > > > >>>>> $ bin/kafka-share-groups.sh --bootstrap-server > > > localhost:9092 > > > > >>>>> --create --group NewShareGroup > > > > >>>>> Share group 'NewShareGroup' exists. > > > > >>>>> > > > > >>>>> Thanks! > > > > >>>>> > > > > >>>>> Lianet > > > > >>>>> > > > > >>>>> On Mon, Jul 15, 2024 at 6:00 AM Andrew Schofield < > > > > >>>> andrew_schofi...@live.com> > > > > >>>>> wrote: > > > > >>>>> > > > > >>>>>> Hi Lianet, > > > > >>>>>> Thanks for your comments. > > > > >>>>>> > > > > >>>>>> LM1. Admin.listGroups() in principle needs to be able to > return > > > > >>>>>> results from any version of the ListGroups RPC. The older > > > versions do > > > > >>>>>> not contain the group type, so I think it’s reasonable to have > > > > >>>>>> Optional<GroupType>. I think there’s a difference between > > > > >>>>>> Optional.empty (I don’t know the group type) and > > > > >>>>>> GroupType.UNKNOWN (I know and do not understand the group > type). > > > > >>>>>> As a result, I’ve changed the KIP to use Optional<GroupType>. > > > > >>>>>> > > > > >>>>>> I think that changing ConsumerGroupListing to extend > > > > >>>>>> GroupListing, and to do the same for ShareGroupListing makes > > > sense. > > > > >>>>>> This does require that the overridden methods such as type() > > have > > > > >>>>>> signatures that match today’s definition of > ConsumerGroupListing > > > but > > > > >>>>>> that’s fine with the change I made to use Optional<GroupType> > > > above. > > > > >>>>>> > > > > >>>>>> LM2. I think it’s possible to do something with generics along > > the > > > > >>>>>> lines you described. > > > > >>>>>> > > > > >>>>>> * public abstract class AbstractListGroupsResult<T extends > > > > >> GroupListing> > > > > >>>>>> * public class ListGroupsResult extends > > > > >>>>>> AbstractListGroupsResult<GroupListing> > > > > >>>>>> * public class ListConsumerGroupsResult extends > > > > >>>>>> AbstractListGroupsResult<ConsumerGroupListing> > > > > >>>>>> > > > > >>>>>> This does make the javadoc for ListConsumerGroupsResult less > > > > >>>>>> readable because its methods are now all inherited. The > classes > > > > >>>>>> such as ListConsumerGroupsResult of course still have to exist > > > > >>>>>> but the implementation is very slim. > > > > >>>>>> > > > > >>>>>> What do you think of this? I haven’t yet updated the KIP in > this > > > > >>>>>> case. > > > > >>>>>> > > > > >>>>>> LM3. I have been kicking around the syntax for kafka-group.sh > > > > >>>>>> for a while now and I too am not happy with the filters yet. I > > > > >>>> absolutely > > > > >>>>>> want to be able to display all consumer groups with a simple > > > option, > > > > >>>>>> but history means that not a single filter under the covers. > > > > >>>>>> > > > > >>>>>> I suggest the following: > > > > >>>>>> --group-type which supports all group types > > > > >>>>>> --protocol which supports any string for protocol (there’s no > > > > >>>> enumeration) > > > > >>>>>> --consumer which matches all classic and modern consumer > groups > > > > >>>>>> (and is thus a confection made by filtering on both group type > > and > > > > >>>>>> protocol). > > > > >>>>>> > > > > >>>>>> I’ve changed the KIP accordingly. Let me know what you think. > > > > >>>>>> > > > > >>>>>> Thanks, > > > > >>>>>> Andrew > > > > >>>>>> > > > > >>>>>> > > > > >>>>>>> On 12 Jul 2024, at 21:48, Lianet M. <liane...@gmail.com> > > wrote: > > > > >>>>>>> > > > > >>>>>>> Hey Andrew, thanks for the KIP, we definitely need visibility > > > from a > > > > >>>>>> higher > > > > >>>>>>> level now that groups are growing. > > > > >>>>>>> > > > > >>>>>>> LM1. Should we have the existing > > > > >>>>>>> org.apache.kafka.clients.admin.ConsumerGroupListing extend > the > > > > >>>>>> GroupListing > > > > >>>>>>> you’re proposing? ConsumerGroupListing already exists with a > > very > > > > >>>> similar > > > > >>>>>>> shape, and this would allow to set a common ground for the > > > existing > > > > >>>> group > > > > >>>>>>> types, and the ones that are coming up (share groups and KS > > > groups). > > > > >>>> Side > > > > >>>>>>> note, the existing ConsumerGroupListing has the type as > > > Optional, but > > > > >>>>>> given > > > > >>>>>>> that the GroupType enum has an UNKNOWN type, I don’t quite > get > > > the > > > > >> need > > > > >>>>>> for > > > > >>>>>>> Optional and seems ok to me as you’re proposing it. > > > > >>>>>>> > > > > >>>>>>> LM2: if the point above makes sense, it would allow us to > > > consider > > > > >>>>>> changing > > > > >>>>>>> the new ListGroupResult you’re proposing to make it generic > and > > > > >>>>>> potentially > > > > >>>>>>> reused by all group types: > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> public class ListGroupsResult { > > > > >>>>>>> > > > > >>>>>>> public KafkaFuture<Collection<? extends GroupListing>> all() > > > > >>>>>>> > > > > >>>>>>> public KafkaFuture<Collection<? extends GroupListing>> > valid() > > > { } > > > > >>>>>>> > > > > >>>>>>> public KafkaFuture<Collection<Throwable>> errors() { } > > > > >>>>>>> > > > > >>>>>>> } > > > > >>>>>>> > > > > >>>>>>> Makes sense? With this, maybe we won’t need specific result > > > classes > > > > >> for > > > > >>>>>>> each group (like the existing ListConsumerGroupsResult), > given > > > that > > > > >> in > > > > >>>>>> the > > > > >>>>>>> end it’s just a wrapper around the GroupListing (which is > what > > > each > > > > >>>> group > > > > >>>>>>> type would redefine). > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> LM3. I get how you're playing with the filters for group > types > > > and > > > > >>>>>>> protocol, but then I find it confusing how we end up with > > filters > > > > >> that > > > > >>>> do > > > > >>>>>>> not match the output ( --group-type that matches the protocol > > > from > > > > >> the > > > > >>>>>>> output and not the type for "consumer" example). What about > > > having > > > > >> the > > > > >>>>>>> –group-type filter on the actual GroupType field of the RPC > > > response > > > > >>>>>> (shown > > > > >>>>>>> in the cmd line output as TYPE); and add a –protocol-type > that > > > would > > > > >>>>>> filter > > > > >>>>>>> on the ProtocolType field of RPC response (shown in the cmd > > line > > > > >>>> output > > > > >>>>>> as > > > > >>>>>>> PROTOCOL). We would have the filters aligned with the output > > for > > > all > > > > >>>>>> cases, > > > > >>>>>>> which seems more consistent. > > > > >>>>>>> > > > > >>>>>>> Thanks! > > > > >>>>>>> > > > > >>>>>>> Lianet > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> On Thu, Jun 6, 2024 at 8:16 AM Andrew Schofield < > > > > >>>>>> andrew_schofi...@live.com> > > > > >>>>>>> wrote: > > > > >>>>>>> > > > > >>>>>>>> Hi Kirk, > > > > >>>>>>>> Thanks for your comments. > > > > >>>>>>>> > > > > >>>>>>>> 1. I’m a big fan of consistency in these things and the > method > > > > >>>>>> signatures > > > > >>>>>>>> match > > > > >>>>>>>> ListConsumerGroupsResult and ListShareGroupsResult. > > > > >>>>>>>> > > > > >>>>>>>> 2. Yes, client-side filtering. > > > > >>>>>>>> > > > > >>>>>>>> 3. I didn’t offer “classic” as an option for --group-type. > > I’ve > > > > >> kicked > > > > >>>>>> the > > > > >>>>>>>> options > > > > >>>>>>>> around in my mind for a while and I decided that using > > > --group-type > > > > >>>> as a > > > > >>>>>>>> way of > > > > >>>>>>>> filtering types in a way that a normal user would understand > > > them > > > > >> was > > > > >>>> a > > > > >>>>>>>> good > > > > >>>>>>>> place to start. For example, I didn’t have `--protocol > > > consumer` for > > > > >>>>>>>> consumer groups > > > > >>>>>>>> and `--group-type share` for share groups, even though > that’s > > > > >>>>>> technically > > > > >>>>>>>> more > > > > >>>>>>>> correct. > > > > >>>>>>>> > > > > >>>>>>>> Since KIP-848, the set of consumer groups is actually formed > > > from > > > > >>>> those > > > > >>>>>>>> which > > > > >>>>>>>> use the classic protocol and those which use the modern > > > protocol. > > > > >> This > > > > >>>>>> tool > > > > >>>>>>>> gives you both together when you use `--group-type > consumer`, > > > which > > > > >> is > > > > >>>>>>>> exactly > > > > >>>>>>>> what kafka-consumer-groups.sh does. > > > > >>>>>>>> > > > > >>>>>>>> Do you think - -group-type classic is helpful? It would > give a > > > list > > > > >> of > > > > >>>>>> all > > > > >>>>>>>> groups using > > > > >>>>>>>> any variant of the classic group protocol. I can easily add > > it. > > > > >>>>>>>> > > > > >>>>>>>> 4, 5. Yes, maybe the wording of the message could improve. > > These > > > > >>>> things > > > > >>>>>>>> are always > > > > >>>>>>>> tricky. I went with “Group CG1 is not a share group.” > because > > it > > > > >>>> doesn’t > > > > >>>>>>>> require the tool > > > > >>>>>>>> to interpret the group type in order to generate the > message. > > > > >>>>>>>> > > > > >>>>>>>> Imagine this scenario. You are using kafka-share-groups.sh > > > > >> --describe > > > > >>>>>> and > > > > >>>>>>>> you’ve > > > > >>>>>>>> used the group ID of a consumer group. Here are some > options: > > > > >>>>>>>> > > > > >>>>>>>> a) “Group CG1 is not a share group.” > > > > >>>>>>>> b) “Incorrect group type (Consumer). Group CG1 is not a > share > > > > >> group.” > > > > >>>>>>>> c) “Group CG1 has the wrong type for this operation. It is > > not a > > > > >> share > > > > >>>>>>>> group." > > > > >>>>>>>> > > > > >>>>>>>> I don’t think “There is already a (consumer) group named > > ‘CG1’” > > > is > > > > >>>> quite > > > > >>>>>>>> right. > > > > >>>>>>>> > > > > >>>>>>>> Any preference? > > > > >>>>>>>> > > > > >>>>>>>> 6. Yes, it is a change in behaviour which is why I mention > it > > > in the > > > > >>>>>> KIP. > > > > >>>>>>>> Personally, I think that’s OK because the existing message > is > > > > >>>> misleading > > > > >>>>>>>> and could definitely cause frustration. Let’s see what other > > > > >> reviewers > > > > >>>>>>>> think. > > > > >>>>>>>> > > > > >>>>>>>> Thanks, > > > > >>>>>>>> Andrew > > > > >>>>>>>> > > > > >>>>>>>>> On 6 Jun 2024, at 00:44, Kirk True <k...@kirktrue.pro> > > wrote: > > > > >>>>>>>>> > > > > >>>>>>>>> Hi Andrew, > > > > >>>>>>>>> > > > > >>>>>>>>> Thanks for the KIP! I don’t have much experience as a Kafka > > > > >> operator, > > > > >>>>>>>> but this seems like a very sane proposal. > > > > >>>>>>>>> > > > > >>>>>>>>> Questions & comments: > > > > >>>>>>>>> > > > > >>>>>>>>> 1. Do you think the ListGroupsResult.all() method is a bit > > of a > > > > >>>>>>>> potential ‘foot gun’? I can imagine cases where developers > > > reach for > > > > >>>>>> that > > > > >>>>>>>> without understanding its potential of throwing errors. It > > could > > > > >> lead > > > > >>>> to > > > > >>>>>>>> cases where all() works in development but not in > production. > > > > >>>>>>>>> > > > > >>>>>>>>> 2. Based on the LIST_GROUPS RPC, it appears that filtering > is > > > all > > > > >>>>>>>> performed client side, correct? (I know that’s not specific > to > > > this > > > > >>>> KIP, > > > > >>>>>>>> but just want to make sure I understand.) > > > > >>>>>>>>> > > > > >>>>>>>>> 3. For kafka-groups.sh --list, is ‘classic’ valid for > > > --group-type? > > > > >>>> If > > > > >>>>>>>> so, should we allow users of kafka-groups.sh --list to > provide > > > > >>>> multiple > > > > >>>>>>>> --group-type arguments? > > > > >>>>>>>>> > > > > >>>>>>>>> 4. In the last kafka-share-groups.sh --create example > > > > >>>>>> (“ConsumerGroup”), > > > > >>>>>>>> the error simply states that “Group 'ConsumerGroup’ is not a > > > share > > > > >>>>>> group.” > > > > >>>>>>>> I’m assuming that’s the case where the user gets a failure > > when > > > > >>>> there’s > > > > >>>>>>>> already a group named “ConsumerGroup”, right? If so, the > error > > > > >> should > > > > >>>> be > > > > >>>>>>>> something like “There is already a (consumer) group named > > > > >>>>>> ’ConsumerGroup’”. > > > > >>>>>>>>> > > > > >>>>>>>>> 5. In the last kafka-share-groups.sh --describe example, > how > > > hard > > > > >> is > > > > >>>> it > > > > >>>>>>>> to add the type of group that CG1 is, just for a bit of > > clarity > > > for > > > > >>>> the > > > > >>>>>>>> user? > > > > >>>>>>>>> > > > > >>>>>>>>> 6. In the kafka-consumer-groups.sh section, it states "if > > that > > > > >> group > > > > >>>>>>>> exists but is not a consumer group, the command fails with a > > > message > > > > >>>>>>>> indicating that the group type is incorrect, rather than the > > > > >> existing > > > > >>>>>>>> message that the group does not exist.” That sounds like a > > > change > > > > >> that > > > > >>>>>>>> could trip up some brittle scripts somewhere, but I don’t > know > > > if > > > > >>>>>> that’s a > > > > >>>>>>>> serious problem. > > > > >>>>>>>>> > > > > >>>>>>>>> Thanks! > > > > >>>>>>>>> > > > > >>>>>>>>>> On Jun 4, 2024, at 10:08 AM, Andrew Schofield < > > > > >>>>>>>> andrew_schofi...@live.com> wrote: > > > > >>>>>>>>>> > > > > >>>>>>>>>> Hi, > > > > >>>>>>>>>> I would like to start a discussion thread on KIP-1043: > > > > >>>> Administration > > > > >>>>>>>> of groups. This KIP enhances the command-line tools to make > it > > > > >> easier > > > > >>>> to > > > > >>>>>>>> administer groups on clusters with a variety of types of > > groups. > > > > >>>>>>>>>> > > > > >>>>>>>>>> > > > > >>>>>>>> > > > > >>>>>> > > > > >>>> > > > > >> > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1043%3A+Administration+of+groups > > > > >>>>>>>>>> > > > > >>>>>>>>>> Thanks. > > > > >>>>>>>>>> Andrew > > > > >> > > > > >> > > > > >> > > > > > >
