Hey Ashish, Yeah, that's fine with me too. I thought people kind of frowned upon the use of an empty topic list to get all topics, but perhaps it's more of an issue at the user API level.
-Jason On Wed, Oct 28, 2015 at 2:58 PM, Ashish Singh <asi...@cloudera.com> wrote: > Jason, thanks for the great write up. I am overall in favor of changes > suggested. However, I too think that there is no specific need of > *IncludeAllGroups* flag, but that could be due to me not being aware of why > this pattern is frowned upon for TopicMetadataRequest. To me it simply > eases the use. > > > 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 > > > > > > -- > > Regards, > Ashish >
