Status
Current state: Under Discussion
Discussion thread:
JIRA:
Released:
Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).
Motivation
We have 2 methods in AdminClient
for updating config, alterConfigs
and incrementalAlterConfigs
, the former has many restrictions and has been deprecated from 2.3.0. However, It's still used in ConfigCommand
to update broker config and is resulting in a bug
, so I'm inclined to move it to incrementalAlterConfigs
and provide a flag to still use alterConfigs
for new client to interact with old servers. There are some other reasons for this change:
alterConfigs
has been deprecated and will be removed in a future release;- we are using
incrementalAlterConfigs
to change user/topic/client-metrics configs, it would be benefit to unify broker configs. incrementalAlterConfigs
is more convenient especially for updating configs of list data type, such as "leader.replication.throttled.replicas"
Public Interfaces
kafka-configs.sh
- add new options --disable-incremental , which is used for new client to connect to older servers before 2.3.0.
Proposed Changes
Use incrementalAlterConfigs
without --disable-incremental flag when alter broker configs, which will fail if the broker is before 2.3.0.
here is an example of changing the broker configs twice, log.cleaner.threads=2
Compatibility, Deprecation, and Migration Plan
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?
Documentation Plan
What will the impact be on the documentation? List any affected areas/files.
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.