Status

Current state: "Under Discussion"  Accepted

Discussion thread: here

Vote thread:  "Will update after discussion" here

JIRA: KAFKA-19784

PR: https://github.com/apache/kafka/pull/20691

...

However, when users call AdminClient.describeConsumerGroups(), the returned MemberDescription objects do not include this rack information. The rack ID is available in the wire protocol but is discarded during response processing in DescribeConsumerGroupsHandler.

The Similar case is for AdminClient.describeShareGroups(). The current status can be summarized as follows:

Problem Statement

This limitation creates several issues:

...

kafkaConsumerConfig.customConfig(ConsumerConfig.CLIENT_ID_CONFIG, generateClientIdWithRack(ip, rack));

Image RemovedImage Added

Public Interfaces

...

public class MemberDescription {
    private final String memberId;
    private final Optional<String> groupInstanceId;
    private final Optional<String> rackId;  // NEWnew FIELDfield
    private final String clientId;
    //omit other codes        
    public Optional<String> rackId() {  // new method
       return rackId;
    }
    //omit other codes
}

2.  Add rack ID support to org.apache.kafka.clients.admin.MemberDescriptionShareMemberDescription:

public class ShareMemberDescription{     
    private final String memberId;
    private final Optional<String> rackId; // NEWnew FIELD field
    private private final String clientId;
    //omit other codes        
    public Optional<String> rackId() {  // new method
       return rackId;
    }
    //omit other codes
}

Proposed Changes

 You can refer to https://github.com/apache/kafka/pull/20691:

...

• Mark old constructor as @Deprecated immediately
• Keep it available for at least 2 major releases Remove in Kafka 4.2.0 or laterand then remove them.

Test Plan

We can use follow test to cover the change:

...

• Behavior with mixed rack configurations
• Behavior with classic and new protocol groups
  
  

Rejected Alternatives

Alternative 1: Create a New API
Proposal: Create describeConsumerGroupsWithRack() method
Rejection Reason:

• Unnecessary API proliferation
• The information already exists in the protocol
• Extending existing API is more intuitive
• Similar precedent: KIP-345 added groupInstanceId to existing MemberDescription