[
https://issues.apache.org/jira/browse/KAFKA-16538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17927987#comment-17927987
]
Krzysztof Piecuch commented on KAFKA-16538:
-------------------------------------------
I'd love to see this in 3.9.1 if possible please.
Workload/controllers migration to different nodes is a critical feature for any
software. Maybe I'm missing something, but how others can commit to running
kraft without the ability to migrate their controllers after a node fault? Yes,
you can recreate clusters but that means you need to approach the problem in a
significantly different way than you did with ZK kafka.
Another issue is the feature compatibility. The fact that "fresh 3.9.0 cluster"
has a different feature set than "cluster upgraded to 3.9.0" is quite
confusing. At minimum, I'd love to see
{code:java}
kafka-features upgrade --feature kraft.version=1{code}
throw an error. Currently, it reports success, but the following
"{color:#172b4d}kafka-metadata-quorum{color} remove controller" invocation
throws an exception that my kafka.version is 0.
I understand if my ask doesn't get accepted. Either way, this feature is
something I've been waiting for since kraft got released and I'm very happy to
see it finally implemented.
> Support UpdateFeatures for kraft.version so we can go from static quorums to
> dynamic
> ------------------------------------------------------------------------------------
>
> Key: KAFKA-16538
> URL: https://issues.apache.org/jira/browse/KAFKA-16538
> Project: Kafka
> Issue Type: Sub-task
> Reporter: José Armando García Sancio
> Assignee: José Armando García Sancio
> Priority: Major
>
> Should:
> # Route request to cluster metadata kraft client.
> # KRaft leader should check the supported version of all voters and observers
> ## voter information comes from VoterSet
> ## observer information is push down to kraft by the metadata controller
> # Persist both the kraft.version and voter set in one control batch
> We need to allow for the kraft.version to succeed while the metadata
> controller changes may fail. This is needed because there will be two batches
> for this updates. One control record batch which includes kraft.version and
> voter set, and one metadata batch which includes the feature records.
>
> This change should also improve the handling of UpdateVoter to allow the
> request when the kraft.version is 0.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
