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
