Hi Ismael, I debated including something about feature flags in my last comment, but maybe I should have. What you said makes sense.
Justine On Fri, Jan 12, 2024 at 9:31 AM Ismael Juma <m...@ismaeljuma.com> wrote: > Justine, > > For features that are not production-ready, they should have an additional > configuration (not the metadata version) that enables/disables it. The MV > specific features we ship are something we have to support and make sure we > don't break going forward. > > Ismael > > On Fri, Jan 12, 2024 at 9:26 AM Justine Olshan > <jols...@confluent.io.invalid> > wrote: > > > Hi Ismael, > > > > I think the concern I have about a MV for a feature that is not > production > > ready is that it blocks any development/features with higher MV versions > > that could be production ready. > > > > I do see your point though. Previously MV/IBP was about pure broker > > compatibility and not about the confidence in the feature it is gating. I > > do wonder though if it could be useful to have that sort of gating. > > I also wonder if an internal config could be useful so that the average > > user doesn't have to worry about the complexities of unstable metadata > > versions (and their risks). > > > > I am ok with options 2 and 2 as well by the way. > > > > Justine > > > > On Fri, Jan 12, 2024 at 7:36 AM Ismael Juma <m...@ismaeljuma.com> wrote: > > > > > Hi, > > > > > > Thanks for the KIP. > > > > > > Reading the discussion, I think a lot of the confusion is due to the > > > "unstable" naming. People are then trying to figure out when we think > > > something is stable in the "this is battle-tested" sense. But this flag > > > should not be about that. We can have an MV for a feature that is not > yet > > > production-ready (and we did that when KRaft itself was not production > > > ready). I think this flag is about metadata versions that are basically > > > unsupported - if you use it, you get to keep the pieces. They exist > > solely > > > to make the lives of Apache Kafka developers easier. I would even > suggest > > > that the config we introduce be of the internal variety, ie it won't > show > > > in the generated documentation and there won't be any compatibility > > > guarantee. > > > > > > Thoughts? > > > > > > Ismael > > > > > > On Fri, Jan 5, 2024 at 7:33 AM Proven Provenzano > > > <pprovenz...@confluent.io.invalid> wrote: > > > > > > > Hey folks, > > > > > > > > I am starting a discussion thread for managing unstable metadata > > versions > > > > in Apache Kafka. > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1014%3A+Managing+Unstable+Metadata+Versions+in+Apache+Kafka > > > > > > > > This KIP is actually already implemented in 3.7 with PR > > > > https://github.com/apache/kafka/pull/14860. > > > > I have created this KIP to explain the motivation and how managing > > > Metadata > > > > Versions is expected to work. > > > > Comments are greatly appreciated as this process can always be > > improved. > > > > > > > > -- > > > > --Proven > > > > > > > > > >
