Hi David, Do most people feel that it's OK to break compatibility when transitioning a feature from EA to GA? I always had the impression we tried hard to avoid doing this. But I'm curious if this is documented somewhere.
My concern about making this configuration externally useable is that people will start to rely on it, and expect compatibility guarantees that aren't there. It would also be good to understand how many EA features will need or want radical metadata changes before going GA. We did try pretty hard to avoid this in cases like JBOD... best, Colin On Thu, Jun 27, 2024, at 00:27, David Jacot wrote: > Hi all, > > I think that it would be nice to have an official way to enable > non-production-ready features in order to have a way to test them in > development/soak clusters. For instance, I would like the new consumer > protocol to be disabled by default but users should be able to enable it if > they want to test it in their environment. Diverging a bit here but for > group.version=1, it should be the default in 4.0 and it should be usable in > 3.8/3.9 by for instance setting it with `kafka-features`. I don't think > that we allow this with KIP-1022 unless the unstable/unrelease flag is set > because group.version=1 is attached to MV_4_0. > > Best, > David > > On Thu, Jun 27, 2024 at 12:50 AM Colin McCabe <cmcc...@apache.org> wrote: > >> Hi Jun, >> >> KIP-1014 is explicitly NOT for EA features, since EA features need to be >> usable by non-developers. >> >> I think it's important to be clear about this. Maybe "unreleased" would be >> a better name than "unstable" since people seem to have lots of different >> ideas about what "unstable" means, which are very different than the >> intention of this KIP. What do you think? >> >> For a developer making changes to the code, making an additional change to >> enable testing outside of JUnit should be fine. I think this is actually >> critical to making this work, since if we allow non-developers to use >> KIP-1014 features, we'll get bogged down in compatibility discussions (no >> matter what the KIP says). >> >> best, >> Colin >> >> On Wed, Jun 26, 2024, at 14:49, Jun Rao wrote: >> > Hi, Colin, >> > >> > Thanks for the reply. >> > >> > 4. "A developer could modify the code to allow unstable features outside >> of >> > JUnit, and then run whatever they want." >> > Hmm, it's inconvenient for a developer to make some temporary change just >> > to test an unstable feature outside of junit, right? >> > >> > Also, how does a user test an EA feature in a release? It's inconvenient >> > for a user to change code and recompile the binary. >> > >> > Jun >> > >> > >> > On Wed, Jun 26, 2024 at 1:38 PM Colin McCabe <cmcc...@apache.org> wrote: >> > >> >> 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 >> >> >> >> >> >> >> >> >> >>
