Re: [DISCUSS] KIP-1014: Managing Unstable Features in Apache Kafka
Hi Colin, I agree that we try hard to avoid breaking compatibility. I am not questioning this at all. I also agree with your concern. My point was about requiring users to opt-in for a feature vs having it enabled by default during the EA and the Preview phases. With KIP-1022, the only way to use a non-default version of a feature is to set the unstable config. I think that it would be nice to have the default feature version, new stable version(s) that users could opt-in to enable during EA/Preview, and the development one(s) gated by the unstable flag. This is perhaps more a discussion for KIP-1022. Best, David On Fri, Jun 28, 2024 at 7:50 AM Chia-Ping Tsai 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. > > > > I file a jira for this (https://issues.apache.org/jira/browse/KAFKA-17051) >
Re: [DISCUSS] KIP-1014: Managing Unstable Features in Apache Kafka
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. > I file a jira for this (https://issues.apache.org/jira/browse/KAFKA-17051)
Re: [DISCUSS] KIP-1014: Managing Unstable Features in Apache Kafka
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 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 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 >> >> 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 >> >> >>
Re: [DISCUSS] KIP-1014: Managing Unstable Features in Apache Kafka
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 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 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 > >> 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
Re: [DISCUSS] KIP-1014: Managing Unstable Features in Apache Kafka
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 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 >> 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 >> wrote: >> >> > >> >> >> Hi all, >> >> >> >> >> >> We previously discussed this KIP for documenting how we deal with >> >> unstable >> >> >>
Re: [DISCUSS] KIP-1014: Managing Unstable Features in Apache Kafka
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 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 > 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 > 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
Re: [DISCUSS] KIP-1014: Managing Unstable Features in Apache Kafka
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 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 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 >> >> >>
Re: [DISCUSS] KIP-1014: Managing Unstable Features in Apache Kafka
Hi, Colin, Thanks for the reply. 1. https://kafka.apache.org/protocol.html#The_Messages_ConsumerGroupDescribe lists ConsumerGroupDescribeRequest, whose latest version is unstable. 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? "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? Jun On Wed, Jun 26, 2024 at 12:52 PM Colin McCabe 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 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 > >> >
Re: [DISCUSS] KIP-1014: Managing Unstable Features in Apache Kafka
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 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 >>
Re: [DISCUSS] KIP-1014: Managing Unstable Features in Apache Kafka
Hi Justine, Since these configurations are (and have always been) internal, changing or removing them should be no problem. best, Colin On Tue, Jun 25, 2024, at 16:51, Justine Olshan wrote: > Hey Colin, > > I made a single configuration as part of KIP-1022 called > unstableFeatureVersionsEnabled. Would we want to deprecate that and use the > more generic name? Unfortunately, the config as defined in KIP-1022 is > already in 3.8. > > Thanks for taking a look at this again. This will help with a lot of > confusion around the topic of unstable versions. > > Justine > > On Tue, Jun 25, 2024 at 3:39 PM Colin McCabe 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 >>
Re: [DISCUSS] KIP-1014: Managing Unstable Features in Apache Kafka
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? Should we explicitly mark unstable versions of PRC in https://kafka.apache.org/protocol.html? Currently, it's not clear which versions are unstable. 2. enable.unstable.features: Our current convention is to put enable in the suffix in config names. 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 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? 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. Jun On Tue, Jun 25, 2024 at 3:39 PM Colin McCabe 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 >
Re: [DISCUSS] KIP-1014: Managing Unstable Features in Apache Kafka
Hey Colin, I made a single configuration as part of KIP-1022 called unstableFeatureVersionsEnabled. Would we want to deprecate that and use the more generic name? Unfortunately, the config as defined in KIP-1022 is already in 3.8. Thanks for taking a look at this again. This will help with a lot of confusion around the topic of unstable versions. Justine On Tue, Jun 25, 2024 at 3:39 PM Colin McCabe 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 >
