log.segment.bytes (segment.bytes)
log.roll.ms, log.roll.hours (segment.ms)
log.roll.jitter.ms, log.roll.jitter.hours (segment.jitter.ms)
log.index.size.max.bytes (segment.index.bytes)
log.flush.interval.messages (flush.messages)
log.flush.interval.ms (flush.ms)
log.retention.bytes (retention.bytes)
log.retention.ms, log.retention.minutes, log.retention.hours (retention.ms)
log.index.interval.bytes (index.interval.bytes)
log.cleaner.delete.retention.ms (delete.retention.ms)
log.cleaner.min.compaction.lag.ms (min.compaction.lag.ms)
log.cleaner.min.cleanable.ratio (min.cleanable.dirty.ratio)
log.cleanup.policy (cleanup.policy)
log.segment.delete.delay.ms (file.delete.delay.ms)
unclean.leader.election.enable (unclean.leader.election.enable)
min.insync.replicas (min.insync.replicas)
max.message.bytes (max.message.bytes)
compression.type (compression.type)
log.preallocate (preallocate)
log.message.format.version (message.format.version)log.message.timestamp.type (message.timestamp.type)
log.message.timestamp.difference.max.ms (message.timestamp.difference.max.ms)

Configuration updates will not be allowed for the listener used in inter-broker communication. To update inter-broker configs without restarting the broker, a new listener can be created with new configs and the inter-broker listener can be changed to the new listener (similar to the currently documented security upgrade process).

Compatibility, Deprecation, and Migration Plan

Message Format and Inter Broker Protocol

Use case: Avoid additional rolling restarts during upgrade

Config scope: Default for whole cluster (/configs/brokers/<default>)

Config options:

Dynamic update changes:

AdminClient needs to verify that all brokers in the cluster support the new version before making an update. To enable this, the version of the broker will be added to the JSON registered by each broker during startup at /brokers/ids/id

Broker configuration using a properties object or the properties file server.properties will continue to be supported. So users who do not configure dynamic broker options will not be impacted.
When downgrading from a new broker to an older version that does not support dynamic configs, any configs that were dynamically configured needs to be added to server.properties. The current configs which include dynamic configs can be obtained using kafka-configs.sh.
If a config is renamed, broker will be updated to automatically register a dynamic config with the new name that has the value of the old config, if the old config was dynamically configured. So no action is required during upgrade. It will be up to the user to delete the old config when no downgrades are expectedBroker configuration using a properties object or the properties file server.properties will continue to be supported. So users who do not configure dynamic broker options will not be impacted.

...