[
https://issues.apache.org/jira/browse/KAFKA-18281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jacot updated KAFKA-18281:
--------------------------------
Fix Version/s: 4.0.0
> Kafka (3.9.0) is improperly validating non-advertised listeners for routable
> controller addresses
> -------------------------------------------------------------------------------------------------
>
> Key: KAFKA-18281
> URL: https://issues.apache.org/jira/browse/KAFKA-18281
> Project: Kafka
> Issue Type: Bug
> Affects Versions: 3.9.0
> Reporter: Justin Lee
> Assignee: PoAn Yang
> Priority: Blocker
> Fix For: 4.0.0, 3.9.1
>
>
> Kafka 3.9.0 is currently validating whether all listeners (including
> non-advertised controller listeners) are routable. Non-advertised controller
> listeners don't need to be routable.
> *Background:*
> [KIP-853 (KRaft Controller Membership
> Changes)|https://cwiki.apache.org/confluence/display/KAFKA/KIP-853%3A+KRaft+Controller+Membership+Changes]
> introduced dynamic controller quorums.
> When a cluster is configured with a dynamic controller quorum, KRaft clients
> request (via a metadata request) the currently-valid set of controller
> endpoints, which are configured on a per-controller basis via
> `advertised.listeners` (previously, controller listeners were prohibited in
> `advertised.listeners`).
> As part of [this
> work|https://github.com/confluentinc/ce-kafka/blob/78066ca74e7964bc7f9dfb0f7660814ee91ef149/core/src/main/scala/kafka/server/KafkaConfig.scala#L3445],
> Kafka added two things:
> * When a controller listener is not in `advertised.listeners`, the
> (non-advertised) controller listener from `listeners` is added to
> `effectiveAdvertisedBrokerListeners`
> * We validate that all effective advertised broker listeners are routable
> (i.e. not `0.0.0.0`)
> This is incorrect logic, because the listeners property indicates what IPs a
> listener binds on, not how clients should connect to the listener (which may
> be a static configuration that is transparent to the controller)
>
> In 3.8, both of these config combinations are valid:
> _Implicit "bind on all IP addresses"_
> {code:java}
> controller.quorum.voters=9991@localhost:9094
> listeners=BROKER://:9093,CONTROLLER://:9094
> advertised.listeners=BROKER://hostname:9093{code}
> _Explicit "bind on all addresses" (specifically, IPv4)_
> {code:java}
> controller.quorum.voters=9991@localhost:9094
> listeners=BROKER://0.0.0.0:9093,CONTROLLER://0.0.0.0:9094
> advertised.listeners=BROKER://<hostname>:9093{code}
> Formatting a controller with this configuration fails with an error like this:
> {code:java}
> broker | Exception in thread "main" java.lang.IllegalArgumentException:
> requirement failed: advertised.listeners cannot use the nonroutable
> meta-address 0.0.0.0. Use a routable IP address. at
> scala.Predef$.require(Predef.scala:337) at
> kafka.server.KafkaConfig.validateValues(KafkaConfig.scala:1022) at
> kafka.server.KafkaConfig.<init>(KafkaConfig.scala:852) at
> kafka.server.KafkaConfig.<init>(KafkaConfig.scala:184) at
> kafka.tools.StorageTool$.$anonfun$execute$1(StorageTool.scala:79) at
> scala.Option.flatMap(Option.scala:283) at
> kafka.tools.StorageTool$.execute(StorageTool.scala:79) at
> kafka.tools.StorageTool$.main(StorageTool.scala:46) at
> kafka.docker.KafkaDockerWrapper$.main(KafkaDockerWrapper.scala:48) at
> kafka.docker.KafkaDockerWrapper.main(KafkaDockerWrapper.scala) at
> [email protected]/java.lang.invoke.LambdaForm$DMH/sa346b79c.invokeStaticInit(LambdaForm$DMH)
> {code}
> In 3.9.0, the implicit configuration works, but the explicit configuration
> does not. This is a breaking change because a configuration that previously
> worked no longer works.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
