...

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

Public Interfaces

We need to do tiny change for the existed public class:
1. Add rack ID support to org.apache.kafka.clients.admin.MemberDescription:

...

public class MemberDescription {
    private final String memberId;
    private final Optional<String> groupInstanceId;
    private final Optional<String> rackId;  // NEW FIELD
    private final String clientId;
    private final String host; 
    //omit other codes
}

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

public class MemberDescription ShareMemberDescription{     
    private final String memberId;
    private final Optional<String> rackId; // NEW FIELD 
    private final String clientId;
    private final String host;
    //omit other codes
}

...

public interface RemoteLogMetadataManager extends BrokerReadyCallback, Configurable, Closeable 

Proposed Changes

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

 We postpone the TopicBasedRemoteLogMetadataManager's initialization part (quering metedata from remote topic) after the server is ready for the request. 

...

20691:

•  add rackId into MemberDescription and ShareMemberDescription
•  pass through rack ID from protocol response

Compatibility, Deprecation, and Migration Plan 

...

Backward Compatibility

This change is fully backward compatible:

1. Binary Compatibility:

   • The old constructor remains available (marked as @Deprecated)
   • Existing code will continue to compile and run
   • The new field is an Optional, defaulting to empty()

2. Source Compatibility:

   • Existing code using the old constructor continues to work
   • No changes required to existing applications

3. Behavioral Compatibility:

   • Existing behavior is unchanged
   • Only adds new information when available

Migration Path

For users upgrading:

• No action required
• Rack information automatically available when using Admin API
• Access via memberDescription.rackId() when needed

For developers using MemberDescription:

• Old constructor still works
• Recommended to migrate to new constructor over time
• Old constructor may be removed in a future major version (e.g., Kafka 5.0)

Deprecation Plan

• Mark old constructor as @Deprecated immediately
• Keep it available for at least 2 major releases
• Remove in Kafka 4.2.0 or later

Test Plan

Describe in few sentences how the KIP will be tested. We are mostly interested in system tests (since unit-tests are specific to implementation details). How will we know that the implementation works as expected? How will we know nothing broke?

...