Hi everyone, I make some update to KIP-1022 < https://cwiki.apache.org/confluence/display/KAFKA/KIP-1022%3A+Formatting+and+Updating+Features > As part of KIP-584, brokers expose supported version ranges for features, which may include 0. Version 0 can indicate either an incomplete feature or a disabled one. However, older software versions have an issue in SupportedVersionRange that prevents handling ranges that include 0, leading to deserialization problems in ApiVersionsResponse. One approach is to modify the minimum version from 0 to 1, which passes old client validation but removes the ability to disable the feature. Another approach is to omit features with min version 0 in requests. KAFKA-17011 implements the solution of modifying the minimum version from 0 to 1 for RPC versions v0 to v3. This passes old client validation but removes the ability to disable the feature. A related issue occurs when a new broker sends a BrokerRegistrationRequest to an old controller, as the old controller does not support version 1. The solution is to omit features with version 0 in requests for versions v0 to v3. Therefore, we need to adjust the approach to resolve this dilemma. In KAFKA-17492, we omit the minimum version of 0 for RPC versions v0 to v3, allowing a 3.9 broker to join a 3.8 broker controller.
Please let me know if you have any questions or concerns regarding this approach. Thanks you, Best regard, Jiunn-Yang On 2024/04/02 18:49:50 Justine Olshan wrote: > Hi José > > I originally had each on a new line and then switched to a single line > since it looked like a lot of space. I can switch it back. > > I don't think it makes a big difference if we implement it for both tools. > Both tools will have use for it. > > I can change the name to feature-dependencies if that makes it clearer. > > I can say that we won't allow cycles, but I'm not sure the best way to > enforce this. > > I just put ">" to show output. I can change the color if that makes it > clearer. > > Justine > > On Tue, Apr 2, 2024 at 11:41 AM José Armando García Sancio > <js...@confluent.io.invalid> wrote: > > > Hi Justine, > > > > See my comments below. > > > > On Mon, Apr 1, 2024 at 4:43 PM Justine Olshan > > <jo...@confluent.io.invalid> wrote: > > > 20. I can update the KIP. > > > > I took a look at the latest KIP. > > > > * Should the output of this command "bin/kafka-features.sh > > version-mapping --release-version 3.6-IV1" be something like this: > > metadata.version=13 > > transaction.protocol.version=0 > > group.coordinator.version=0 > > kraft.version=0 > > > > I added the kraft.version to show the changes that are coming from > > KIP-853. I find this formatting much easier to parse by scripts/tools. > > They can even use Java's Properties parser if they want. > > > > * Maybe I missed the discussion but can you talk about why both > > "kafka-storage" and "kafka-features" are going to implement the > > "version-mapping" and dependencies"? I assume that it is sufficient > > for only one (kafka-features) to implement these new commands. > > > > * For the command "dependencies" in the "kafka-features" command, it > > is probably obvious that the dependencies listed are feature version > > dependencies. This is not obvious when the user uses "kafka-storage > > dependencies". This reads as the dependencies of kafka-storage. > > > > * Should we state that Kafka will not allow cycles in the feature > > version dependency definition? Meaning the user is not allowed to > > define a feature version X which depends on Y which depends on Z which > > depends on X. > > > > * Some of the example output start with the characters "> ". Will the > > CLI print those characters or is that just part of the KIP's > > formating? > > > > Thanks, > > -- > > -José > > >
