Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Currently, client produce/consume quota configurations are stored in the Zookeeper. Brokers monitor the changes of quota configurations from Zookeeper, and then enforce them in the process of each produce/consume request. Any changes to the client quota configurations have to talk to Zookeeper directly, which introduces more overhead for users. Given that we have released the KafkaAdminClient, which is capable of managing the configurations of brokers and topics for customers, it's desire to also support the configuration of quota rules. In this case, applications can leverage the unified KafkaAdminClient to manage their quota configurations, instead of the direct dependency on Zookeeper.

Public Interfaces

We need to define these two entities (User and Client) in the client packages as follows:

    1. org.apache.kafka.clients.admin package:
      1. Add two new types (USER and CLIENT) in the ConfigResource.Type.
      2. These two types will be used to represent a user config or client config
      3. user-clientId config is included in the user config
    2. org.apache.kafka.common.config package
      1. Add two new types(USER and CLIENT) in the ConfigResource
    3. org.apache.kafka.common.requests package:
      1. Add two types in the ConfigSource enum
        1. DYNAMIC_USER_CONFIG((byte) 6),
        2. DYNAMIC_CLIENT_CONFIG((byte) 7);

Proposed Changes

Add logic to handle the user and client quota config changes in the kafka.server package.

    1. add support for Users and Clients in the describeConfigs and alterConfigs in the AdminManager
    2. We leverage the following two utils from adminZKClient package
      1. adminZkClient.changeUserOrUserClientIdConfig(user, properties)
      2. adminZkClient.changeClientIdConfig(client, properties)

Compatibility, Deprecation, and Migration Plan

    1. We only add a new way to configure the quotas, there is nothing to migrate.

...