cmccabe commented on PR #19416:
URL: https://github.com/apache/kafka/pull/19416#issuecomment-2787916394
> Before the kraft version can be upgraded to version 1, all of the
> brokers and controllers in the cluster need to support kraft version 1.
> The check that all brokers support kraft version 1 is done by the
> FeatureControlManager. The check that all of the controllers support
> kraft version is done by KafkaRaftClient and LeaderState.
There is already code in FeatureControlManager to check that the controllers
support the correct features. It relies on the KIP-919 controller
registrations. Can we just use that?
> The kraft version is upgraded using the UpdateFeatures RPC. These RPCs
> are handled by the QuorumController and FeatureControlManager. This
> change adds special handling in the FeatureControlManager so that
> upgrades to the kraft.version are directed to
> RaftClient#upgradeKRaftVersion.
There is a problem here, which is that I don't see how we reverse this
change in the case where there is a controller failover and the changes we made
were not committed.
We also need some way of waiting for this operation to complete before
returning from the updateFeatures call.
A simple way of doing this would be to emit a NoOpRecord and wait for that
to complete.
I also would prefer to avoid coupling between FeatureControlManager and
RaftClient. It seems like we could just have an interface or something that is
implemented by a simple class that calls into RaftClient.
For example if we had something like this:
```
interface KRaftVersionAccessor {
KRaftVersion currentKRaftVersion();
void setKRaftVersion(KRaftVersion);
}
```
we could avoid the dependency by implementing this in QuorumController in
the obvious way...
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
