group deletion
I'll put in a new KIP soon.
Thanks,
Andrew
From: Chia-Ping Tsai
Sent: 24 April 2025 17:41
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-1043: Administration of groups
hi Andrew
Sorry for making noise on this accepted KIP, but i
hi Andrew
Sorry for making noise on this accepted KIP, but inspired by KIP-1152, have you
considered adding support for pattern filters? It seems to me that the issue
encountered by KIP-1152 could also happen with group IDs.
Best,
Chia-Ping
On 2024/06/04 17:08:10 Andrew Schofield wrote:
> Hi,
e found.
>
> Thanks for your time reviewing this KIP.
>
> Andrew
>
>
> From: David Jacot
> Sent: 28 October 2024 13:37
> To: dev@kafka.apache.org
> Subject: Re: [DISCUSS] KIP-1043: Administration of groups
>
> Hi A
13:37
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-1043: Administration of groups
Hi Andrew,
Thanks for your response. I think that your last proposal makes sense to
me. It seems that we have no choice but to also change the DescribeGroups
API. However, I still have a preference fo
rience 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#listShareGr
min#listShareGroups from KIP-932, along with
related tidying up that results from this.
Thanks,
Andrew
____________
From: David Jacot
Sent: 22 October 2024 11:08
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-1043: Administration of groups
Hi Andrew,
Please e
tocol, 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
>
> __
ka-xxx-groups.sh --list.
Thanks,
Andrew
From: David Jacot
Sent: 02 October 2024 08:54
To: 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 t
> 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),
&
nsumerGroupListing 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
Sent: 23 September 2024 13:57
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-1043: Admin
...@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
> Sent: 11 September 2024 15:17
>
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
Sent: 11 September 2024 15:17
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-1043: Administration of g
Hi Lianet,
Thanks for the review. I've updated the KIP with the suggestions
and will open up a vote soon.
Thanks,
Andrew
From: Lianet M.
Sent: 11 September 2024 18:04
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-1043: Administration of group
rking 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
> >
> > Th
_
> From: Andrew Schofield
> Sent: 02 August 2024 15:00
> To: 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
>
,
Andrew
From: Andrew Schofield
Sent: 02 August 2024 15:00
To: 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
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 consum
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
> INVA
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 a
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-gr
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 sc
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, agreed.
LM5. In GroupListing, should we use the existing
org.apache.kafka.clients.ProtocolType to represent the protocol (instead of
Stri
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. I think there’s a difference between
Optional.empty (I
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
shap
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 m
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 und
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+grou
27 matches
Mail list logo
