...

1. Create version 2 of DescribeGroups protocol to include additional information about the consumer group and also each group member for the API clients.
2. Update the consumer group command to provide the added information in the command output (where applicable). Note that this KIP will improve upon KIP-175 where group state and detailed member information will also be returned by the consumer group command using additional command line options. Therefore, the output of some of the sub-options introduced in KIP-175 will improve to include the newly available information by this KIP. Suggested changes are:
   1. Updating the --state option to also include a GENERATION-ID and LEADER-ID column.
   2. Providing the missing member ASSIGNMENT-STRATEGY value for --members option.
   3. Providing the missing member SUBSCRIPTION value for --members --verbose option.
3. On a related subject but perhaps unrelated to the protocol enhancement, also update the consumer group command to provide filtering by topic as well (similar to how the old consumer offset checker tool supported this filtering).

Compatibility, Deprecation, and Migration Plan

Since this KIP follows KIP-175, the output for sub-options --members and --state that are introduced in that KIP will be modified to also include the newly added fields. Therefore, clients who rely on the output for those sub-options may need to be adjusted. It also helps the consumer group --describe command to fill some of the newly added columns introduced by KIP-175 (i.e. ASSIGNMENT-STRATEGY for --members options, and SUBSCRIPTION for --members --verbose option).

Rejected Alternatives

There are other information available for a consumer group that could be included in the KIP. For example:

• newMemberAdded

• receivedConsumerOffsetCommits

• receivedTransactionalOffsetCommits

...

• Providing this additional information in the server logs: It is much more convenient to look up this new pieces of information via the consumer group command tool. Plus, these fields and their underlying concepts are not likely to disappear in the future. So we would not have to worry about making a protocol change that will likely become obsolete in the future.