Hi Kevin, Thanks for the KIP.
4. How about using a new metric type to collect all feature metrics? So we don’t need to have different metric names in controller and broker. For example: * kafka.server:type=FeatureMetrics,name=FinalizedLevel,featureName=X * kafka.server:type=FeatureMetrics,name=MinimumSupportedLevel,featureName=X * kafka.server:type=FeatureMetrics,name=MaximumSupportedLevel,featureName=X PY_0: The rejected alternative regarding `kafka-feature describe` is KIP-1160. However, we haven’t started voting KIP-1160 yet, so it’s not been rejected. Could you change the title to “Alternatives” and link to KIP-1160? Thank you. Regards, PoAn > On May 14, 2025, at 1:52 AM, Jun Rao <j...@confluent.io.INVALID> wrote: > > Hi, Kevin, > > Thanks for the reply. > > 4. There seems to be some inconsistency. For MinimumSupportedLevel, we have > two metrics, one with the package kafka.controller and another with > kafka.server. For FinalizedLevel, we only have one metric with the package > kafka.server. Could we choose a more consistent convention? > 5. If you are following the existing usage, this is fine. > > Jun > > On Tue, May 13, 2025 at 6:57 AM Kevin Wu <kevin.wu2...@gmail.com> wrote: > >> Hey Jun, >> >> Thanks for the comments: >> 4. Maybe I'm missing something, but I think the MetadataLoader is used by >> both the broker and controller, so having the one metric works for both >> node types. The CurrentMetadataVersion metric is currently reported on both >> the broker and controller. >> 5. What is the best naming practice for additional metrics being added to >> existing metrics groups? I'm following the naming convention that is >> already in place for these existing metrics objects (MetadataLoaderMetrics >> and BrokerServerMetrics), where the former is camel case and the latter is >> kebab case. >> >> Best, >> Kevin Wu >> >> On Mon, May 12, 2025 at 9:05 AM Kevin Wu <kevin.wu2...@gmail.com> wrote: >> >>> Hey Chia-Ping and Justine, >>> >>> Okay, that makes sense about the minimum version changing at some point. >>> I'll add these metrics to this KIP. Thanks for the insightful discussion. >>> >>> Best, >>> Kevin Wu >>> >>> On Fri, May 9, 2025 at 4:54 PM Kevin Wu <kevin.wu2...@gmail.com> wrote: >>> >>>> Hey Chia-Ping and Justine, >>>> >>>> Thanks for the explanation. I see where y'all are coming from, but I >> want >>>> to make sure I understand how the value of this metric would change. >>>> >>>> It seems to me that the supported feature range is determined by the >>>> software version, so this metric's value should only change when a >> software >>>> upgrade/downgrade occurs. Otherwise, the range should not change. Is >> that >>>> correct? >>>> >>>> Also, if we want to add this metric, we would just have one additional >>>> metric per feature right, which would be the maximum feature level >>>> supported, since the minimum is always 0? >>>> >>>> Thanks, >>>> Kevin >>>> >>>> On Thu, May 8, 2025 at 6:06 PM Kevin Wu <kevin.wu2...@gmail.com> wrote: >>>> >>>>> Hey Chia-Ping, >>>>> >>>>> I hadn't considered adding the supported versions for each feature as a >>>>> metric, but I'm not sure if it's helpful for monitoring the progress >> of an >>>>> upgrade/downgrade of a feature. For example, if a node doesn't support >> a >>>>> particular feature level we're upgrading to, we shouldn't even be >> allowed >>>>> to run the upgrade right? I think that's the case for kraft.version >> (which >>>>> might be a special case), but I'm not sure about the other features. >> The >>>>> use case for exposing the finalized feature level is that monitoring it >>>>> across all nodes tells the operator that an upgrade/downgrade of the >>>>> feature was completed on every node. >>>>> >>>>> Best, >>>>> Kevin Wu >>>>> >>>>> On Thu, May 8, 2025 at 9:04 AM Kevin Wu <kevin.wu2...@gmail.com> >> wrote: >>>>> >>>>>> Hey Jun, >>>>>> >>>>>> Thanks for the comments. >>>>>> 1. I'll update the KIP. My trunk is a bit stale. >>>>>> 2. Yeah, the metric should report the finalized feature level for the >>>>>> feature. And if it is not set, the metric will report 0. >>>>>> 3. I'll update the KIP with a timeline. >>>>>> >>>>>> Thanks, >>>>>> Kevin >>>>>> >>>>>> On Wed, May 7, 2025 at 3:10 PM Kevin Wu <kevin.wu2...@gmail.com> >> wrote: >>>>>> >>>>>>> Hey Jose, >>>>>>> >>>>>>> Thanks for the response. Yeah, the new metric should expose >>>>>>> metadata.version as well. Let me update the KIP to reflect that. >>>>>>> >>>>>>> Thanks, >>>>>>> Kevin Wu >>>>>>> >>>>>>> On Wed, May 7, 2025 at 2:54 PM Kevin Wu <kevin.wu2...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Hello all, >>>>>>>> >>>>>>>> I wrote a KIP to add a generic feature level metric. >>>>>>>> Here's the link: >>>>>>>> >> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1180%3A+Add+a+generic+feature+level+metric >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Kevin Wu >>>>>>>> >>>>>>>> >>>>>>>> >>
