Hey there Jiunn-Yang, Thanks for taking the time to update the KIP. I noticed the section now has some crossed out components. I am a little confused since I think this means we originally took a certain approach, but decided against it later? Is it possible to explain we took one approach but decided against it later in words and not crossing out text? I think it will help anyone who reads this KIP in the future understand.
Thanks again, Justine On Sat, Sep 14, 2024 at 6:21 PM 黃竣陽 <s7133...@gmail.com> wrote: > 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é > > > > > >
