On Wed, Jun 26, 2024, at 13:16, Jun Rao wrote: > Hi, Colin, > > Thanks for the reply. > > 1. https://kafka.apache.org/protocol.html#The_Messages_ConsumerGroupDescribe > lists ConsumerGroupDescribeRequest, whose latest version is unstable. >
Hi Jun, I think that is a bug. > > 4. "As devlopers, they can change the code to do this if they want." > Just to be clear. A developer could be able to test unstable MV/RPCs by > enabling unstable.features.enable in a real cluster, right? A developer could modify the code to allow unstable features outside of JUnit, and then run whatever they want. > > "But I think it's important that this should NOT work in our actual Kafka > releases" > Are you saying unstable MV/RPCs can't be enabled in Kafka releases with > unstable.features.enable set to true? How do we plan to enforce that? > We can just unset the configuration key in KafkaRaftServer.scala, which is not used by JUnit, but which is used by the normal broker and controller startup processes. best, Colin > Jun > > On Wed, Jun 26, 2024 at 12:52 PM Colin McCabe <cmcc...@apache.org> wrote: > >> On Wed, Jun 26, 2024, at 12:09, Jun Rao wrote: >> > Hi, Colin, >> > >> > Thanks for restarting the discussion. A few comments. >> > >> > 1. "An unstable RPC version can be changed at any time, until it becomes >> > stable." >> > >> > What's our recommendation to non-java developers? Should they start >> > building a new version of an RPC until it is stable? >> > >> >> Hi Jun, >> >> Non-Java developers will always be using only stable APIs. Unstable APIs >> are only available to JUnit tests (that run inside the JUnit JVM). >> >> > Should we explicitly mark unstable versions of PRC in >> > https://kafka.apache.org/protocol.html? Currently, it's not clear which >> > versions are unstable. >> > >> >> Hmm, I don't think the unstable APIs should be documented at all in our >> public docs. Since they're just "possibilities for the future" that haven't >> actually been released. >> >> > 2. enable.unstable.features: Our current convention is to put enable in >> the >> > suffix in config names. >> > >> >> OK. I changed it to "unstable.features.enable" >> >> > 3. It would be useful to explicitly mention the removal of the following >> > two configs in the public interfaces section. >> > unstable.api.versions.enable >> > unstable.feature.versions.enable >> > >> >> OK. I added this to that section. >> >> > 4. "Clusters can be created with unstable MVs, but only in JUnit tests." >> > Hmm, we should allow developers to test unstable MVs in a real cluster, >> > right? >> > >> >> As devlopers, they can change the code to do this if they want. But I >> think it's important that this should NOT work in our actual Kafka >> releases, to avoid blurring the lines between released features and >> unreleased ones. >> >> > 5. "This also implies that if there are no stable MVs for a release, >> > parsing will fail." >> > So for every release, we need to have at least one stable MV in that >> > release number (e.g 3.8)? It would be useful to document that. >> >> I added a note that "prior to a release, all metadata versions for that >> release must be stable." >> >> best, >> Colin >> >> >> > >> > Jun >> > >> > >> > On Tue, Jun 25, 2024 at 3:39 PM Colin McCabe <cmcc...@apache.org> wrote: >> > >> >> Hi all, >> >> >> >> We previously discussed this KIP for documenting how we deal with >> unstable >> >> MetadataVersions. At that time, we didn't bring it to a vote. >> >> >> >> Proven handed this off to me, and I've made some changes to the proposal >> >> since then: >> >> >> >> - I expanded the scope to also cover "RPCs with latestVersionUnstable" >> >> >> >> - I expanded the scope to cover other unstable KIP-584 features >> >> (MetadataVersion is just one KIP-584 feature, after all) >> >> >> >> - Made a single configuration cover all of the above. Since it's silly >> to >> >> enable an unstable MV, but have it fail because you have not also set >> some >> >> other configurations to get unstable things. >> >> >> >> - Clarified that unstable features will be usable only from JUnit, >> nowhere >> >> else >> >> >> >> - Added a "rejected alternatives" section >> >> >> >> - Clarified that there is no need to "reserve" previously used but no >> >> longer extant unstable features, MVs, or RPCs. >> >> >> >> Please take a look. >> >> >> >> best, >> >> Colin >> >> >>
