limits: Add generic layer of limits (e.g interceptors) for StoreAPI.

[bwplotka]

We can leverage gRPC interceptors to ensure configuring limits per chunks, series etc of StoreAPI

Open questions:

• partial result or total cancel?

[bwplotka]

Good point from @brancz is that interceptor limit might be not enough. We can deduce how much chunks etc we will have without fetching them... so more on query planning side already.

[yashrsharma44]

I was working on a proposal for the above issue, and I had some queries regarding it. It would be really helpful for me to get some more clarity about the problem that we are trying to solve 😅

We can deduce how much chunks etc we will have without fetching them

Are we looking something like pre-flight checks for this?

so more on query planning side already.

Is this more like Query Logging but for Thanos?
@bwplotka

[VineethReddy02]

@bwplotka
I see the existing configuration in querier to limit the large queries and responses are

1. enablePartialResponse bool,
2. queryTimeout time.Duration,
3. storeResponseTimeout time.Duration,

Can I know what these configurations are missing to achieve in limiting the large queries and responses?

I have couple of questions here

1. So just to confirm will these interceptors be part of store API between querier & store, querier & sidecar right? as the query result is the aggregation of both.
2. And on what basis will grpc interceptors limit blocks? Based on the query range or based on the size of the block using metadata from the object store?

This can help me to understand what additional configurations need to be added and how interceptor logic needs to be implemented.

[stale]

Hello 👋 Looks like there was no activity on this issue for last 30 days.
Do you mind updating us on the status? Is this still reproducible or needed? If yes, just comment on this PR or push a commit. Thanks! 🤗
If there will be no activity for next week, this issue will be closed (we can always reopen an issue if we need!). Alternatively, use remind command if you wish to be reminded at some point in future.

[bwplotka]

Still in progress. Meant for a later task.

…

On Sun, 31 May 2020 at 19:24, stale[bot] ***@***.***> wrote: Hello 👋 Looks like there was no activity on this issue for last 30 days. *Do you mind updating us on the status?* Is this still reproducible or needed? If yes, just comment on this PR or push a commit. Thanks! 🤗 If there will be no activity for next week, this issue will be closed (we can always reopen an issue if we need!). Alternatively, use remind command <https://probot.github.io/apps/reminders/> if you wish to be reminded at some point in future. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2527 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABVA3O7NPLMIA2B7B7UIS6TRUKOFHANCNFSM4MRWL35Q> .

[stale]

Hello 👋 Looks like there was no activity on this issue for last 30 days.
Do you mind updating us on the status? Is this still reproducible or needed? If yes, just comment on this PR or push a commit. Thanks! 🤗
If there will be no activity for next week, this issue will be closed (we can always reopen an issue if we need!). Alternatively, use remind command if you wish to be reminded at some point in future.

[stale]

Closing for now as promised, let us know if you need this to be reopened! 🤗

[bwplotka]

Still not done.

[stale]

Hello 👋 Looks like there was no activity on this issue for the last two months.
Do you mind updating us on the status? Is this still reproducible or needed? If yes, just comment on this PR or push a commit. Thanks! 🤗
If there will be no activity in the next two weeks, this issue will be closed (we can always reopen an issue if we need!). Alternatively, use remind command if you wish to be reminded at some point in future.

[stale]

Closing for now as promised, let us know if you need this to be reopened! 🤗

[bwplotka]

Proven to be hard. Let's start with "non-generic" ones first (: