MON-4035: Add ThanosQuerierConfig to ClusterMonitoring API#2769
Conversation
|
Pipeline controller notification For optional jobs, comment This repository is configured in: LGTM mode |
openshift-ci-robot
added
the
jira/valid-reference
|
@danielmellado: This pull request references MON-4035 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target either version "4.22." or "openshift-4.22.", but it targets "openshift-5.0" instead. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
Hello @danielmellado! Some important instructions when contributing to openshift/api: |
📝 WalkthroughWalkthroughAdded an optional ✨ Finishing Touches🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 golangci-lint (2.11.4)Error: build linters: unable to load custom analyzer "kubeapilinter": tools/_output/bin/kube-api-linter.so, plugin: not implemented Comment |
openshift-ci
bot
added
the
size/XXL
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (2)
config/v1alpha1/tests/clustermonitorings.config.openshift.io/ClusterMonitoringConfig.yaml (1)
790-971: Add one explicit regression case for the relaxed quantity checks.If the non-positive
ContainerResourcerelaxation is intentional, please add one representativethanosQuerierConfig.resourcescreate case for it. The new coverage only exercises list semantics andlimit >= request, so that contract change is still implicit.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@config/v1alpha1/tests/clustermonitorings.config.openshift.io/ClusterMonitoringConfig.yaml` around lines 790 - 971, Add a regression test entry for the relaxed non-positive ContainerResource check by inserting a new test case in the same YAML list that validates thanosQuerierConfig.resources accepts a non-positive quantity (e.g., request: "0" and limit: "0"); the test should include a name like "Should be able to create ThanosQuerierConfig with non-positive resources" and provide identical initial and expected manifests under spec.thanosQuerierConfig.resources to assert create succeeds with request "0" and limit "0". Ensure the added case follows the same structure as existing tests (name, initial, expected) and targets thanosQuerierConfig.resources so the change in semantics is explicitly covered.payload-manifests/crds/0000_10_config-operator_01_clustermonitorings.crd.yaml (1)
4656-4702: Consider disallowing negative quantities in the regex to match the documented contract.
limit/requestdescriptions state values must be> 0, but the current pattern accepts a leading-. Tightening the regex keeps validation cheap while aligning behavior with docs.Suggested diff
- pattern: ^(\+|-)?(([0-9]+(\.[0-9]*)?)|(\.[0-9]+))(([KMGTPE]i)|[numkMGTPE]|([eE](\+|-)?(([0-9]+(\.[0-9]*)?)|(\.[0-9]+))))?$ + pattern: ^(\+)?(([0-9]+(\.[0-9]*)?)|(\.[0-9]+))(([KMGTPE]i)|[numkMGTPE]|([eE](\+|-)?(([0-9]+(\.[0-9]*)?)|(\.[0-9]+))))?$ ... - pattern: ^(\+|-)?(([0-9]+(\.[0-9]*)?)|(\.[0-9]+))(([KMGTPE]i)|[numkMGTPE]|([eE](\+|-)?(([0-9]+(\.[0-9]*)?)|(\.[0-9]+))))?$ + pattern: ^(\+)?(([0-9]+(\.[0-9]*)?)|(\.[0-9]+))(([KMGTPE]i)|[numkMGTPE]|([eE](\+|-)?(([0-9]+(\.[0-9]*)?)|(\.[0-9]+))))?$🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@payload-manifests/crds/0000_10_config-operator_01_clustermonitorings.crd.yaml` around lines 4656 - 4702, The regex for resource quantities in the limit and request fields currently allows a leading '-' which contradicts the documented "must be greater than 0" constraint; update the pattern in both the limit and request definitions (the pattern under the limit and request properties) to remove the optional negative sign (e.g., change ^(\+|-)?... to ^(\+)?... or simply drop the sign group) so negative values are rejected while preserving the rest of the quantity syntax and x-kubernetes-int-or-string behavior.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In
`@config/v1alpha1/tests/clustermonitorings.config.openshift.io/ClusterMonitoringConfig.yaml`:
- Around line 790-971: Add a regression test entry for the relaxed non-positive
ContainerResource check by inserting a new test case in the same YAML list that
validates thanosQuerierConfig.resources accepts a non-positive quantity (e.g.,
request: "0" and limit: "0"); the test should include a name like "Should be
able to create ThanosQuerierConfig with non-positive resources" and provide
identical initial and expected manifests under
spec.thanosQuerierConfig.resources to assert create succeeds with request "0"
and limit "0". Ensure the added case follows the same structure as existing
tests (name, initial, expected) and targets thanosQuerierConfig.resources so the
change in semantics is explicitly covered.
In
`@payload-manifests/crds/0000_10_config-operator_01_clustermonitorings.crd.yaml`:
- Around line 4656-4702: The regex for resource quantities in the limit and
request fields currently allows a leading '-' which contradicts the documented
"must be greater than 0" constraint; update the pattern in both the limit and
request definitions (the pattern under the limit and request properties) to
remove the optional negative sign (e.g., change ^(\+|-)?... to ^(\+)?... or
simply drop the sign group) so negative values are rejected while preserving the
rest of the quantity syntax and x-kubernetes-int-or-string behavior.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Pro
Run ID: af668436-5d4c-40ff-9589-2615607272cd
⛔ Files ignored due to path filters (4)
config/v1alpha1/zz_generated.crd-manifests/0000_10_config-operator_01_clustermonitorings.crd.yamlis excluded by!**/zz_generated.crd-manifests/*config/v1alpha1/zz_generated.featuregated-crd-manifests/clustermonitorings.config.openshift.io/ClusterMonitoringConfig.yamlis excluded by!**/zz_generated.featuregated-crd-manifests/**openapi/generated_openapi/zz_generated.openapi.gois excluded by!openapi/**openapi/openapi.jsonis excluded by!openapi/**
📒 Files selected for processing (5)
config/v1alpha1/tests/clustermonitorings.config.openshift.io/ClusterMonitoringConfig.yamlconfig/v1alpha1/types_cluster_monitoring.goconfig/v1alpha1/zz_generated.deepcopy.goconfig/v1alpha1/zz_generated.swagger_doc_generated.gopayload-manifests/crds/0000_10_config-operator_01_clustermonitorings.crd.yaml
yuqi-zhang
left a comment
yuqi-zhang
left a comment
There was a problem hiding this comment.
Generally lgtm, thanks for the clear documentation and tests. Just had some minor questions/comments inline + some nits/suggestions
danielmellado
force-pushed
the
mon_4035_add_thanos_querier_config
branch
from
4f6fc30 to
19ce37e
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@config/v1alpha1/types_cluster_monitoring.go`:
- Around line 771-781: Update the documentation examples in the comments for the
resources list to remove "limit: null" and instead omit the limit field (or show
it as unset) so the examples match the actual non-nullable schema; specifically
edit the comment blocks that list the default resources (the entries with "-
name: cpu" and "- name: memory") to drop "limit: null" for the resource items
referenced by the resources list in types_cluster_monitoring.go.
In
`@payload-manifests/crds/0000_10_config-operator_01_clustermonitorings.crd.yaml`:
- Around line 4660-4693: thanosQuerierConfig.resources currently allows negative
quantities because the regex for limit and request includes an optional "-" and
no CEL validation enforces positivity; update the pattern for both the limit and
request fields to remove the optional negative sign (replace the leading
'(\+|-)?' with either '(\+)?' or no sign) and add an x-kubernetes-validations
CEL rule on thanosQuerierConfig.resources.request and .limit that asserts the
parsed quantity is positive (e.g., use a CEL expression that converts the value
to a Quantity/number and checks > 0) so negative values are rejected at CRD
validation time.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Pro
Run ID: 68e62516-6e4b-435c-99aa-4d235de5d96e
⛔ Files ignored due to path filters (4)
config/v1alpha1/zz_generated.crd-manifests/0000_10_config-operator_01_clustermonitorings.crd.yamlis excluded by!**/zz_generated.crd-manifests/*config/v1alpha1/zz_generated.featuregated-crd-manifests/clustermonitorings.config.openshift.io/ClusterMonitoringConfig.yamlis excluded by!**/zz_generated.featuregated-crd-manifests/**openapi/generated_openapi/zz_generated.openapi.gois excluded by!openapi/**openapi/openapi.jsonis excluded by!openapi/**
📒 Files selected for processing (5)
config/v1alpha1/tests/clustermonitorings.config.openshift.io/ClusterMonitoringConfig.yamlconfig/v1alpha1/types_cluster_monitoring.goconfig/v1alpha1/zz_generated.deepcopy.goconfig/v1alpha1/zz_generated.swagger_doc_generated.gopayload-manifests/crds/0000_10_config-operator_01_clustermonitorings.crd.yaml
✅ Files skipped from review due to trivial changes (1)
- config/v1alpha1/zz_generated.deepcopy.go
🚧 Files skipped from review as they are similar to previous changes (1)
- config/v1alpha1/tests/clustermonitorings.config.openshift.io/ClusterMonitoringConfig.yaml
payload-manifests/crds/0000_10_config-operator_01_clustermonitorings.crd.yaml
Show resolved
Hide resolved
yuqi-zhang
left a comment
yuqi-zhang
left a comment
There was a problem hiding this comment.
Generally lgtm, will @JoelSpeed or @everettraven give the final approval
everettraven
left a comment
everettraven
left a comment
There was a problem hiding this comment.
Aside from aligning the container resources changes with the changes in #2755 and my one comment - this LGTM
danielmellado
force-pushed
the
mon_4035_add_thanos_querier_config
branch
from
19ce37e to
97cb5e4
Compare
There was a problem hiding this comment.
🧹 Nitpick comments (1)
config/v1alpha1/tests/clustermonitorings.config.openshift.io/ClusterMonitoringConfig.yaml (1)
2432-2446: Consider adding ratcheting tests for ThanosQuerierConfig.Other component configs (alertmanagerConfig, metricsServerConfig, prometheusOperatorConfig, etc.) include ratcheting tests that verify:
- Updating other fields while retaining >5 resources via ratcheting
- Rejecting updates to a different invalid list when persisted count exceeds maxItems
- Allowing reduction of persisted resources to a valid count
ThanosQuerierConfig only has the empty object rejection test. Adding the ratcheting tests would ensure consistent validation behavior and test coverage.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@config/v1alpha1/tests/clustermonitorings.config.openshift.io/ClusterMonitoringConfig.yaml` around lines 2432 - 2446, Add ratcheting tests for ThanosQuerierConfig similar to existing tests for alertmanagerConfig/metricsServerConfig/prometheusOperatorConfig: create test cases that (1) start with >5 resources and verify an update that changes unrelated fields while keeping the persisted resource count uses ratcheting (accepts update), (2) simulate a persisted state with count > maxItems and attempt an update that swaps to a different invalid resource list (expect rejection like "spec.thanosQuerierConfig: Invalid value"), and (3) allow reducing the persisted resources down to a valid count and ensure the update succeeds; target the same test harness as the existing YAML cases and add names like "Should allow ratcheting update for ThanosQuerierConfig", "Should reject swap to different invalid ThanosQuerierConfig list when persisted count exceeds maxItems", and "Should allow reducing ThanosQuerierConfig resources to valid count", referencing spec.thanosQuerierConfig and the existing "Should reject updating ThanosQuerierConfig to empty object" case for placement.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In
`@config/v1alpha1/tests/clustermonitorings.config.openshift.io/ClusterMonitoringConfig.yaml`:
- Around line 2432-2446: Add ratcheting tests for ThanosQuerierConfig similar to
existing tests for
alertmanagerConfig/metricsServerConfig/prometheusOperatorConfig: create test
cases that (1) start with >5 resources and verify an update that changes
unrelated fields while keeping the persisted resource count uses ratcheting
(accepts update), (2) simulate a persisted state with count > maxItems and
attempt an update that swaps to a different invalid resource list (expect
rejection like "spec.thanosQuerierConfig: Invalid value"), and (3) allow
reducing the persisted resources down to a valid count and ensure the update
succeeds; target the same test harness as the existing YAML cases and add names
like "Should allow ratcheting update for ThanosQuerierConfig", "Should reject
swap to different invalid ThanosQuerierConfig list when persisted count exceeds
maxItems", and "Should allow reducing ThanosQuerierConfig resources to valid
count", referencing spec.thanosQuerierConfig and the existing "Should reject
updating ThanosQuerierConfig to empty object" case for placement.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Pro
Run ID: 74f22348-75a7-442e-bcd4-f04e3da32446
⛔ Files ignored due to path filters (3)
config/v1alpha1/zz_generated.crd-manifests/0000_10_config-operator_01_clustermonitorings.crd.yamlis excluded by!**/zz_generated.crd-manifests/*config/v1alpha1/zz_generated.featuregated-crd-manifests/clustermonitorings.config.openshift.io/ClusterMonitoringConfig.yamlis excluded by!**/zz_generated.featuregated-crd-manifests/**openapi/generated_openapi/zz_generated.openapi.gois excluded by!openapi/**
📒 Files selected for processing (5)
config/v1alpha1/tests/clustermonitorings.config.openshift.io/ClusterMonitoringConfig.yamlconfig/v1alpha1/types_cluster_monitoring.goconfig/v1alpha1/zz_generated.deepcopy.goconfig/v1alpha1/zz_generated.swagger_doc_generated.gopayload-manifests/crds/0000_10_config-operator_01_clustermonitorings.crd.yaml
✅ Files skipped from review due to trivial changes (1)
- config/v1alpha1/zz_generated.deepcopy.go
🚧 Files skipped from review as they are similar to previous changes (2)
- config/v1alpha1/zz_generated.swagger_doc_generated.go
- config/v1alpha1/types_cluster_monitoring.go
Migrate the thanos-querier configmap settings to a CRD field within ClusterMonitoringSpec in config/v1alpha1. The new ThanosQuerierConfig struct supports: - nodeSelector: pod scheduling to specific nodes - resources: compute resource requests and limits - tolerations: pod tolerations for scheduling - topologySpreadConstraints: pod distribution across topology domains Also removes per-field positive-quantity CEL checks from ContainerResource request/limit fields to stay within the Kubernetes CRD CEL validation cost budget (StaticEstimatedCRDCostLimit) with 7 component configs at MaxItems=10. Signed-off-by: Daniel Mellado <dmellado@fedoraproject.org>
danielmellado
force-pushed
the
mon_4035_add_thanos_querier_config
branch
from
97cb5e4 to
22d3aa1
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@config/v1alpha1/tests/clustermonitorings.config.openshift.io/ClusterMonitoringConfig.yaml`:
- Around line 1269-1289: Update the two failing tests in
ClusterMonitoringConfig.yaml: for the case named "Should reject
ThanosQuerierConfig with zero request" stop expecting a "positive, non‑zero
quantity" error (remove the expectedError or mark the input as valid) because
per-field positive checks on request were removed; for "Should reject
ThanosQuerierConfig with zero limit" change the expectedError to assert the
inequality validation (i.e., that limit is less than request) instead of a
non‑positive error—update the expected error to reference
spec.thanosQuerierConfig.resources[0].limit and a message stating that limit
must be >= request.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Pro
Run ID: 372172c2-e60c-4698-b80f-250a4edd46a2
⛔ Files ignored due to path filters (3)
config/v1alpha1/zz_generated.crd-manifests/0000_10_config-operator_01_clustermonitorings.crd.yamlis excluded by!**/zz_generated.crd-manifests/*config/v1alpha1/zz_generated.featuregated-crd-manifests/clustermonitorings.config.openshift.io/ClusterMonitoringConfig.yamlis excluded by!**/zz_generated.featuregated-crd-manifests/**openapi/generated_openapi/zz_generated.openapi.gois excluded by!openapi/**
📒 Files selected for processing (5)
config/v1alpha1/tests/clustermonitorings.config.openshift.io/ClusterMonitoringConfig.yamlconfig/v1alpha1/types_cluster_monitoring.goconfig/v1alpha1/zz_generated.deepcopy.goconfig/v1alpha1/zz_generated.swagger_doc_generated.gopayload-manifests/crds/0000_10_config-operator_01_clustermonitorings.crd.yaml
🚧 Files skipped from review as they are similar to previous changes (2)
- config/v1alpha1/zz_generated.deepcopy.go
- config/v1alpha1/zz_generated.swagger_doc_generated.go
| - name: Should reject ThanosQuerierConfig with zero request | ||
| initial: | | ||
| apiVersion: config.openshift.io/v1alpha1 | ||
| kind: ClusterMonitoring | ||
| spec: | ||
| thanosQuerierConfig: | ||
| resources: | ||
| - name: "cpu" | ||
| request: "0" | ||
| expectedError: 'spec.thanosQuerierConfig.resources[0].request: Invalid value: "": request must be a positive, non-zero quantity' | ||
| - name: Should reject ThanosQuerierConfig with zero limit | ||
| initial: | | ||
| apiVersion: config.openshift.io/v1alpha1 | ||
| kind: ClusterMonitoring | ||
| spec: | ||
| thanosQuerierConfig: | ||
| resources: | ||
| - name: "cpu" | ||
| request: "100m" | ||
| limit: "0" | ||
| expectedError: 'spec.thanosQuerierConfig.resources[0].limit: Invalid value: "": limit must be a positive, non-zero quantity' |
There was a problem hiding this comment.
Zero-quantity assertions are inconsistent with the ContainerResource validation change.
Line 1269 and Line 1280 still expect “positive, non-zero quantity” errors, but this PR explicitly removes per-field positive-quantity CEL checks on request/limit.
Also, the Line 1280 case (request: "100m", limit: "0") should fail because limit < request, not because limit is non-positive.
Please update these tests to reflect the new behavior (accept zero where applicable, and keep inequality validation separate).
Suggested test adjustment
- - name: Should reject ThanosQuerierConfig with zero request
+ - name: Should allow ThanosQuerierConfig with zero request
initial: |
apiVersion: config.openshift.io/v1alpha1
kind: ClusterMonitoring
spec:
thanosQuerierConfig:
resources:
- name: "cpu"
request: "0"
- expectedError: 'spec.thanosQuerierConfig.resources[0].request: Invalid value: "": request must be a positive, non-zero quantity'
+ expected: |
+ apiVersion: config.openshift.io/v1alpha1
+ kind: ClusterMonitoring
+ spec:
+ thanosQuerierConfig:
+ resources:
+ - name: "cpu"
+ request: "0"
- - name: Should reject ThanosQuerierConfig with zero limit
+ - name: Should allow ThanosQuerierConfig with zero limit when request is omitted
initial: |
apiVersion: config.openshift.io/v1alpha1
kind: ClusterMonitoring
spec:
thanosQuerierConfig:
resources:
- name: "cpu"
- request: "100m"
limit: "0"
- expectedError: 'spec.thanosQuerierConfig.resources[0].limit: Invalid value: "": limit must be a positive, non-zero quantity'
+ expected: |
+ apiVersion: config.openshift.io/v1alpha1
+ kind: ClusterMonitoring
+ spec:
+ thanosQuerierConfig:
+ resources:
+ - name: "cpu"
+ limit: "0"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@config/v1alpha1/tests/clustermonitorings.config.openshift.io/ClusterMonitoringConfig.yaml`
around lines 1269 - 1289, Update the two failing tests in
ClusterMonitoringConfig.yaml: for the case named "Should reject
ThanosQuerierConfig with zero request" stop expecting a "positive, non‑zero
quantity" error (remove the expectedError or mark the input as valid) because
per-field positive checks on request were removed; for "Should reject
ThanosQuerierConfig with zero limit" change the expectedError to assert the
inequality validation (i.e., that limit is less than request) instead of a
non‑positive error—update the expected error to reference
spec.thanosQuerierConfig.resources[0].limit and a message stating that limit
must be >= request.
There was a problem hiding this comment.
but this PR explicitly removes per-field positive-quantity CEL checks on request/limit.
Does it? Looks to me like there are still CEL expressions that enforce the parsed quantity value is greater than 0.
There was a problem hiding this comment.
🧩 Analysis chain
Let me verify what CEL validations actually exist on the thanosQuerierConfig resources in the CRD.
🏁 Script executed:
#!/bin/bash
# Check CEL validations for thanosQuerierConfig resources in the CRD
rg -A 30 "thanosQuerierConfig" payload-manifests/crds/0000_10_config-operator_01_clustermonitorings.crd.yaml | grep -A 10 "x-kubernetes-validations" | head -80
# Also check the types file directly
rg -B5 -A10 "positive.*non-zero\|non-zero.*positive\|quantity.*greater" config/v1alpha1/types_cluster_monitoring.go
# Check the CRD YAML for the request/limit validation rules within thanosQuerierConfig
python3 - <<'EOF'
import yaml, sys
with open("payload-manifests/crds/0000_10_config-operator_01_clustermonitorings.crd.yaml") as f:
crd = yaml.safe_load(f)
spec_props = crd["spec"]["versions"][0]["schema"]["openAPIV3Schema"]["properties"]["spec"]["properties"]
if "thanosQuerierConfig" in spec_props:
tqc = spec_props["thanosQuerierConfig"]
resources = tqc.get("properties", {}).get("resources", {})
items = resources.get("items", {})
print("=== ThanosQuerierConfig resources items validations ===")
print(yaml.dump(items, default_flow_style=False))
else:
print("thanosQuerierConfig not found")
EOF
Length of output: 2356
@everettraven, you're absolutely right. The per-field positive-quantity CEL checks are still present in the CRD schema for thanosQuerierConfig.resources items:
x-kubernetes-validations:
- message: request must be a positive, non-zero quantity
rule: quantity(self).isGreaterThan(quantity('0'))x-kubernetes-validations:
- message: limit must be a positive, non-zero quantity
rule: quantity(self).isGreaterThan(quantity('0'))My original comment was incorrect — the tests at those lines are valid and should stay as-is. I apologize for the noise.
There was a problem hiding this comment.
It is true that this would also trigger the limit < request validation to fail though.
This could be simplified to only specifying limit because there is a requirement is that at least one of limit and request is specified, meaning both aren't strictly required. I wouldn't block on that though. As long as we have a signal that the validation we want to fail is failing, this should be OK.
There was a problem hiding this comment.
@everettraven, that's a fair point. The current test with request: "100m" and limit: "0" does exercise both validations simultaneously, whereas limit: "0" alone would more precisely isolate the positive-quantity check. Either way the signal is there. Since you're not blocking on it, the author can choose to simplify or leave as-is — both are correct.
|
Scheduling tests matching the |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: everettraven, yuqi-zhang The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci
bot
added
the
approved
|
/verified by tests |
openshift-ci-robot
added
the
verified
|
@danielmellado: This PR has been marked as verified by DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
/retest-required |
|
https://prow.ci.openshift.org/job-history/gs/test-platform-results/pr-logs/directory/pull-ci-openshift-api-master-e2e-aws-ovn-hypershift-conformance e2e-aws-ovn-hypershift-conformance seems not to have had a passing job since April 1st |
|
Known issue with hypershift conformance. /override ci/prow/e2e-aws-ovn-hypershift-conformance |
|
@everettraven: Overrode contexts on behalf of everettraven: ci/prow/e2e-aws-ovn-hypershift-conformance DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
@everettraven mind overriding this again? it seems it didn't stuck somehow. Thanks! |
|
/override ci/prow/e2e-aws-ovn-hypershift-conformance |
|
@everettraven: Overrode contexts on behalf of everettraven: ci/prow/e2e-aws-ovn-hypershift-conformance DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
@danielmellado: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
5 participants
Migrate the thanos-querier configmap settings to a CRD field within
ClusterMonitoringSpec in config/v1alpha1. The new ThanosQuerierConfig
struct supports:
Also removes per-field positive-quantity CEL checks from
ContainerResource request/limit fields to stay within the Kubernetes
CRD CEL validation cost budget (StaticEstimatedCRDCostLimit) with
7 component configs at MaxItems=10.
Signed-off-by: Daniel Mellado dmellado@fedoraproject.org