Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add flags to enable promql-at-modifier and negative offset #4026

Closed

Conversation

yeya24
Copy link
Contributor

@yeya24 yeya24 commented Apr 6, 2021

Signed-off-by: yeya24 yb532204897@gmail.com

  • I added CHANGELOG entry for this change.
  • Change is not relevant to the end user.

Changes

Fixes #4022

Verification

yeya24 added 3 commits April 6, 2021 15:14
Signed-off-by: yeya24 <yb532204897@gmail.com>
Signed-off-by: yeya24 <yb532204897@gmail.com>
Signed-off-by: yeya24 <yb532204897@gmail.com>
Copy link
Member

@bwplotka bwplotka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you! One question though.

@@ -154,6 +154,10 @@ func registerQuery(app *extkingpin.App) {
storeResponseTimeout := extkingpin.ModelDuration(cmd.Flag("store.response-timeout", "If a Store doesn't send any data in this specified duration then a Store will be ignored and partial data will be returned if it's enabled. 0 disables timeout.").Default("0ms"))
reqLogConfig := extkingpin.RegisterRequestLoggingFlags(cmd)

enableAtModifier := cmd.Flag("promql-at-modifier", "Experimental: Enable @ modifier in PromQL.").Default("false").Bool()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wonder.... Do we want those feature flags? I would be happy to have those marked as experimental but literally enabled always. Why not? 🤗

cc @brancz @kakkoyun @GiedriusS @squat ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Essentially - more flags - more complexity and confusion, so it would be best to avoid them if we can

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree. I add them as flags in this pr in order to be consistent with Prometheus.
But I don't see the reason why we need to disable them. Happy to enable them by default in the engine and remove these flags.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW i'd prefer to not enable experimental Prometheus features by default. If an experimental feature was dropped at some point, it would be a breaking change for our end users.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that's true but then you'd simply update to a newer version where they had been dropped and that's it. I would opt for fewer options here just like others have said.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that's true but then you'd simply update to a newer version where they had been dropped and that's it.

Unfortunately, that's not so easy, I think @tiagomeireles is right. The problem is that users can depend on those experimental features - they will create rules, alerts with dashboards with negative offset, At modifiers etc. If they will be gone for some reason on Prometheus we would need to either keep the broken feature and maintain on our own or drop it which will break users with those dashboards, alerts etc.

My thinking is however that as Prometheus Maintainer, I am almost certain those features will not go away, but since they are experimental there could be bugs and some modifications of behavior, so yes = breaking changes.

Thanks for reminding us @tiagomeireles.

I would propose the following:

  1. Similar to https://prometheus.io/docs/prometheus/latest/disabled_features/#disabled-features add feature flags idea.
  2. Add to all components (for now Query) --experimental-features which will be https://github.com/thanos-io/thanos/blob/main/pkg/extflag/pathorcontent.go Reason why such flag and not --enable-feature as Prometheus: There might subsequent configuration for each experimental feature, so file or content in YAML format could give us future proof flexibility. WDYT? Also we could disable or enable inside this YAML that's why I would skip enable prefix. 🤔
  3. Allow specifying those feature, and add documentation page that explains the YAML (autogenerate even)
  4. I believe we cannot enable those features by default in this case.

The benefit here is that we don't have thousands of flags. Experiments are added and dropped so it's good to have common path. We could even at some point improve this flag to be dynamically reloaded / instrumented (to show in metric which thins was enabled and when etc)

WDYT? @brancz @GiedriusS @kakkoyun @yeya24

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like to idea to have a dedicated file for experimental features and also a dedicated documentation page for it. Let's just do it.
We just need to be maybe backwards compatible and if we remove an option from the file we shouldn't fail, just let the user know that we don't have it as an experimental option anymore.

@bwplotka
Copy link
Member

Let us know if you want to create this @yeya24 or don't have time 🤗

@yeya24
Copy link
Contributor Author

yeya24 commented Apr 15, 2021

Let us know if you want to create this @yeya24 or don't have time

No sorry, I don't have time to implement the feature you mentioned.
I will close this pr and let's create a new issue to track this feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Negative offset with flag --enable-feature=promql-negative-offset
5 participants