Table of Contents |
---|
Status
Current state: Under Discussion
...
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
Jira | ||||||
---|---|---|---|---|---|---|
|
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:...
Note that I'm only changing the way we updating broker configs, user/topic/client-metrics configs are already being updated using incrementalAlterConfigs
Public Interfaces
kafka-configs.sh
- Adding new options --disable-incremental , which is used for new client to connect to older servers before 2.3.0 when updating broker configs.
Proposed Changes
- --disable-incremental is only makes sense when used together with (--alter) and (--broker <broker-id>)/(--entity-types brokers), or it will be ignored.
- --disable-incremental is only makes sense when used together with (--bootstrap-server)/(bootstrap-controller), we are leaving zookeeper case unchanged.
- use AdminClient.
incrementalAlterConfigs
without --disable-incremental flag when alter broker configs, which will fail if the broker is before 2.3.0.
...
- Use kafka-configs.sh to set log.cleaner.threads=2, the client will send it to server using AdminClient.incrementalAlterConfigs(), the broker will merge the old snapshot( {} ) with delta and save the new snapshot( {log.cleaner.threads=2} ) to metadata storage.
- Use kafka-configs.sh to set background.threads=1, the client will send it to server using AdminClient.incrementalAlterConfigs(), the broker will merge the old snapshot( {log.cleaner.threads=2} ) with delta and got the new snapshot ({log.cleaner.threads=2, background.threads=1 }) to metadata storage.
The result is expected to be the same for both way, except that we can avoid some issues for AdminClient.alterConfigs().
Compatibility, Deprecation, and Migration Plan
There will be a backward compatibility problem here since incrementalAlterConfigs
is added from 2.3.0, we add a --disable-incremental option for older client to do smooth migration.
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
...
new client tool with older server can be tested locally and using test cases.
Documentation Plan
There are some api changes and we should document about kafka-configs.sh change list
Rejected Alternatives
- We fallback to using
alterConfigs
automatically ifincrementalAlterConfigs
is not supported, we need to unify the semantics if we want to do this heuristically, so we choose to give this privilege to users by add --disable-incremental.