Hide TSDB block ranges period config from doc and mark it experimental

[pracucci]

What this PR does

From time to time I see some people from OSS community changing TSDB block ranges period. I think we're not ready for that, given whenever we design features and default config we only think about the TSDB 2h block ranges period. This option was configurable only for testing purposes (e.g. we use it in integration tests) but in my opinion shouldn't be changed (at least I would love that we officially not support any value different than 2h).

For this reason, I'm proposing to hide it from the doc.

I know this PR is controversial, but I genuinely believe that doing so we do a step forward to help OSS community not shooting to their feet (cause if you change it you need to understand how things work internally and which other config options to change accordingly).

Thoughts?

Which issue(s) this PR fixes or relates to

N/A

Checklist

• Tests updated
• Documentation added
• CHANGELOG.md updated - the order of entries should be [CHANGE], [FEATURE], [ENHANCEMENT], [BUGFIX]

[pstibrany]

💯 Agree. If it wasn't a breaking change, I'd remove the option as well.

[replay]

I think hiding it is one possible solution, although it could be interpreted as a bug in the docs... I just wanted to propose one potential alternative solution which doesn't require hiding it which I already mentioned when we met recently:

We could add an unsafe flag to the configuration, for a user to tune certain flags like the block ranges period they would have to also specify unsafe: true because otherwise Mimir would exit with an error. The down-side of this solution is that users who are upgrading with an existing config that already tunes the block ranges period would then end up with a Mimir that doesn't start anymore after the upgrade. Later we might want to put more "dangerous" flags behind the unsafe.

[krajorama]

+1 I'm always in favor of less configuration to worry about.

To fix the high disk utilization use case, I'd rather we shipped blocks at 80% disk capacity (or two hours, whichever comes first) . And if we don't test something , then it doesn't exists, so we should make the current option unsafe or remove it.

[osg-grafana]

I think hiding it is one possible solution, although it could be interpreted as a bug in the docs...

This is sometimes a strategy to force a happy path, and at other times it is indicative of a deeper issue. Documentation is a tool of discovery in this case. How close can we fix x at its core? I will not block this PR whatever you all decide, but encourage a more root-cause fix.

[osg-grafana]

Unblocking and leaning on engineering to make a decision wrt ease of use

[osg-grafana]

Do any of these references need to be updated or removed: https://github.com/grafana/mimir/search?l=Markdown&q=TSDB+block+ranges

[jhesketh]

Makes sense to me

[pracucci]

Do any of these references need to be updated or removed: https://github.com/grafana/mimir/search?l=Markdown&q=TSDB+block+ranges

Good point @osg-grafana ! I spot this: 40a4dd4

[pracucci]

Merging until we have a better way to deal with it (see #3528).