-
Feature Request
-
Resolution: Unresolved
-
Normal
-
None
-
openshift-4.18
-
None
-
None
-
Product / Portfolio Work
-
None
-
False
-
-
None
-
None
-
None
-
-
None
-
None
-
None
-
None
-
None
[1]Proposed title of this feature request
- Expose resource requests and limits configuration for ThanosQuerier in Cluster Observability Operator
[2]What is the nature and description of the request?
- The Cloud Observability Operator (COO) currently does not provide a supported mechanism to configure CPU and memory resource requests and limits for the ThanosQuerier component.
- While the MonitoringStack custom resource allows configuring resources for some components, these settings are not inherited by the ThanosQuerier. In addition, the ThanosQuerier CRD itself does not expose any fields to define resource requirements.
- As a result, Thanos Querier pods are created without resource requests or limits.
Problem Statement:
In environments where ResourceQuota and/or LimitRange policies are enforced (which is common in production and regulated clusters), pods without explicit resource requests and limits are rejected by the admission controller.
This leads to:
- Thanos Querier pods failing to start
- Centralized query functionality being unavailable
- Cloud Observability deployments being blocked in production clusters
- Reliance on unsupported workarounds such as namespace-wide LimitRanges or manual Deployment patching
[3]Why does the customer need this? (List the business requirements here)
- In many production environments, configuring CPU and memory requests and limits is considered a standard operational requirement to support reliable scheduling and capacity planning. As the ThanosQuerier CR does not currently expose these settings, an RFE would be beneficial to better align the component with common supportability expectations.
- links to