Hmm, I thought I had added that already. I guess I missed it. Sorry for the confusion, and thanks for the update.
best, Colin On Tue, Jul 30, 2024, at 15:06, Jun Rao wrote: > Thanks for updating the KIP, Justine. > > Jun > > On Tue, Jul 30, 2024 at 1:37 PM Justine Olshan <jols...@confluent.io.invalid> > wrote: > >> I added this update to the end of the section Colin added. >> >> Justine >> >> On Tue, Jul 30, 2024 at 11:01 AM Jun Rao <j...@confluent.io.invalid> wrote: >> >> > Hi, Colin, >> > >> > Thanks for the update. We also excluded supported features with >> maxVersion >> > of 0 from both ApiVersionResponse and BrokerRegistrationRequest, and >> > excluded finalized features with version of 0 from ApiVersionResponse. It >> > would be useful to document those too. >> > >> > Jun >> > >> > On Mon, Jul 29, 2024 at 9:25 PM Colin McCabe <cmcc...@apache.org> wrote: >> > >> > > Hi Jun, >> > > >> > > Just to close the loop on this... the KIP now mentions both >> > > ApiVersionResponse and BrokerRegistrationRequest. >> > > >> > > best, >> > > Colin >> > > >> > > On Mon, Jul 8, 2024, at 14:57, Jun Rao wrote: >> > > > Hi, Colin, >> > > > >> > > > Thanks for the update. Since the PR also introduces a new version of >> > > > BrokerRegistrationRequest, could we include that change in the KIP >> > update >> > > > too? >> > > > >> > > > Jun >> > > > >> > > > On Mon, Jul 8, 2024 at 11:08 AM Colin McCabe <cmcc...@apache.org> >> > wrote: >> > > > >> > > >> Hi all, >> > > >> >> > > >> I've updated the approach in >> > https://github.com/apache/kafka/pull/16421 >> > > >> so that we change the minVersion=0 to minVersion=1 in older >> > > >> ApiVersionsResponses. >> > > >> >> > > >> I hope we can get this in soon and unblock the features that are >> > waiting >> > > >> for it! >> > > >> >> > > >> best, >> > > >> Colin >> > > >> >> > > >> On Wed, Jul 3, 2024, at 10:55, Jun Rao wrote: >> > > >> > Hi, David, >> > > >> > >> > > >> > Thanks for the reply. In the common case, there is no difference >> > > between >> > > >> > omitting just v0 of the feature or omitting the feature >> completely. >> > > It's >> > > >> > just when an old client is used, there is some difference. To me, >> > > >> > omitting just v0 of the feature seems slightly better for the old >> > > client. >> > > >> > >> > > >> > Jun >> > > >> > >> > > >> > On Wed, Jul 3, 2024 at 9:45 AM David Jacot >> > > <dja...@confluent.io.invalid> >> > > >> > wrote: >> > > >> > >> > > >> >> Hi Jun, Colin, >> > > >> >> >> > > >> >> Thanks for your replies. >> > > >> >> >> > > >> >> If the FeatureCommand relies on version 0 too, my suggestion does >> > not >> > > >> work. >> > > >> >> Omitting the features for old clients as suggested by Colin seems >> > > fine >> > > >> for >> > > >> >> me. In practice, administrators will usually use a version of >> > > >> >> FeatureCommand matching the cluster version so the impact is not >> > too >> > > bad >> > > >> >> knowing that the first features will be introduced from 3.9 on. >> > > >> >> >> > > >> >> Best, >> > > >> >> David >> > > >> >> >> > > >> >> On Tue, Jul 2, 2024 at 2:15 AM Colin McCabe <cmcc...@apache.org> >> > > wrote: >> > > >> >> >> > > >> >> > Hi David, >> > > >> >> > >> > > >> >> > In the ApiVersionsResponse, we really don't have an easy way of >> > > >> mapping >> > > >> >> > finalizedVersion = 1 to "off" in older releases such as 3.7.0. >> > For >> > > >> >> example, >> > > >> >> > if a 3.9.0 broker advertises that it has finalized >> group.version >> > = >> > > 1, >> > > >> >> that >> > > >> >> > will be treated by 3.7.0 as a brand new feature, not as >> "KIP-848 >> > is >> > > >> off." >> > > >> >> > However, I suppose we could work around this by not setting a >> > > >> >> > finalizedVersion at all for group.version (or any other >> feature) >> > if >> > > >> its >> > > >> >> > finalized level was 1. We could also work around the "deletion >> = >> > > set >> > > >> to >> > > >> >> 0" >> > > >> >> > issue on the server side. The server can translate requests to >> > set >> > > the >> > > >> >> > finalized level to 0, into requests to set it to 1. >> > > >> >> > >> > > >> >> > So maybe this solution is worth considering, although it's >> > > >> unfortunate to >> > > >> >> > lose 0. I suppose we'd have to special case metadata.version >> > being >> > > >> set to >> > > >> >> > 1, since that was NOT equivalent to it being "off" >> > > >> >> > >> > > >> >> > best, >> > > >> >> > Colin >> > > >> >> > >> > > >> >> > >> > > >> >> > On Mon, Jul 1, 2024, at 10:11, Jun Rao wrote: >> > > >> >> > > Hi, David, >> > > >> >> > > >> > > >> >> > > Yes, that's another option. It probably has its own >> challenges. >> > > For >> > > >> >> > > example, the FeatureCommand tool currently treats disabling a >> > > >> feature >> > > >> >> as >> > > >> >> > > setting the version to 0. It would be useful to get Jose's >> > > opinion >> > > >> on >> > > >> >> > this >> > > >> >> > > since he introduced version 0 in the kraft.version feature. >> > > >> >> > > >> > > >> >> > > Thanks, >> > > >> >> > > >> > > >> >> > > Jun >> > > >> >> > > >> > > >> >> > > On Sun, Jun 30, 2024 at 11:48 PM David Jacot >> > > >> >> <dja...@confluent.io.invalid >> > > >> >> > > >> > > >> >> > > wrote: >> > > >> >> > > >> > > >> >> > >> Hi Jun, Colin, >> > > >> >> > >> >> > > >> >> > >> Have we considered sticking with the range going from >> version >> > 1 >> > > to >> > > >> N >> > > >> >> > where >> > > >> >> > >> version 1 would be the equivalent of "disabled"? In the >> > > >> group.version >> > > >> >> > case, >> > > >> >> > >> we could introduce group.version=1 that does basically >> nothing >> > > and >> > > >> >> > >> group.version=2 that enables the new protocol. I suppose >> that >> > we >> > > >> could >> > > >> >> > do >> > > >> >> > >> the same for the other features. I agree that it is less >> > elegant >> > > >> but >> > > >> >> it >> > > >> >> > >> would avoid all the backward compatibility issues. >> > > >> >> > >> >> > > >> >> > >> Best, >> > > >> >> > >> David >> > > >> >> > >> >> > > >> >> > >> On Fri, Jun 28, 2024 at 6:02 PM Jun Rao >> > > <j...@confluent.io.invalid> >> > > >> >> > wrote: >> > > >> >> > >> >> > > >> >> > >> > Hi, Colin, >> > > >> >> > >> > >> > > >> >> > >> > Yes, #3 is the scenario that I was thinking about. >> > > >> >> > >> > >> > > >> >> > >> > In either approach, there will be some information missing >> > in >> > > the >> > > >> >> old >> > > >> >> > >> > client. It seems that we should just pick the one that's >> > less >> > > >> wrong. >> > > >> >> > In >> > > >> >> > >> the >> > > >> >> > >> > more common case when a feature is finalized on the >> server, >> > > >> >> > presenting a >> > > >> >> > >> > supported feature with a range of 1-1 seems less wrong >> than >> > > >> omitting >> > > >> >> > it >> > > >> >> > >> in >> > > >> >> > >> > the output of "kafka-features describe". >> > > >> >> > >> > >> > > >> >> > >> > Thanks, >> > > >> >> > >> > >> > > >> >> > >> > Jun >> > > >> >> > >> > >> > > >> >> > >> > On Thu, Jun 27, 2024 at 9:52 PM Colin McCabe < >> > > cmcc...@apache.org >> > > >> > >> > > >> >> > wrote: >> > > >> >> > >> > >> > > >> >> > >> > > Hi Jun, >> > > >> >> > >> > > >> > > >> >> > >> > > This is a fair question. I think there's a few different >> > > >> scenarios >> > > >> >> > to >> > > >> >> > >> > > consider: >> > > >> >> > >> > > >> > > >> >> > >> > > 1. mixed server software versions in a single cluster >> > > >> >> > >> > > >> > > >> >> > >> > > 2. new client software + old server software >> > > >> >> > >> > > >> > > >> >> > >> > > 3. old client software + new server software >> > > >> >> > >> > > >> > > >> >> > >> > > In scenario #1 and #2, we have old (pre-3.9) server >> > > software in >> > > >> >> the >> > > >> >> > >> mix. >> > > >> >> > >> > > This old software won't support features like >> > group.version >> > > and >> > > >> >> > >> > > kraft.version. As we know, there are no features >> supported >> > > in >> > > >> 3.8 >> > > >> >> > and >> > > >> >> > >> > older >> > > >> >> > >> > > except metadata.version itself. So the fact that we >> leave >> > > out >> > > >> some >> > > >> >> > >> stuff >> > > >> >> > >> > > from the ApiVersionResponse isn't terribly significant. >> We >> > > >> weren't >> > > >> >> > >> going >> > > >> >> > >> > to >> > > >> >> > >> > > be able to enable those post-3.8 features anyway, since >> > > >> enabling a >> > > >> >> > >> > feature >> > > >> >> > >> > > requires ALL server nodes to support it. >> > > >> >> > >> > > >> > > >> >> > >> > > Scenario #3 is more interesting. With new server >> software, >> > > >> >> features >> > > >> >> > >> like >> > > >> >> > >> > > group.version and kraft.version may be enabled. But due >> to >> > > the >> > > >> >> > >> > KAFKA-17011 >> > > >> >> > >> > > bug, we cannot accurately communicate the supported >> > feature >> > > >> range >> > > >> >> > back >> > > >> >> > >> to >> > > >> >> > >> > > the old client. >> > > >> >> > >> > > >> > > >> >> > >> > > What is the impact of this? It depends on what the >> client >> > > is. >> > > >> >> Today, >> > > >> >> > >> the >> > > >> >> > >> > > only client that cares about feature versions is admin >> > > client, >> > > >> >> which >> > > >> >> > >> can >> > > >> >> > >> > > surface them through the Admin.describeFeatures API. So >> if >> > > we >> > > >> omit >> > > >> >> > the >> > > >> >> > >> > > supported feature range, admi client won't report it. If >> > we >> > > >> fudge >> > > >> >> > it by >> > > >> >> > >> > > reporting it as 1-1 instead of 0-1, admin client will >> > report >> > > >> the >> > > >> >> > fudged >> > > >> >> > >> > > version. >> > > >> >> > >> > > >> > > >> >> > >> > > In theory, there could be other clients looking at the >> > > >> supported >> > > >> >> > >> feature >> > > >> >> > >> > > ranges later, but I guess those will be post-3.8, if >> they >> > > ever >> > > >> >> > exist, >> > > >> >> > >> and >> > > >> >> > >> > > so not subject to this problem. >> > > >> >> > >> > > >> > > >> >> > >> > > AdminClient returns a separate map for "supported >> > features" >> > > and >> > > >> >> > >> > "finalized >> > > >> >> > >> > > features." So leaving out the supported versions for >> > > >> group.version >> > > >> >> > and >> > > >> >> > >> > > kraft.version will not prevent the client from returning >> > the >> > > >> >> > finalized >> > > >> >> > >> > > versions of those features to the old client. >> > > >> >> > >> > > >> > > >> >> > >> > > So basically we have a choice between missing >> information >> > in >> > > >> >> > >> > > Admin.describeFeatures and wrong information. I would >> lean >> > > >> towards >> > > >> >> > the >> > > >> >> > >> > > missing information path, but I guess we should try out >> an >> > > old >> > > >> >> > build of >> > > >> >> > >> > > kafka-features.sh against a server with one of the new >> > > features >> > > >> >> > >> enabled, >> > > >> >> > >> > to >> > > >> >> > >> > > make sure it looks the way we want. >> > > >> >> > >> > > >> > > >> >> > >> > > best, >> > > >> >> > >> > > Colin >> > > >> >> > >> > > >> > > >> >> > >> > > >> > > >> >> > >> > > On Thu, Jun 27, 2024, at 14:01, Jun Rao wrote: >> > > >> >> > >> > > > Hi, Colin, >> > > >> >> > >> > > > >> > > >> >> > >> > > > ApiVersionResponse includes both supported and >> finalized >> > > >> >> > features. If >> > > >> >> > >> > we >> > > >> >> > >> > > > only suppress features in the supported field, but not >> > in >> > > the >> > > >> >> > >> finalized >> > > >> >> > >> > > > field, it can potentially lead to inconsistency in the >> > > older >> > > >> >> > client. >> > > >> >> > >> > For >> > > >> >> > >> > > > example, if a future feature supporting V0 is >> finalized >> > in >> > > >> the >> > > >> >> > >> broker, >> > > >> >> > >> > an >> > > >> >> > >> > > > old client issuing V3 of ApiVersionRequest will see >> the >> > > >> feature >> > > >> >> in >> > > >> >> > >> the >> > > >> >> > >> > > > finalized field, but not in the supported field. >> > > >> >> > >> > > > >> > > >> >> > >> > > > An alternative approach is to still include all >> features >> > > in >> > > >> the >> > > >> >> > >> > supported >> > > >> >> > >> > > > field, but replace minVersion of 0 with 1. This may >> > still >> > > >> lead >> > > >> >> to >> > > >> >> > >> > > > inconsistency if a future feature is finalized at >> > version >> > > 0. >> > > >> >> > However, >> > > >> >> > >> > > since >> > > >> >> > >> > > > downgrading is less frequent than upgrading, this >> > approach >> > > >> seems >> > > >> >> > >> > slightly >> > > >> >> > >> > > > more consistent. >> > > >> >> > >> > > > >> > > >> >> > >> > > > No matter what approach we take, it would be useful to >> > > >> document >> > > >> >> > this >> > > >> >> > >> > > > inconsistency to the old client. >> > > >> >> > >> > > > >> > > >> >> > >> > > > Thanks, >> > > >> >> > >> > > > >> > > >> >> > >> > > > Jun >> > > >> >> > >> > > > >> > > >> >> > >> > > > On Wed, Jun 26, 2024 at 1:18 PM Jun Rao < >> > j...@confluent.io >> > > > >> > > >> >> wrote: >> > > >> >> > >> > > > >> > > >> >> > >> > > >> Thanks for the reply, Justine and Colin. Sounds good >> to >> > > me. >> > > >> >> > >> > > >> >> > > >> >> > >> > > >> Jun >> > > >> >> > >> > > >> >> > > >> >> > >> > > >> On Wed, Jun 26, 2024 at 12:54 PM Colin McCabe < >> > > >> >> > cmcc...@apache.org> >> > > >> >> > >> > > wrote: >> > > >> >> > >> > > >> >> > > >> >> > >> > > >>> Hi Justine, >> > > >> >> > >> > > >>> >> > > >> >> > >> > > >>> Yes, that was what I was thinking. >> > > >> >> > >> > > >>> >> > > >> >> > >> > > >>> best, >> > > >> >> > >> > > >>> Colin >> > > >> >> > >> > > >>> >> > > >> >> > >> > > >>> On Mon, Jun 24, 2024, at 11:11, Justine Olshan >> wrote: >> > > >> >> > >> > > >>> > My understanding is that the tools that don't rely >> > on >> > > >> >> > ApiVersions >> > > >> >> > >> > > should >> > > >> >> > >> > > >>> > still return 0s when it is the correct value. I >> > > believe >> > > >> >> these >> > > >> >> > >> > > commands >> > > >> >> > >> > > >>> do >> > > >> >> > >> > > >>> > not require this API and thus can show 0 as >> > versions. >> > > >> >> > >> > > >>> > >> > > >> >> > >> > > >>> > Likewise, when the old ApiVersionsRequest is used >> to >> > > >> >> describe >> > > >> >> > >> > > features, >> > > >> >> > >> > > >>> we >> > > >> >> > >> > > >>> > can't return 0 versions and we won't be able to >> see >> > > group >> > > >> >> > version >> > > >> >> > >> > > set. >> > > >> >> > >> > > >>> > However, the new api will return 0 and the group >> > > version >> > > >> >> > >> correctly. >> > > >> >> > >> > > >>> > >> > > >> >> > >> > > >>> > Let me know if this is consistent with your >> > thoughts, >> > > >> Colin. >> > > >> >> > >> > > >>> > >> > > >> >> > >> > > >>> > Justine >> > > >> >> > >> > > >>> > >> > > >> >> > >> > > >>> > On Mon, Jun 24, 2024 at 10:44 AM Jun Rao >> > > >> >> > >> <j...@confluent.io.invalid >> > > >> >> > >> > > >> > > >> >> > >> > > >>> wrote: >> > > >> >> > >> > > >>> > >> > > >> >> > >> > > >>> >> Hi, Colin, >> > > >> >> > >> > > >>> >> >> > > >> >> > >> > > >>> >> Thanks for the update. The proposed change seems >> > > >> reasonable >> > > >> >> > to >> > > >> >> > >> me. >> > > >> >> > >> > > >>> Just one >> > > >> >> > >> > > >>> >> clarification. >> > > >> >> > >> > > >>> >> >> > > >> >> > >> > > >>> >> The KIP can show version 0 of certain features >> with >> > > >> >> > >> > version-mapping >> > > >> >> > >> > > >>> >> and feature-dependencies. Will that part change? >> > For >> > > >> >> example, >> > > >> >> > >> will >> > > >> >> > >> > > the >> > > >> >> > >> > > >>> tool >> > > >> >> > >> > > >>> >> show version 0 features with --release-version >> 3.8 >> > or >> > > >> do we >> > > >> >> > >> > exclude >> > > >> >> > >> > > >>> them. >> > > >> >> > >> > > >>> >> >> > > >> >> > >> > > >>> >> bin/kafka-storage.sh version-mapping >> > > --release-version >> > > >> >> > 3.6-IV1 >> > > >> >> > >> > > >>> >> metadata.version=13 (3.6-IV1) >> > > transaction.version=0 >> > > >> >> > >> > > >>> group.version=0 >> > > >> >> > >> > > >>> >> kraft.version=0 >> > > >> >> > >> > > >>> >> >> > > >> >> > >> > > >>> >> Jun >> > > >> >> > >> > > >>> >> >> > > >> >> > >> > > >>> >> On Sat, Jun 22, 2024 at 2:19 PM José Armando >> García >> > > >> Sancio >> > > >> >> > >> > > >>> >> <jsan...@confluent.io.invalid> wrote: >> > > >> >> > >> > > >>> >> >> > > >> >> > >> > > >>> >> > Thanks for the update Colin. The changes make >> > > sense to >> > > >> >> me. >> > > >> >> > >> > > >>> >> > >> > > >> >> > >> > > >>> >> > Are you planning to update the KIP to reflect >> > this >> > > new >> > > >> >> RPC >> > > >> >> > >> > > version? >> > > >> >> > >> > > >>> It >> > > >> >> > >> > > >>> >> > would be good to document the semantics >> explained >> > > >> above >> > > >> >> in >> > > >> >> > the >> > > >> >> > >> > > KIP. >> > > >> >> > >> > > >>> >> > >> > > >> >> > >> > > >>> >> > Thanks! >> > > >> >> > >> > > >>> >> > >> > > >> >> > >> > > >>> >> > On Fri, Jun 21, 2024 at 8:22 PM Justine Olshan >> > > >> >> > >> > > >>> >> > <jols...@confluent.io.invalid> wrote: >> > > >> >> > >> > > >>> >> > > >> > > >> >> > >> > > >>> >> > > Ok makes sense. I will update my PR. >> > > >> >> > >> > > >>> >> > > >> > > >> >> > >> > > >>> >> > > On Fri, Jun 21, 2024 at 5:09 PM Colin McCabe >> < >> > > >> >> > >> > > cmcc...@apache.org> >> > > >> >> > >> > > >>> >> wrote: >> > > >> >> > >> > > >>> >> > > >> > > >> >> > >> > > >>> >> > > > I think it's better to suppress the >> response >> > in >> > > >> v3. >> > > >> >> The >> > > >> >> > >> > issue >> > > >> >> > >> > > >>> with >> > > >> >> > >> > > >>> >> > > > modifying it is that there may be scenarios >> > > where >> > > >> [1, >> > > >> >> > 1] >> > > >> >> > >> is >> > > >> >> > >> > > the >> > > >> >> > >> > > >>> >> actual >> > > >> >> > >> > > >>> >> > > > supported range, and we'd want to know >> that. >> > > But >> > > >> >> > leaving >> > > >> >> > >> out >> > > >> >> > >> > > the >> > > >> >> > >> > > >>> >> > feature >> > > >> >> > >> > > >>> >> > > > should be OK for older clients (it will be >> > the >> > > >> case >> > > >> >> > with >> > > >> >> > >> > > clients >> > > >> >> > >> > > >>> old >> > > >> >> > >> > > >>> >> > enough >> > > >> >> > >> > > >>> >> > > > to send a v0, v1, or v2 ApiVersionsRequest >> > > anyway) >> > > >> >> > >> > > >>> >> > > > >> > > >> >> > >> > > >>> >> > > > best, >> > > >> >> > >> > > >>> >> > > > Colin >> > > >> >> > >> > > >>> >> > > > >> > > >> >> > >> > > >>> >> > > > On Fri, Jun 21, 2024, at 16:46, Justine >> > Olshan >> > > >> wrote: >> > > >> >> > >> > > >>> >> > > > > Thanks Colin, >> > > >> >> > >> > > >>> >> > > > > >> > > >> >> > >> > > >>> >> > > > > This makes sense to me. Namely in the >> case >> > > >> where we >> > > >> >> > >> > perhaps >> > > >> >> > >> > > >>> don't >> > > >> >> > >> > > >>> >> > want to >> > > >> >> > >> > > >>> >> > > > > support version 0 anymore, we need the >> > range >> > > to >> > > >> be >> > > >> >> > able >> > > >> >> > >> to >> > > >> >> > >> > > not >> > > >> >> > >> > > >>> >> > include 0. >> > > >> >> > >> > > >>> >> > > > > (In other words, we can't assume 0 is >> > > supported) >> > > >> >> > >> > > >>> >> > > > > It is unfortunate that this change is a >> bit >> > > >> tricky, >> > > >> >> > but >> > > >> >> > >> I >> > > >> >> > >> > > think >> > > >> >> > >> > > >>> >> it's >> > > >> >> > >> > > >>> >> > the >> > > >> >> > >> > > >>> >> > > > > best option. >> > > >> >> > >> > > >>> >> > > > > >> > > >> >> > >> > > >>> >> > > > > Can you clarify >> > > >> >> > >> > > >>> >> > > > >> The server will simply leave out the >> > > features >> > > >> >> whose >> > > >> >> > >> > minimum >> > > >> >> > >> > > >>> >> > supported >> > > >> >> > >> > > >>> >> > > > > value is 0 for clients that send v3 >> > > >> >> > >> > > >>> >> > > > > >> > > >> >> > >> > > >>> >> > > > > For 3.8, I planned to set the 0s in the >> > > >> response to >> > > >> >> > 1. >> > > >> >> > >> Is >> > > >> >> > >> > it >> > > >> >> > >> > > >>> better >> > > >> >> > >> > > >>> >> > to >> > > >> >> > >> > > >>> >> > > > > suppress the zero version features in the >> > > >> response >> > > >> >> > so we >> > > >> >> > >> > are >> > > >> >> > >> > > >>> >> > consistent >> > > >> >> > >> > > >>> >> > > > > between trunk and 3.8? >> > > >> >> > >> > > >>> >> > > > > >> > > >> >> > >> > > >>> >> > > > > Thanks, >> > > >> >> > >> > > >>> >> > > > > Justine >> > > >> >> > >> > > >>> >> > > > > >> > > >> >> > >> > > >>> >> > > > > On Fri, Jun 21, 2024 at 4:34 PM Colin >> > McCabe >> > > < >> > > >> >> > >> > > >>> cmcc...@apache.org> >> > > >> >> > >> > > >>> >> > wrote: >> > > >> >> > >> > > >>> >> > > > > >> > > >> >> > >> > > >>> >> > > > >> Hi all, >> > > >> >> > >> > > >>> >> > > > >> >> > > >> >> > >> > > >>> >> > > > >> It seems that there was a bug in older >> > > >> versions of >> > > >> >> > >> Kafka >> > > >> >> > >> > > which >> > > >> >> > >> > > >>> >> > caused >> > > >> >> > >> > > >>> >> > > > >> deserialization problems when a >> supported >> > > >> feature >> > > >> >> > range >> > > >> >> > >> > > >>> included >> > > >> >> > >> > > >>> >> 0. >> > > >> >> > >> > > >>> >> > For >> > > >> >> > >> > > >>> >> > > > >> example, the range for group.version of >> > [0, >> > > 1] >> > > >> >> would >> > > >> >> > >> be a >> > > >> >> > >> > > >>> problem >> > > >> >> > >> > > >>> >> in >> > > >> >> > >> > > >>> >> > > > this >> > > >> >> > >> > > >>> >> > > > >> situation. >> > > >> >> > >> > > >>> >> > > > >> >> > > >> >> > >> > > >>> >> > > > >> This obviously makes supportedVersions >> > kind >> > > of >> > > >> >> > useless. >> > > >> >> > >> > Any >> > > >> >> > >> > > >>> >> feature >> > > >> >> > >> > > >>> >> > that >> > > >> >> > >> > > >>> >> > > > >> doesn't exist today is effectively at v0 >> > > today >> > > >> (v0 >> > > >> >> > is >> > > >> >> > >> > > >>> equivalent >> > > >> >> > >> > > >>> >> to >> > > >> >> > >> > > >>> >> > > > "off"). >> > > >> >> > >> > > >>> >> > > > >> But if we can't declare that the server >> > > >> supports >> > > >> >> > [0, 1] >> > > >> >> > >> > or >> > > >> >> > >> > > >>> >> similar, >> > > >> >> > >> > > >>> >> > we >> > > >> >> > >> > > >>> >> > > > >> can't declare that it supports the >> feature >> > > >> being >> > > >> >> > off. >> > > >> >> > >> > > >>> Therefore, >> > > >> >> > >> > > >>> >> no >> > > >> >> > >> > > >>> >> > > > rolling >> > > >> >> > >> > > >>> >> > > > >> upgrades are possible. >> > > >> >> > >> > > >>> >> > > > >> >> > > >> >> > >> > > >>> >> > > > >> We noticed this bug during the 3.8 >> release >> > > >> when we >> > > >> >> > >> > noticed >> > > >> >> > >> > > >>> >> problems >> > > >> >> > >> > > >>> >> > in >> > > >> >> > >> > > >>> >> > > > >> upgrade tests. As an addendum to >> KIP-1022, >> > > >> we're >> > > >> >> > adding >> > > >> >> > >> > the >> > > >> >> > >> > > >>> >> > following >> > > >> >> > >> > > >>> >> > > > >> solution: >> > > >> >> > >> > > >>> >> > > > >> >> > > >> >> > >> > > >>> >> > > > >> - There will be a new v4 for >> > > ApiVersionsRequest >> > > >> >> > >> > > >>> >> > > > >> >> > > >> >> > >> > > >>> >> > > > >> - Clients that sent v4 will promise to >> > > >> correctly >> > > >> >> > handle >> > > >> >> > >> > > ranges >> > > >> >> > >> > > >>> >> that >> > > >> >> > >> > > >>> >> > > > start >> > > >> >> > >> > > >>> >> > > > >> with 0, such as [0, 1] >> > > >> >> > >> > > >>> >> > > > >> >> > > >> >> > >> > > >>> >> > > > >> - The server will simply leave out the >> > > features >> > > >> >> > whose >> > > >> >> > >> > > minimum >> > > >> >> > >> > > >>> >> > supported >> > > >> >> > >> > > >>> >> > > > >> value is 0 for clients that send v3 >> > > >> >> > >> > > >>> >> > > > >> >> > > >> >> > >> > > >>> >> > > > >> - ApiVersionsRequest v4 will be >> supported >> > > in AK >> > > >> >> 3.9 >> > > >> >> > and >> > > >> >> > >> > > >>> above. AK >> > > >> >> > >> > > >>> >> > 3.8 >> > > >> >> > >> > > >>> >> > > > will >> > > >> >> > >> > > >>> >> > > > >> ship with ApiVersionsRequest v3 just as >> > > today. >> > > >> >> > >> > > >>> >> > > > >> >> > > >> >> > >> > > >>> >> > > > >> thanks, >> > > >> >> > >> > > >>> >> > > > >> Colin >> > > >> >> > >> > > >>> >> > > > >> >> > > >> >> > >> > > >>> >> > > > >> >> > > >> >> > >> > > >>> >> > > > >> On Mon, Apr 15, 2024, at 11:01, Justine >> > > Olshan >> > > >> >> > wrote: >> > > >> >> > >> > > >>> >> > > > >> > Hey folks, >> > > >> >> > >> > > >>> >> > > > >> > >> > > >> >> > >> > > >>> >> > > > >> > Thanks everyone! I will go ahead and >> > call >> > > it. >> > > >> >> > >> > > >>> >> > > > >> > The KIP passes with the following +1 >> > > votes: >> > > >> >> > >> > > >>> >> > > > >> > >> > > >> >> > >> > > >>> >> > > > >> > - Andrew Schofield (non-binding) >> > > >> >> > >> > > >>> >> > > > >> > - David Jacot (binding) >> > > >> >> > >> > > >>> >> > > > >> > - José Armando García Sancio (binding) >> > > >> >> > >> > > >>> >> > > > >> > - Jun Rao (binding) >> > > >> >> > >> > > >>> >> > > > >> > >> > > >> >> > >> > > >>> >> > > > >> > Thanks again, >> > > >> >> > >> > > >>> >> > > > >> > Justine >> > > >> >> > >> > > >>> >> > > > >> > >> > > >> >> > >> > > >>> >> > > > >> > On Fri, Apr 12, 2024 at 11:16 AM Jun >> Rao >> > > >> >> > >> > > >>> >> <j...@confluent.io.invalid >> > > >> >> > >> > > >>> >> > > >> > > >> >> > >> > > >>> >> > > > >> wrote: >> > > >> >> > >> > > >>> >> > > > >> > >> > > >> >> > >> > > >>> >> > > > >> >> Hi, Justine, >> > > >> >> > >> > > >>> >> > > > >> >> >> > > >> >> > >> > > >>> >> > > > >> >> Thanks for the KIP. +1 >> > > >> >> > >> > > >>> >> > > > >> >> >> > > >> >> > >> > > >>> >> > > > >> >> Jun >> > > >> >> > >> > > >>> >> > > > >> >> >> > > >> >> > >> > > >>> >> > > > >> >> On Wed, Apr 10, 2024 at 9:13 AM José >> > > Armando >> > > >> >> > García >> > > >> >> > >> > > Sancio >> > > >> >> > >> > > >>> >> > > > >> >> <jsan...@confluent.io.invalid> >> wrote: >> > > >> >> > >> > > >>> >> > > > >> >> >> > > >> >> > >> > > >>> >> > > > >> >> > Hi Justine, >> > > >> >> > >> > > >>> >> > > > >> >> > >> > > >> >> > >> > > >>> >> > > > >> >> > +1 (binding) >> > > >> >> > >> > > >>> >> > > > >> >> > >> > > >> >> > >> > > >>> >> > > > >> >> > Thanks for the improvement. >> > > >> >> > >> > > >>> >> > > > >> >> > -- >> > > >> >> > >> > > >>> >> > > > >> >> > -José >> > > >> >> > >> > > >>> >> > > > >> >> > >> > > >> >> > >> > > >>> >> > > > >> >> >> > > >> >> > >> > > >>> >> > > > >> >> > > >> >> > >> > > >>> >> > > > >> > > >> >> > >> > > >>> >> > >> > > >> >> > >> > > >>> >> > >> > > >> >> > >> > > >>> >> > >> > > >> >> > >> > > >>> >> > -- >> > > >> >> > >> > > >>> >> > -José >> > > >> >> > >> > > >>> >> > >> > > >> >> > >> > > >>> >> >> > > >> >> > >> > > >>> >> > > >> >> > >> > > >> >> > > >> >> > >> > > >> > > >> >> > >> > >> > > >> >> > >> >> > > >> >> > >> > > >> >> >> > > >> >> > > >> > >>
