This page is meant as a template for writing a KIP. To create a KIP choose Tools->Copy on this page and modify with your content and replace the heading with the next KIP number and a description of your issue. Replace anything in italics with your own description.
Status
Current state: "Under Discussion" (Draft)
Discussion thread: here [Change the link from the KIP proposal email archive to your own email thread]
JIRA: here
Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).
Motivation
Currently Mirrormaker uses deprecated alterConfigs
API when syncing topic configurations for broker compatibility to 0.11.0. However, the deprecated alterConfigs()
API replaces any existing configuration with the new configuration. Due to this, additional configurations set on a remote topic get cleared up when MirrorMaker syncs topic configurations even if the configurations are filtered. For example this prevents running Cruise Control on the target cluster as it may set follower.replication.throttled.replicas and leader.replication.throttled.replicas.
MirrorMaker should not clear topic configurations that are filtered on the target cluster.
Public Interfaces
This KIP proposes to migrate to incrementalAlterConfigs
API for syncing topic configurations in MirrorMaker. The incrementalAlterConfigs
API has been around for several years since it was introduced in Kafka 2.3.0 and addresses the shortcoming of the deprecated alterConfigs
API. In order to not break the compatibility, we will introduce a new configuration to MirrorMaker connector to give the option to enable incrementalAlterConfigs
API for syncing topic configurations. This new configuration is expected to serve as a temporary measure until the next major release when the API is always used.
Proposed Changes
1) Add a new method updateTopicConfigsUsingIncrementalAlterConfigs() to MirrorSourceConnector.java
which takes a list topic configurations as a parameter and calls incrementalAlterConfigs()
to the target cluster.
2) Add a new configuration setting to MirrorMaker:
Name: enable.incremental.alter.configs
Description: Deprecated. Whether to automatically use incrementalAlterConfigs API for syncing topic configurations. This configuration will be removed in Kafka 4.0 and the incrementalAlterConfigs API will be used by default. Users should make sure that the target cluster is running at least Kafka 2.3.0 or later.
Type: Boolean
Default: false
Update Mode:
When set to false, MirrorMaker will keep using deprecated alterConfigs API for syncing topic configurations.
When explicitly set to true, MirrorMaker will use incrementalAlterConfigs API for syncing topic configurations. If it receives an error from an incompatible broker, the MirrorMaker will report this to the user and fail the connector.
3) Update `syncTopicConfigs`
Compatibility, Deprecation, and Migration Plan
- What impact (if any) will there be on existing users?
- If we are changing behavior how will we phase out the older behavior?
- If we need special migration tools, describe them here.
- When will we remove the existing behavior?
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?
Rejected Alternatives
If there are alternative ways of accomplishing the same thing, what were they? The purpose of this section is to motivate why the design is the way it is and not some other way.