Hey folks I'm requesting again for a review on this, please. This feature will be very useful to both Loki & Mimir, and it's a relatively simple change with extensive tests.
Thanks Danny Kopping (+27) 84 941 4422 On Wed, Nov 8, 2023 at 7:03 PM Danny Kopping <[email protected]> wrote: > Thanks for the context Björn, makes sense > > Danny Kopping > (+27) 84 941 4422 > > > On Wed, Nov 8, 2023 at 6:34 PM Bjoern Rabenstein <[email protected]> > wrote: > >> On 28.10.23 04:32, Danny Kopping wrote: >> > >> > The feature is hidden behind a feature-flag, but I would argue that we >> can >> > drop the flag and simply set --rules.max-concurrent-evals=0 as default >> which >> > is functionally equivalent to not having any concurrency at all (the >> > current behaviour); double opt-in feels unnecessary. >> >> Just a high level note about feature flags: The opt-in part is only >> one reason to use a feature flag. The other is that it clearly marks a >> feature as experimental. If we just introduced >> `--rules.max-concurrent-evals`, people would inevitably use it >> assuming it's a stable feature. Now imagine that it turns out that the >> whole thing was a bad idea and we remove the feature again, those >> users would see an unexpected breaking change. >> >> -- >> Björn Rabenstein >> [PGP-ID] 0x851C3DA17D748D03 >> [email] [email protected] >> > -- 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/CAEUUdd8Xfo0w9C6MxUdk_PzASAKqj_kFZGcb8-Chv23Dbfm67w%40mail.gmail.com.
