Yes we'll need to bump ApiVersions request/response version to 4. I have a small note in the Public Interfaces that we'll drop MinVersionLevel in ApiVersionsResponse version 4.
I believe we can avoid bumping the version of FeatureLevelRecord since KRaft doesn't support the UpgradeFeatures RPC (and so can't have written any FeatureLevelRecord). On Thu, Dec 16, 2021 at 2:48 PM Jun Rao <j...@confluent.io.invalid> wrote: > Hi, David, > > Thanks for the KIP. It seems that we removed MinVersionLevel from ZK > and FeatureLevelRecord in the latest change. Should we > remove MinVersionLevel from ApiVersionsResponse too? Should we bump up the > version in FeatureLevelRecord and ApiVersionsRequest? > > Jun > > On Thu, Dec 16, 2021 at 10:14 AM Colin McCabe <cmcc...@apache.org> wrote: > > > Thanks for the KIP, David! Great work. > > > > +1 (binding). > > > > Should the "./kafka-features.sh downgrade" command also have a --release > > flag, to match upgrade? > > > > Also, it seems like upgrade should have a --latest flag that upgrades > > everything to the latest installed version? > > > > best, > > Colin > > > > > > On Fri, Dec 10, 2021, at 12:49, David Arthur wrote: > > > Hey everyone, I'd like to start a vote for KIP-778 which adds support > for > > > KRaft to KRaft upgrades. > > > > > > Notably in this KIP is the first use case of KIP-584 feature flags. As > > > such, there are some addendums to KIP-584 included. > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-778%3A+KRaft+Upgrades > > > > > > Thanks! > > > David > > > -- -David
