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 > >> >> >> > >> >> > >> >
