Hey Neha, Thanks for the feedback. I don't have a strong position on either of the points you mentioned. If we're fine having an additional request type, then maybe we could do something like this:
1. GroupMetadata accepts an array of groupIds and just returns the coordinator for each group. An empty array can be used to get all groups managed by the broker. 2. DescribeGroup takes a single groupId and returns all metadata including the group state and the member states. What do you think? Thanks, Jason On Wed, Oct 28, 2015 at 1:20 PM, Neha Narkhede <n...@confluent.io> wrote: > I slightly prefer one of the rejected alternatives over the currently > suggested one - which is to add a separate DescribeGroupRequest that always > returns the member metadata for the group and any other information useful > for monitoring and tooling. It helps keep the abstractions clean and also > reduces the number of optional fields in the existing requests. > > Also, TopicMetadataRequest returns information for all topics if the > requested topic is null. Is there a reason to handle this differently for > consumer group metadata? > > > > > On Wed, Oct 28, 2015 at 12:59 PM, Gwen Shapira <g...@confluent.io> wrote: > > > Looks awesome to me :) > > > > This will allow to both list all groups and to retrieve offsets for > > specific groups. > > > > Since 3 days passed with no comments, would you like to start a vote? > > > > On Sun, Oct 25, 2015 at 6:29 PM, Jason Gustafson <ja...@confluent.io> > > wrote: > > > Hi Kafka Devs, > > > > > > Currently, the new consumer provides no way to view a group's status > > except > > > by inspecting coordinator and consumer logs. This includes listing the > > > members of the group and their partition assignments. For the old > > consumer, > > > tools could read this information directly from Zookeeper, but with > > > persistence up in the air for the new consumer, that may not be > possible. > > > Even if it were, we might prefer to use a request API (in line with > > KIP-4) > > > since that keeps tooling decoupled from the storage system and makes > > access > > > control easier. Along those lines, I've created KIP-40 to solve this > > > problem by extending the GroupMetadata request (formerly known as the > > > ConsumerMetadata request). Have a look and let me know what you think! > > > > > > KIP-40: > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-40%3A+GroupMetadata+request+enhancement > > > > > > > > > Thanks, > > > Jason > > > > > > -- > Thanks, > Neha >
