Hi everyone,
I have add some changes to the KIP based on the Pull Request:
https://github.com/apache/kafka/pull/4454#issuecomment-360553277 :
* Reduce the scope of the operations to Consumer Groups to avoid complexity
of making assignments generic for Consumer and Connect groups. If Connect
Great!
I have added `listGroupOffsets` to the KIP.
If there are no additional feedback, VOTE thread is already open.
Cheers,
Jorge
El mar., 2 ene. 2018 a las 17:49, Gwen Shapira ()
escribió:
> listGroups and listGroupOffsets will make it a snap to transition the
> existing
listGroups and listGroupOffsets will make it a snap to transition the
existing ConsumerGroups CLI to depend on client libraries only.
Thanks for adding them :)
On Sun, Dec 31, 2017 at 1:39 PM Jorge Esteban Quilcate Otoya <
quilcate.jo...@gmail.com> wrote:
> Thanks all for your feedback, and
Thanks all for your feedback, and sorry for late response.
I'm considering the following:
```AdminClient.java
public abstract ListGroupsResult listGroups(ListGroupsOptions options);
public ListGroupsResult listGroups() {
return listGroups(new ListGroupsOptions());
}
On Tue, Dec 12, 2017, at 09:39, Jason Gustafson wrote:
> Hi Colin,
>
> They do share the same namespace. We have a "protocol type" field in the
> JoinGroup request to make sure that all members are of the same kind.
Hi Jason,
Thanks. That makes sense.
> Very roughly what I was thinking is
Jorge,
Would you consider also adding `listGroupOffsets` to this KIP?
thanks
dan
On Tue, Dec 12, 2017 at 9:39 AM, Jason Gustafson wrote:
> Hi Colin,
>
> They do share the same namespace. We have a "protocol type" field in the
> JoinGroup request to make sure that all
Hi Colin,
They do share the same namespace. We have a "protocol type" field in the
JoinGroup request to make sure that all members are of the same kind. Very
roughly what I was thinking is something like this. First we introduce an
interface for deserialization:
interface
Sorry... this is probably a silly question, but do Kafka Connect groups
share a namespace with consumer groups? If we had a separate API for
Kafka Connect groups vs. Consumer groups, would that make sense? Or
should we unify them?
best,
Colin
On Mon, Dec 11, 2017, at 16:11, Jason Gustafson
Hi Jorge,
Kafka group management is actually more general than consumer groups (e.g.
there are kafka connect groups). If we are adding these APIs, I would
suggest we consider the more general protocol and how to expose
group-protocol-specific metadata. For example, it might be reasonable to
have
Jorge,
is there any update regarding this KIP?
-Matthias
On 11/17/17 9:14 AM, Guozhang Wang wrote:
> Hello Jorge,
>
> I made a pass over the wiki, and here are a few comments:
>
> 1. First, regarding to Tom's comment #2 above, I think if we are only going
> to include the String groupId.
Hello Jorge,
I made a pass over the wiki, and here are a few comments:
1. First, regarding to Tom's comment #2 above, I think if we are only going
to include the String groupId. Then it is Okay to keep as a String than
using a new wrapper class. However, I think we could include the
Hi Tom,
1. You're right. I've updated the KIP accordingly.
2. Yes, I have add it to keep consistency, but I'd like to know what others
think about this too.
Cheers,
Jorge.
El mar., 7 nov. 2017 a las 9:29, Tom Bentley ()
escribió:
> Hi again Jorge,
>
> A couple of minor
Hi again Jorge,
A couple of minor points:
1. ConsumerGroupDescription has the member `name`, but everywhere else that
I've seen the term "group id" is used, so perhaps calling it "id" or
"groupId" would be more consistent.
2. I think you've added ConsumerGroupListing for consistency with
Thanks for the feedback!
@Ted Yu: Links added.
KIP updated. Changes:
* `#listConsumerGroups(ListConsumerGroupsOptions options)` added to the API.
* `DescribeConsumerGroupResult` and `ConsumerGroupDescription` classes
described.
Cheers,
Jorge.
El lun., 6 nov. 2017 a las 20:28, Guozhang Wang
Hi Matthias,
You meant "list groups" I think?
Guozhang
On Mon, Nov 6, 2017 at 11:17 AM, Matthias J. Sax
wrote:
> The main goal of this KIP is to enable decoupling StreamsResetter from
> core module. For this case (ie, using AdminClient within
> StreamsResetter) we get
Hi Jorge,
This looks like a great improvement.
I will echo the question that others had about listGroups. Can we just
add it to this KIP? It's weird to be able to describe groups, but not
list them. In the past, for topics and ACLs, we added describing and
listing functionality together.
In
The main goal of this KIP is to enable decoupling StreamsResetter from
core module. For this case (ie, using AdminClient within
StreamsResetter) we get the group.id from the user as command line
argument. Thus, I think the KIP is useful without "describe group"
command to.
I am happy to include
A quick question: I think we do not yet have the `list consumer groups`
func as in the old AdminClient. Without this `describe group` given the
group id would not be very useful. Could you include this as well in your
KIP? More specifically, you can look at kafka.admin.AdminClientfor more
details
Please fill out Discussion thread and JIRA fields.
Thanks
On Mon, Nov 6, 2017 at 2:02 AM, Tom Bentley wrote:
> Hi Jorge,
>
> Thanks for the KIP. A few initial comments:
>
> 1. The AdminClient doesn't have any API like `listConsumerGroups()`
> currently, so in general how
Hi Jorge,
Thanks for the KIP. A few initial comments:
1. The AdminClient doesn't have any API like `listConsumerGroups()`
currently, so in general how does a client know the group ids it is
interested in?
2. Could you fill in the API of DescribeConsumerGroupResult, just so
everyone knows exactly
Hi everyone,
I would like to start a discussion on KIP-222 [1] based on issue [2].
Looking forward to feedback.
[1]
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74686265
[2] https://issues.apache.org/jira/browse/KAFKA-6058
Cheers,
Jorge.
21 matches
Mail list logo