Create v2-1.md

[09jvilla]

Draft PR for the release notes for the mimir 2.1 release. GEM 2.1 release notes to come in a separate PR.

[CLAassistant]

All committers have signed the CLA.

[09jvilla]

@pstibrany I'm not sure I'm capturing 'Mimir on ARM' correctly. Can you give me your thoughts on what I've written? I see 2 images when I go to our Dockerhub repo, which suggests that I as the user need to pick which one to use. As you described it on Slack to me, it made it sound like there was 1 image and somehow it automatically just worked on arm or x86 without the user doing anything.

@pracucci -- I wasn't 100% sure I was understanding the store-gateway attributes cache correctly.

• Am I right that it would add 6MB memory usage per store gateway component?
• Also just want to verify that the cache itself would be part of the store gateway component. I couldn't exactly confirm from the configuration flag name itself since it lives under the blocks storage hierarchy.
• Sounds like this in-memory cache would be helpful for any user, regardless of whether they are running the chunks cache or not? I thought so, but asking since the flag is under the chunks cache hierarchy, and the chunks cache itself seems off by default ('backend' is defaulted to the empty string).

cc'ing @pracucci and @johannaratliff (release shepherd) in case they want to take an initial look at the notes as a whole. On the bugfixes, I tried to focus more on fixes that were in response to problems raised by community users, but if there's another more important bug that I didn't highlight, let me know and I can swap out one of the ones we do have.

[pstibrany]

Perhaps we should point out that TSDB isolation feature (within single ingester) doesn't bring any benefit in our architecture, where single push request is distributed to many ingesters. Mimir didn't provide isolation guarantees even with this option enabled.

[09jvilla]

We sort of mention that in the linked blog post already:

TSDB isolation is a feature that wasn’t used in Mimir, due to its distributed architecture, but was introducing a significant negative impact on write latency caused by a high lock contention on TSDB isolation lock.

For the purposes of keeping the release notes concise, I'd rather keep as is and if anything, just add a bit more detail to the blog (we can ask the content team to edit the blog content even though its already been published). Sounds like you're saying that not only does tsdb isolation not provide any benefits due to our distributed architecture but it actually doesn't really even do what it says it does?

[09jvilla]

If you can give me another sentence you'd like to add to the existing blog post to clarify this, happy to get it in:
https://grafana.com/blog/2022/04/08/how-we-scaled-our-new-prometheus-tsdb-grafana-mimir-to-1-billion-active-series/#prometheus-tsdb-enhancements

[pstibrany]

What about something like this:

Suggested change

- We've changed the default for `-blocks-storage.tsdb.isolation-enabled` from `true` to `false`. We've marked this flag as deprecated and will remove it, setting the value permanently to `false`, in 2 releases. Our decision to do this came from our experience running our [1 billion series load test](https://grafana.com/blog/2022/04/08/how-we-scaled-our-new-prometheus-tsdb-grafana-mimir-to-1-billion-active-series/#prometheus-tsdb-enhancements), where we saw that disabling this setting reduced ingester 99th percentile latency by 90%.

- We've changed the default for `-blocks-storage.tsdb.isolation-enabled` from `true` to `false`. We've marked this flag as deprecated and will remove it, setting the value permanently to `false`, in 2 releases. Our decision to do this came from our experience running our [1 billion series load test](https://grafana.com/blog/2022/04/08/how-we-scaled-our-new-prometheus-tsdb-grafana-mimir-to-1-billion-active-series/#prometheus-tsdb-enhancements), where we saw that disabling this setting reduced ingester 99th percentile latency by 90%. Note that due to Mimir's architecture, Mimir doesn't benefit from TSDB isolation feature, so disabling it is a net win for Mimir.

[pstibrany]

Oh, I wouldn't add anything to the blog post, just to release notes. But if you don't think it's necessary, that's fine. You're correct that it's explained in the blog post already.

[09jvilla]

I tried again! lemme know what you think.

[pstibrany]

@pstibrany I'm not sure I'm capturing 'Mimir on ARM' correctly. Can you give me your thoughts on what I've written? I see 2 images when I go to our Dockerhub repo, which suggests that I as the user need to pick which one to use. As you described it on Slack to me, it made it sound like there was 1 image and somehow it automatically just worked on arm or x86 without the user doing anything.

If you take a look at recent weekly image, you can see two options under OS/ARCH. It means this is a multiplatform Docker image (manifest), and docker client will download the image corresponding to the system it runs on.

(For Mimir 2.0, we manually published arm64 image under a different tag, in order to avoid changing existing 2.0.0 tag)

[pracucci]

Am I right that it would add 6MB memory usage per store gateway component?

Yes.

Also just want to verify that the cache itself would be part of the store gateway component. I couldn't exactly confirm from the configuration flag name itself since it lives under the blocks storage hierarchy.

The cache is part of the store-gateway component.

Sounds like this in-memory cache would be helpful for any user, regardless of whether they are running the chunks cache or not?

Correct.

[pracucci]

Good job! Overall LGTM (modulo active comments) 👏

[pracucci]

👏 👏 👏

[pracucci]

I'm going to merge it to move forward. We can always re-iterate in a follow up PR, if there's more to add (I re-read it and technically looks good to me!).