KAFKA-19719 --no-initial-controllers should not assume kraft.version=…

[kevin-wu24]

…1 (#20604)

commit ec37eb538b7d7e113b80e09276606395b007127e (HEAD ->
KAFKA-19719-cherry-pick-41, origin/KAFKA-19719-cherry-pick-41)
Author: Kevin Wu <kevin.wu2412@gmail.com>
Date:   Thu Sep 25 11:56:16 2025 -0500

    KAFKA-19719: --no-initial-controllers should not assume
kraft.version=1 (#20551)

    Just because a controller node sets --no-initial-controllers flag
does     not mean it is necessarily running kraft.version=1. The more
precise     meaning is that the controller node being formatted does not
know what     kraft version the cluster should be in, and therefore it
is only safe to     assume kraft.version=0. Only by setting
--standalone,--initial-controllers, or --no-initial-controllers     AND
not specifying the controller.quorum.voters static config, is it
known kraft.version > 0.

    For example, it is a valid configuration (although confusing) to run
a     static   quorum defined by controller.quorum.voters but have all
the     controllers   format with --no-initial-controllers. In this
case,     specifying --no-initial-controllers alongside a metadata
version that     does not  support kraft.version=1 causes formatting to
fail, which is     does not  support kraft.version=1 causes formatting
to fail, which is     a  regression.

    Additionally, the formatter should not check the kraft.version
against     the release version, since kraft.version does not actually
depend on any     release version. It should only check the
kraft.version against the     static voters config/format arguments.

    This PR also cleans up the integration test framework to match the
semantics of formatting an actual cluster.

    Reviewers: TengYao Chi <kitingiao@gmail.com>, Kuan-Po Tseng
<brandboat@gmail.com>, Chia-Ping Tsai <chia7712@gmail.com>, José Armando
García Sancio <jsancio@apache.org>      Conflicts:
core/src/main/scala/kafka/tools/StorageTool.scala Minor conflicts. Keep
changes from cherry-pick.
core/src/test/java/kafka/server/ReconfigurableQuorumIntegrationTest.java
Remove auto-join tests, since 4.1 does not support it. docs/ops.html
Keep docs section from cherry-pick.
metadata/src/test/java/org/apache/kafka/metadata/storage/FormatterTest.java
Minor conflicts. Keep cherry-picked changes.
test-common/test-common-runtime/src/main/java/org/apache/kafka/common/test/KafkaClusterTestKit.java
Conflicts due to integration test framework changes. Keep new changes.

commit 02d58b176c32917962ab25b6d685059179d06f26 (upstream/4.1)

Reviewers: Chia-Ping Tsai chia7712@gmail.com
Conflicts:
core/src/test/java/kafka/server/ReconfigurableQuorumIntegrationTest.java
docs/ops.html
metadata/src/main/java/org/apache/kafka/metadata/storage/Formatter.java
metadata/src/test/java/org/apache/kafka/metadata/storage/FormatterTest.java
server-common/src/main/java/org/apache/kafka/server/common/KRaftVersion.java
test-common/test-common-runtime/src/main/java/org/apache/kafka/common/test/KafkaClusterTestKit.java
All minor conflicts. Keep cherry-picked changes.

[kevin-wu24]

Hi @chia7712, can you look at the CI items? It looks like the build compiles and passes the tests, but I'm not sure what is happening with the other tasks.

[chia7712]

Hi @chia7712, can you look at the CI items? It looks like the build compiles and passes the tests, but I'm not sure what is happening with the other tasks.

The root cause is that the ci-complete workflow is also being triggered on the 4.0 branch. Since that branch does not include KAFKA-18748, it is unable to fine the related scan reports. I will file a minor patch to disable this on the 4.0 branch, as its reports can be safely ignored.

[chia7712]

LGTM