Page History

...

• Introducing new entity types for kafka-configs.sh that producers and consumers can associate themselves with. This would make the tool more cumbersome to use and it is most intuitive that client configurations be dynamically altered with the clients and users entity types.

• Use the {Describe, IncrementalAlter}Configs APIs. Client config entities are more dynamic than entities with a singular resource name and type which makes it hard to fit them into generic APIs that expect a distinct entity name and type.
• Use the <user/client-id> hierarchy implemented for client quotas in KIP-55 and extended for the admin client in KIP-546. Quotas are inherently hierarchical but client configs are not, so it seems reasonable to use a hierarchy of shallow depth for dynamic client configs.

• Making client config compatibility information available to the user

  The user should be able to see what dynamic configs are supported for each application. However, clients that are using the same <user, client-id> entity may not necessarily support the same dynamic configs, storing a list of supported configs alongs side quotas and configs is a flawed solution.

  A better solution is to store config registrations in an internal topic. The Java producer and consumer clients can register the configs that they support with a DescribeClientConfigsRequest. The broker can write a key-value pair to an internal topic upon receiving the request where the key is the <user, client-id> entity and the value is ClientVersion along with the list of supported configs.

  Ad hoc aggregations of registration data for a particular entity could be performed to give descriptive information about client config compatibility to the user. All versions of clients that registered with a <user, client-id> entity along with the supported configs for each version of client could be aggregated and when a DescribeClientConfigsRequest from an admin client is received. This information would then be returned to the user admin client in the DescribeClientConfigsResponse. For example, supported dynamic configs for user-principal 'alice', client-id 'clientid-override' are "{ 'ClientInformation(softwareName=apache-kafka-java, softwareVersion=x.y.za-SNAPSHOT)': 'acks', 'ClientInformation(softwareName=apache-kafka-java, softwareVersion=x.y.zb-SNAPSHOT)': 'acks, enable.idempotence' }".

• Interesting hierarchies for config overrides could be constructed if the Java producer and consumer resolved the dynamic configs instead of the broker. For example,  from most precedent to least precedent:
  • /config/users/<user>/clients/<client-id>
  • .properties file configs
  • /config/users/<user>
  • Static default configs defined in ProducerConfig and ConsumerConfig.

...