Dear developers, TL;DR: I'd like to be able to mark feature as experimental in the documentation without feature flag.
I am bringing to your attention a discussion we're having in github issue https://github.com/prometheus/prometheus/pull/9248. That github issue is about having atan2 support in Prometheus as a binary operator. Because it is strange for users to have atan written as foo atan2 bar, instead of atan2(foo, bar), I've asked to mark the feature as experimental. Should we in the future add syntactic sugar or add binary ops to functions, we would be able to do so. I also did not want a feature flag for this. In my vision, and that's how I acted as maintainer, feature flags should be used when: - We change an existing behaviour. => PromQL query range semantics, with @ delimiter => Expanding env variables for external labels - We introduce very risky features, that introduce additional memory / storage requirements. => Remote write receiver => Exemplars => Snapshots on shutdown => Additional scrape metrics (next to up etc) However, I am not a believer of feature-flags driven Prometheus. Feature flags have been introduced in Prometheus 2.25. Since then, we have added a few new features without feature flag: - body_size_limit in scrape configs - setting timeout and interval via relabeling. In general, I think it does not benefit users to launch Prometheus with lots of feature flags. Our users should be able to assess the risk they take by using a feature, without always requiring feature flags. Especially for relatively small features like atan2. There is no intention to drop atan2 in Prometheus 2.x anyway, just we might find a better way to call it. I try to draw a line between what's a useful feature flag, and where just marking experimental in documentation is fine. Prometheus is very conservative anyway, and I value the continuity of our features, including the "experimental" ones. Just to give you an idea, if we had a very strong feature flags policy in Prometheus, here is what it could have looked like, based on https://prometheus.io/docs/prometheus/latest/stability/#api-stability-guarantees --enable-feature=promql-at-modifier --enable-feature=expand-external-labels --enable-feature=promql-negative-offset --enable-feature=remote-write-receiver --enable-feature=exemplar-storage --enable-feature=body-size-limit --enable-feature=relabel-intervals --enable-feature=remote-read --enable-feature=https-basic-auth --enable-feature=web-ui --enable-feature=service-discovery-k8s --enable-feature=service-discovery-consul --enable-feature=remote-write-retry-on-429 --enable-feature=target-limit And that's what I want to avoid. Concretely, my proposal is to continue to be able to mark features as experimental in the documentation, without requiring feature flags. Feature flags can be introduced when some conditions are met, to the appreciation of the maintainers. In some cases (breaking changes or extra unexpected resource consumption), they are mandatory. -- Julien Pivotto @roidelapluie -- You received this message because you are subscribed to the Google Groups "Prometheus Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/20210903074429.GA24618%40hydrogen.
