[
https://issues.apache.org/jira/browse/KAFKA-17788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17889367#comment-17889367
]
Colin McCabe edited comment on KAFKA-17788 at 10/14/24 11:35 PM:
-----------------------------------------------------------------
Update:
Kafka wants to divide up all listeners into either broker listeners or
controller listeners. The sets are disjoint: a listener can't be both.
BrokerServer will try to open the ports that belong to the broker;
ControllerServer will try to open the ports that belong to the controller. You
obviously can't open the same port twice (in standard UNIX, at least) or if you
somehow did, the result would be nonsense. This isn't such a big deal on broker
or controller nodes, but it becomes a bigger deal when in "combined" mode,
where a process functions as both broker and controller.
You are getting the error message "requirement failed:
control.plane.listener.name must be a listener name defined in
advertised.listeners" because the broker is looking for a listener named
CONTROLPLANE-9090, but it already knows that this is NOT an advertised listener
for the broker, it is an advertised listener for the controller. You would get
the same error if you tried to set the inter.broker.listener or the broker
replication listener to the CONTROLLER listener.
The reason why this wasn't an issue in 3.8.0, and is in 3.9-RC2 is that in
3.8.0 and earlier, advertised.listeners was just for broker listeners. There
was never a need to put a controller listener in there because controller
listeners were statically configured by controller.quorum.voters. In fact, when
in KRaft mode, it would be a fatal configuration error to put a controller
listener into advertised.listeners. Unfortunately, we failed to enforce this
when the broker was in migration mode.
I guess for the purpose of being bug-compatible with 3.8, we could make an
exception here and force the listener specified by control.plane.listener to
appear in effectiveAdvertisedBrokerListeners. Since control plane listeners are
going away anyway, we won't have to support this exception for very long.
was (Author: cmccabe):
Kafka wants to divide up all listeners into either broker listeners or
controller listeners. The sets are disjoint: a listener can't be both.
BrokerServer will try to open the ports that belong to the broker;
ControllerServer will try to open the ports that belong to the controller. You
obviously can't open the same port twice (in standard UNIX, at least) or if you
somehow did, the result would be nonsense. This isn't such a big deal on broker
or controller nodes, but it becomes a bigger deal when in "combined" mode,
where a process functions as both broker and controller.
You are getting the error message "requirement failed:
control.plane.listener.name must be a listener name defined in
advertised.listeners" because the broker is looking for a listener named
CONTROLPLANE-9090, but it already knows that this is NOT an advertised listener
for the broker, it is an advertised listener for the controller. You would get
the same error if you tried to set the inter.broker.listener or the broker
replication listener to the CONTROLLER listener.
The reason why this wasn't an issue in 3.8.0, and is in 3.9-RC2 is that in
3.8.0 and earlier, advertised.listeners was just for broker listeners. There
was never a need to put a controller listener in there because controller
listeners were statically configured by controller.quorum.voters. In fact, when
in KRaft mode, it would be a fatal configuration error to put a controller
listener into advertised.listeners. Unfortunately, we failed to enforce this
when the broker was in migration mode.
I guess for the purpose of being bug-compatible with 3.8, we could make an
exception here and force the listener specified by control.plane.listener to
appear in effectiveAdvertisedBrokerListeners. Since control plane listeners are
going away anyway, we won't have to support this exception for very long.
> Migration fails in Kafka 3.9.0-RC2 when control plane listener is used
> ----------------------------------------------------------------------
>
> Key: KAFKA-17788
> URL: https://issues.apache.org/jira/browse/KAFKA-17788
> Project: Kafka
> Issue Type: Bug
> Affects Versions: 3.9.0
> Reporter: Jakub Scholz
> Assignee: Colin McCabe
> Priority: Blocker
> Attachments: logs-pod-cluster-9833cba6-kafka-1-container-kafka.log
>
>
> When testing migration with Kafka 3.9.0-RC2, the broker fail to start when
> they are first rolled to start the migration with the following error:
> {code}
> 2024-10-11 21:37:04,060 ERROR Exiting Kafka due to fatal exception
> (kafka.Kafka$) [main]
> java.lang.IllegalArgumentException: requirement failed:
> control.plane.listener.name must be a listener name defined in
> advertised.listeners. The valid options based on currently configured
> listeners are REPLICATION-9091,PLAIN-9092,TLS-9093
> at scala.Predef$.require(Predef.scala:337)
> at kafka.server.KafkaConfig.validateValues(KafkaConfig.scala:1019)
> at kafka.server.KafkaConfig.<init>(KafkaConfig.scala:843)
> at kafka.server.KafkaConfig.<init>(KafkaConfig.scala:185)
> at kafka.Kafka$.buildServer(Kafka.scala:71)
> at kafka.Kafka$.main(Kafka.scala:90)
> at kafka.Kafka.main(Kafka.scala)
> {code}
> This is despite our configuration having the {control.plane.listener.name}
> properly configured:
> {code}
> listener.security.protocol.map=CONTROLPLANE-9090:SSL,REPLICATION-9091:SSL,PLAIN-9092:SASL_PLAINTEXT,TLS-9093:SSL
> listeners=CONTROLPLANE-9090://0.0.0.0:9090,REPLICATION-9091://0.0.0.0:9091,PLAIN-9092://0.0.0.0:9092,TLS-9093://0.0.0.0:9093
> advertised.listeners=CONTROLPLANE-9090://cluster-9833cba6-kafka-1.cluster-9833cba6-kafka-brokers.test-suite-namespace.svc:9090,REPLICATION-9091://cluster-9833cba6-kafka-1.cluster-9833cba6-kafka-brokers.test-suite-namespace.svc:9091,PLAIN-9092://cluster-9833cba6-kafka-1.cluster-9833cba6-kafka-brokers.test-suite-namespace.svc:9092,TLS-9093://cluster-9833cba6-kafka-1.cluster-9833cba6-kafka-brokers.test-suite-namespace.svc:9093
> inter.broker.listener.name=REPLICATION-9091
> control.plane.listener.name=CONTROLPLANE-9090
> {code}
> It looks like 3.9.0-RC2 filters out the control plane listener (maybe because
> it is used by the KRaft controllers as well?) and runs into this error. This
> worked fine in 3.8.0, so this seems like a regression in 3.9.0 that should be
> fixed.
> The full log from the broker node is attached. It includes the full
> configuration of the broker as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
