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: jira-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to