Add prometheusConfig API#2653
Conversation
|
Pipeline controller notification For optional jobs, comment This repository is configured in: LGTM mode |
|
Hello @marioferh! Some important instructions when contributing to openshift/api: |
|
Note Reviews pausedUse the following commands to manage reviews:
📝 WalkthroughWalkthroughThis pull request introduces comprehensive Prometheus platform configuration capabilities to the cluster monitoring API. It adds multiple new public types for Prometheus settings, including support for remote write endpoints, TLS configuration, authorization, metric relabeling, retention policies, and scheduling constraints. The changes include auto-generated implementations for deep-copy operations and OpenAPI/Swagger documentation. Three ClusterMonitoring CRD variants are updated with a new prometheusConfig field, and Alertmanager volumeClaimTemplate descriptions are refined across all CRD files. 🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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.
Actionable comments posted: 5
🤖 Fix all issues with AI agents
In `@config/v1alpha1/types_cluster_monitoring.go`:
- Around line 734-736: The RelabelAction enum is missing valid Prometheus
actions (Lowercase, Uppercase, KeepEqual, DropEqual) referenced by the
RelabelConfig XValidation rules; update the RelabelAction enum to include these
four values and ensure the RelabelConfig.action field documentation (and any
comment on targetLabel) lists them so the enum validation and XValidation rules
align with each other and with Prometheus semantics.
In `@openapi/generated_openapi/zz_generated.openapi.go`:
- Around line 24259-24333: The RelabelConfig OpenAPI definition generated in
function schema_openshift_api_config_v1alpha1_RelabelConfig has an incomplete
"action" description; update the description string for the "action" property to
list all 11 valid Prometheus actions (Replace, Keep, Drop, HashMod, LabelMap,
LabelDrop, LabelKeep, Lowercase, Uppercase, KeepEqual, DropEqual) and then
regenerate the OpenAPI output from the canonical source type so the change
persists; verify and correct the source Go type or its swagger tags that define
RelabelConfig's Action documentation before re-running the generator.
In
`@payload-manifests/crds/0000_10_config-operator_01_clustermonitorings-CustomNoUpgrade.crd.yaml`:
- Around line 1803-1811: The action enum for RelabelConfig currently lists
Replace, Keep, Drop, HashMod, LabelMap, LabelDrop, LabelKeep but the targetLabel
description and its validation rule mention Lowercase, Uppercase, KeepEqual,
DropEqual; update either the enum or the docs/validation so they match: either
add the missing actions (Lowercase, Uppercase, KeepEqual, DropEqual) to the
action enum or remove/replace those action names from the targetLabel
description and the validation pattern so they only reference the existing enum
values; locate the enum block named "action" and the "targetLabel"
description/validation in this CRD and make the change consistently across both
sections.
In
`@payload-manifests/crds/0000_10_config-operator_01_clustermonitorings-DevPreviewNoUpgrade.crd.yaml`:
- Around line 1803-1811: The CRD's action enum for the field named "action" is
missing values referenced elsewhere (Lowercase, Uppercase, KeepEqual,
DropEqual), causing an enum/validation/description mismatch; fix by either
adding those four values to the action enum (so enum contains Replace, Keep,
Drop, HashMod, LabelMap, LabelDrop, LabelKeep, Lowercase, Uppercase, KeepEqual,
DropEqual) or by removing all references to those four actions from the
validation rule and the description text that mentions them; update the enum
block for "action" and the corresponding validation rule/description (the same
section around the existing action enum and the validation referenced)
consistently so they match, and repeat the same change for the other occurrence
noted (the block spanning lines ~1873-1894).
In
`@payload-manifests/crds/0000_10_config-operator_01_clustermonitorings-TechPreviewNoUpgrade.crd.yaml`:
- Around line 1803-1894: The action enum for the relabel configuration is
missing four valid Prometheus actions; update the enum under the "action" field
to include "Lowercase", "Uppercase", "KeepEqual", and "DropEqual" so those
values are accepted by validation. Edit the enum list (the token named action in
this CRD) to append these four strings and leave the existing
x-kubernetes-validations rules (the rule that requires targetLabel for Replace,
HashMod, Lowercase, Uppercase, KeepEqual, DropEqual and the replacement rule)
intact so targetLabel and replacement semantics continue to be enforced.
🧹 Nitpick comments (3)
openapi/openapi.json (3)
4575-4587: Consider encodingAcceptRisk.namelength constraints in schema.The description calls out non-empty and ≤256 chars, but the schema doesn’t enforce
minLength/maxLength. If you want API-server validation, add kubebuilder validation tags on the Go type so OpenAPI reflects the constraint.
12164-12208: Add schema validation for documented constraints (scheme/pathPrefix/staticConfigs).The doc specifies allowed values and structural constraints (e.g., scheme values, pathPrefix format, staticConfigs min/max), but the schema doesn’t encode them. If you want server-side validation, add kubebuilder
Enum,Pattern, andMinItems/MaxItemstags in the Go types so OpenAPI enforces these rules.
13178-13380: Align schema validation with documented constraints.Several fields document enums or size limits (e.g.,
collectionProfile,logLevel,externalLabels,remoteWrite,tolerations,topologySpreadConstraints), but the schema doesn’t encode those rules. If enforcement is intended, add kubebuilder validations to the Go types so the OpenAPI includesenum,minItems/maxItems, and relevantmin/maxconstraints.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Cache: Disabled due to data retention organization setting
Knowledge base: Disabled due to data retention organization setting
⛔ Files ignored due to path filters (4)
config/v1alpha1/zz_generated.crd-manifests/0000_10_config-operator_01_clustermonitorings-CustomNoUpgrade.crd.yamlis excluded by!**/zz_generated.crd-manifests/*config/v1alpha1/zz_generated.crd-manifests/0000_10_config-operator_01_clustermonitorings-DevPreviewNoUpgrade.crd.yamlis excluded by!**/zz_generated.crd-manifests/*config/v1alpha1/zz_generated.crd-manifests/0000_10_config-operator_01_clustermonitorings-TechPreviewNoUpgrade.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/**
📒 Files selected for processing (8)
config/v1alpha1/types_cluster_monitoring.goconfig/v1alpha1/zz_generated.deepcopy.goconfig/v1alpha1/zz_generated.swagger_doc_generated.goopenapi/generated_openapi/zz_generated.openapi.goopenapi/openapi.jsonpayload-manifests/crds/0000_10_config-operator_01_clustermonitorings-CustomNoUpgrade.crd.yamlpayload-manifests/crds/0000_10_config-operator_01_clustermonitorings-DevPreviewNoUpgrade.crd.yamlpayload-manifests/crds/0000_10_config-operator_01_clustermonitorings-TechPreviewNoUpgrade.crd.yaml
🧰 Additional context used
🧬 Code graph analysis (3)
config/v1alpha1/zz_generated.deepcopy.go (2)
config/v1alpha1/types_cluster_monitoring.go (10)
AdditionalAlertmanagerConfig(615-676)TLSConfig(814-842)AuthorizationConfig(869-882)PrometheusConfig(434-601)Label(679-693)RemoteWriteSpec(696-732)ContainerResource(305-335)Retention(907-928)RelabelConfig(737-807)SecretKeySelector(886-903)config/v1alpha1/zz_generated.swagger_doc_generated.go (10)
AdditionalAlertmanagerConfig(132-134)TLSConfig(333-335)AuthorizationConfig(176-178)PrometheusConfig(273-275)Label(238-240)RemoteWriteSpec(300-302)ContainerResource(228-230)Retention(310-312)RelabelConfig(288-290)SecretKeySelector(320-322)
config/v1alpha1/types_cluster_monitoring.go (1)
config/v1alpha1/zz_generated.swagger_doc_generated.go (5)
PrometheusConfig(273-275)AdditionalAlertmanagerConfig(132-134)Label(238-240)Retention(310-312)SecretKeySelector(320-322)
config/v1alpha1/zz_generated.swagger_doc_generated.go (1)
config/v1alpha1/types_cluster_monitoring.go (9)
AdditionalAlertmanagerConfig(615-676)AuthorizationConfig(869-882)Label(679-693)PrometheusConfig(434-601)RelabelConfig(737-807)RemoteWriteSpec(696-732)Retention(907-928)SecretKeySelector(886-903)TLSConfig(814-842)
🔇 Additional comments (54)
config/v1alpha1/zz_generated.deepcopy.go (1)
1-1274: Autogenerated deep copy implementations look correct.This file is marked as autogenerated (
Code generated by codegen. DO NOT EDIT.). The deep copy semantics are correctly implemented:
- Slices of structs with nested pointers/slices (e.g.,
AdditionalAlertmanagerConfigs,RemoteWrite,WriteRelabelConfigs) use element-wiseDeepCopyInto- Slices of value types (e.g.,
ExternalLabels,StaticConfigs) usecopy()- Pointer fields (e.g.,
Replacement *string,VolumeClaimTemplate *PVC) are properly allocated and deep copied- Value-only structs (e.g.,
Retention,SecretKeySelector,TLSConfig) correctly use shallow copypayload-manifests/crds/0000_10_config-operator_01_clustermonitorings-TechPreviewNoUpgrade.crd.yaml (4)
455-456: Description refinement looks good.The updated description appropriately focuses on the practical configuration aspects (storage class and volume size) while removing redundant "This field is optional." text that's conveyed elsewhere in the schema.
1285-1298: Well-designed API surface for Prometheus configuration.The
prometheusConfigfield provides a comprehensive configuration interface with clear documentation and appropriate defaults. The use ofminProperties: 1ensures the field is meaningful when specified.
1592-1596: Good mutual TLS validation constraint.The CEL rule ensures that
certandkeymust both be specified together for mutual TLS, or both be omitted. This prevents invalid partial configurations.
2259-2668: PrometheusvolumeClaimTemplatemirrors Alertmanager configuration appropriately.The schema for Prometheus persistent storage follows the same pattern as
alertmanagerConfig.volumeClaimTemplate, ensuring consistent UX across the API. The description correctly notes that data will not persist without this configuration.payload-manifests/crds/0000_10_config-operator_01_clustermonitorings-CustomNoUpgrade.crd.yaml (4)
455-456: LGTM!The updated description is clearer and more actionable, guiding users on what the field configures.
1300-1606: Well-designed additional Alertmanager configuration.The
additionalAlertmanagerConfigsstructure is comprehensive with:
- Proper
x-kubernetes-list-map-keysusingnamefor server-side apply- Consistent secret reference patterns with appropriate validation
- TLS mutual auth validation ensuring cert/key are specified together
- Sensible defaults (HTTP scheme, 10s timeout)
1706-1736: Well-designed queryLogFile path validation.The validation rules effectively prevent security issues:
- Restricts
/dev/paths to only stdout, stderr, and null- Prevents path traversal with
..check- Disallows consecutive slashes and trailing slashes
- Allows both absolute paths and simple filenames
This is a thoughtful security-conscious design.
1285-1298: Comprehensive prometheusConfig API addition.The new
prometheusConfigfield provides extensive customization options for the platform Prometheus instance. The design follows established patterns:
- Consistent validation rules across similar field types
- Proper use of
x-kubernetes-list-type(map for keyed lists, atomic for ordered lists, set for unique items)- Clear default value documentation in descriptions
minProperties: 1ensures meaningful configuration when the field is presentpayload-manifests/crds/0000_10_config-operator_01_clustermonitorings-DevPreviewNoUpgrade.crd.yaml (7)
455-458: LGTM - Description refinement is clear and consistent.The updated description appropriately focuses on the purpose of
volumeClaimTemplatewhile the "If omitted" clause still conveys optionality.
1285-1298: LGTM - Well-structured prometheusConfig introduction.The prometheusConfig field is well-documented with clear use cases (pod scheduling, resource allocation, retention policies, external integrations). The
minProperties: 1constraint correctly ensures at least one property is set when the field is specified.
1300-1606: LGTM - additionalAlertmanagerConfigs is well-designed.Good use of:
- Server-side apply with
x-kubernetes-list-type: mapkeyed byname- CEL validation for mutual TLS (cert and key must both be present or both omitted)
- CEL validation for bearer token requirement based on auth type
- Clever use of
isURL('http://' + self)to validate host:port format in staticConfigs
1986-2016: LGTM - Retention configuration is well-defined.Clear constraints with appropriate ranges (1-365 days for duration, 1-16384 GiB for size). The
minProperties: 1ensures at least one setting is specified when the field is used.
1706-1736: LGTM - queryLogFile validation is comprehensive and security-conscious.The CEL validation rules properly:
- Allow absolute paths or simple filenames
- Restrict
/dev/paths to only stdout/stderr/null- Prevent path traversal with
..and/..checks- Prevent malformed paths with
//and trailing/checks
2259-2264: LGTM - volumeClaimTemplate structure is consistent.The Prometheus volumeClaimTemplate mirrors the Alertmanager volumeClaimTemplate structure, maintaining API consistency across the CRD.
1635-1673: LGTM - externalLabels design supports multi-controller management.Good use of
x-kubernetes-list-type: mapkeyed bykeyallows multiple controllers to independently manage their labels via server-side apply. The constraints (max 50 labels, 128 char limit per key/value) are reasonable.openapi/generated_openapi/zz_generated.openapi.go (10)
22321-22397: LGTM - AdditionalAlertmanagerConfig schema is well-structured.The schema properly defines required fields (
name,staticConfigs) and documents validation constraints in descriptions. The use ofx-kubernetes-list-type: setfor staticConfigs is appropriate for ensuring uniqueness.
22543-22548: LGTM - Improved documentation clarity.The updated description clearly explains the consequence of omitting
volumeClaimTemplate(ephemeral storage, data loss on restarts).
22578-22618: LGTM - AuthorizationConfig uses proper discriminated union pattern.The schema correctly implements the Kubernetes discriminated union pattern with
x-kubernetes-unions, ensuringbearerTokenis only applicable whentypeisBearerToken.
23055-23074: LGTM - prometheusConfig field properly integrated.The field is appropriately optional with a comprehensive description covering scheduling, resources, retention, and external integrations. Dependencies are correctly updated.
23656-23682: LGTM - Label schema is straightforward.Both
keyandvalueare correctly marked as required. Character length constraints documented in descriptions would be enforced via CRD validation markers in the source types.
24057-24257: LGTM - PrometheusConfig schema is comprehensive.The schema covers all expected Prometheus configuration aspects including scheduling (
nodeSelector,tolerations,topologySpreadConstraints), resources, retention, and external integrations (remoteWrite,additionalAlertmanagerConfigs). List types are correctly specified for server-side apply compatibility.
24335-24392: LGTM - RemoteWriteSpec schema is well-defined.The
urlfield is correctly marked as required. ThewriteRelabelConfigsuses map list type withnameas the key, enabling proper server-side apply behavior.
24394-24419: LGTM - Retention schema is appropriately flexible.Both fields are optional with sensible documented defaults (15 days, no size limit). The constraints (1-365 days, 1-16384 GiB) are clearly documented.
24515-24546: LGTM - SecretKeySelector schema is correct.Both
nameandkeyare properly required. Thex-kubernetes-map-type: atomicannotation is appropriate for this reference type, and the namespace scoping (openshift-monitoring) is clearly documented.
24578-24626: No changes needed. The TLSConfig validation constraints described in the schema are properly implemented in the source type definition via kubebuilder markers:
+kubebuilder:validation:MinProperties=1enforces at least one TLS configuration option must be specified+kubebuilder:validation:XValidationenforces the cert/key mutual dependencyThe OpenAPI schema correctly reflects the descriptions without requiring explicit Required fields, as the validation rules are enforced at the CRD/admission level.
config/v1alpha1/zz_generated.swagger_doc_generated.go (1)
121-335: LGTM! Swagger documentation entries for new types are correctly generated.The swagger documentation maps for the new Prometheus configuration types (
PrometheusConfig,AdditionalAlertmanagerConfig,Label,RemoteWriteSpec,RelabelConfig,TLSConfig,AuthorizationConfig,SecretKeySelector,Retention) are consistent with the corresponding struct definitions intypes_cluster_monitoring.go.config/v1alpha1/types_cluster_monitoring.go (8)
92-104: LGTM! Well-documented addition of prometheusConfig field.The new
prometheusConfigfield is properly documented with clear explanations of what can be configured (scheduling, resources, retention, external integrations). The field follows the same optional pattern as other config fields in the spec.
260-265: LGTM! VolumeClaimTemplate field improvements.The refined description is clearer, and adding
omitzeroto the JSON tag is appropriate for optional pointer fields to ensure empty structs are omitted from serialization.
430-601: LGTM! Comprehensive PrometheusConfig struct with thorough validation.The struct is well-designed with:
- Appropriate
listTypeannotations (mapfor unique keys,setfor unique items,atomicfor tolerations)- Reasonable validation bounds (e.g., 10kB-1GB for body size limit, 1-10 items for lists)
- Composite list map keys for
topologySpreadConstraintsmatching the pattern used inAlertmanagerCustomConfig- Clear documentation for each field including defaults and behavior when omitted
809-842: LGTM! Well-designed TLSConfig with proper mTLS validation.The struct has good validation:
MinProperties=1ensures meaningful configuration when TLSConfig is specified- XValidation rule properly enforces that
certandkeymust both be present or both absent for mutual TLS- DNS subdomain validation on
serverNameis appropriate
866-882: LGTM! Proper union pattern for AuthorizationConfig.The struct correctly implements the Kubernetes union pattern with:
+unionmarker on the struct+unionDiscriminatoron thetypefield- XValidation rule ensuring
bearerTokenis required when type isBearerTokenand forbidden otherwise
884-903: LGTM! SecretKeySelector with appropriate atomic struct type.The
+structType=atomicmarker is appropriate for this simple reference type. Both fields have proper validation constraints for Kubernetes secret naming conventions.
612-676: LGTM! Well-structured AdditionalAlertmanagerConfig.The struct has thorough validation:
- Clever
staticConfigsvalidation using URL parsing to validatehost:portformat- Proper path prefix validation preventing query strings and fragments
- Reasonable timeout bounds (1-600 seconds)
- Default scheme of
HTTPwith explicit HTTPS option
678-732: LGTM! Supporting types are well-defined.
Label: Appropriate length constraints (1-128 chars) for key/value pairsRemoteWriteSpec: Proper URL validation with http/https scheme enforcementRetention:MinProperties=1ensures meaningful configuration; reasonable bounds (1-365 days, 1-16384 GiB)CollectionProfile: Clear enum values (Full/Minimal) with good documentationAlso applies to: 905-961
openapi/openapi.json (19)
5875-5886: No issues noted.
6094-6102: No issues noted.
6129-6140: No issues noted.
6351-6354: No issues noted.
8537-8539: No issues noted.
8815-8817: No issues noted.
9745-9747: No issues noted.
11323-11326: No issues noted.
11334-11353: No issues noted.
11639-11650: No issues noted.
11685-11686: No issues noted.
12288-12290: No issues noted.
12306-12331: No issues noted.
12586-12590: No issues noted.
12938-12954: No issues noted.
13446-13464: No issues noted.
13483-13510: No issues noted.
29305-29307: No issues noted.
29954-29957: No issues noted.
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
| enum: | ||
| - Replace | ||
| - Keep | ||
| - Drop | ||
| - HashMod | ||
| - LabelMap | ||
| - LabelDrop | ||
| - LabelKeep | ||
| type: string |
There was a problem hiding this comment.
Mismatch between RelabelConfig action enum and validation/description.
The action enum (lines 1803-1810) includes: Replace, Keep, Drop, HashMod, LabelMap, LabelDrop, LabelKeep.
However, the targetLabel description (line 1876) and validation rule (lines 1889-1891) reference additional actions: Lowercase, Uppercase, KeepEqual, DropEqual — which are not in the enum.
This inconsistency will not cause runtime failures (since invalid actions are rejected at the enum level), but it creates confusing documentation and suggests an incomplete implementation.
Either add the missing actions to the enum if they should be supported, or update the description and validation rule to only reference the actions that exist in the enum.
🔧 Suggested fix: Update validation rule to match enum
If the additional actions are not intended to be supported, update the validation:
x-kubernetes-validations:
- message: targetLabel is required when action is Replace,
- HashMod, Lowercase, Uppercase, KeepEqual or DropEqual,
+ HashMod, LabelMap, LabelDrop, or LabelKeep,
and forbidden otherwise
- rule: 'self.action in [''Replace'', ''HashMod'', ''Lowercase'',
- ''Uppercase'', ''KeepEqual'', ''DropEqual''] ? (has(self.targetLabel)
+ rule: 'self.action in [''Replace'', ''HashMod''] ? (has(self.targetLabel)
&& size(self.targetLabel) > 0) : !has(self.targetLabel)'And update the description at line 1876 accordingly.
Alternatively, if Lowercase, Uppercase, KeepEqual, DropEqual should be supported, add them to the enum.
Also applies to: 1873-1891
🤖 Prompt for AI Agents
In
`@payload-manifests/crds/0000_10_config-operator_01_clustermonitorings-CustomNoUpgrade.crd.yaml`
around lines 1803 - 1811, The action enum for RelabelConfig currently lists
Replace, Keep, Drop, HashMod, LabelMap, LabelDrop, LabelKeep but the targetLabel
description and its validation rule mention Lowercase, Uppercase, KeepEqual,
DropEqual; update either the enum or the docs/validation so they match: either
add the missing actions (Lowercase, Uppercase, KeepEqual, DropEqual) to the
action enum or remove/replace those action names from the targetLabel
description and the validation pattern so they only reference the existing enum
values; locate the enum block named "action" and the "targetLabel"
description/validation in this CRD and make the change consistently across both
sections.
|
@CodeRabbit ignore |
✅ Actions performedReviews paused. |
| // Valid values are "None" (no authentication) and "BearerToken" (bearer token authentication). | ||
| // When set to None, no authentication credentials are sent. |
There was a problem hiding this comment.
The parent field in which this is used is optional, and based on the godoc when omitted it means that it performs no authentication (the same as specifying None).
We try to only have one way of saying something, so either the omission of the parent field, or setting this field to None should be the only way to set no authentication.
I suspect that omission is a more natural indication of no authentication mode, so I'd recommend removing the None option here.
|
@everettraven please take a look to 54882a6 |
everettraven
left a comment
everettraven
left a comment
There was a problem hiding this comment.
The diff between this and my last review was much bigger than I expected - it looks like quite a bit of new fields were added.
I didn't get to finish a full review but wanted to post my current review progress. I'll have to come back to this review tomorrow morning.
openshift-merge-robot
added
the
needs-rebase
marioferh
force-pushed
the
prometheus_k8s_config_api__v2
branch
from
014f5f3 to
1609529
Compare
openshift-merge-robot
removed
the
needs-rebase
| // queueConfig allows tuning configuration for remote write queue parameters. | ||
| // When omitted, default queue configuration is used. |
There was a problem hiding this comment.
That still doesn't explain to a user why they might want to configure this field. We should include that information in the field documentation.
|
#2653 (comment) |
marioferh
force-pushed
the
prometheus_k8s_config_api__v2
branch
from
3884108 to
ba20fed
Compare
| // When omitted, this means no opinion and the platform is left to choose a reasonable default, which is subject to change over time. | ||
| // The default value is "$1" (the first capture group). | ||
| // Must be at most 255 characters in length. | ||
| // +optional |
There was a problem hiding this comment.
The above looks like it was made required - should this be required as well?
marioferh
force-pushed
the
prometheus_k8s_config_api__v2
branch
from
ba20fed to
ceb48de
Compare
openshift-merge-robot
added
the
needs-rebase
marioferh
force-pushed
the
prometheus_k8s_config_api__v2
branch
from
f355c34 to
5823bf9
Compare
openshift-merge-robot
added
needs-rebase
|
/retest |
|
/test e2e-aws-ovn-hypershift |
|
PR-Agent: could not fine a component named |
|
/pipeline required |
|
Scheduling tests matching the |
|
/verified by @juzhao |
openshift-ci-robot
added
the
verified
|
@juzhao: 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. |
|
/test e2e-aws-ovn-hypershift-conformance |
|
PR-Agent: could not fine a component named |
|
/test e2e-aws-ovn-hypershift |
|
PR-Agent: could not fine a component named |
|
So far, test violations are infra related, let's see how many times do we have to retest |
|
/test e2e-aws-ovn-hypershift-conformance |
|
PR-Agent: could not fine a component named |
|
/test e2e-gcp |
|
PR-Agent: could not fine a component named |
|
/test e2e-aws-ovn-techpreview |
|
PR-Agent: could not fine a component named |
|
/test e2e-aws-ovn-hypershift |
|
PR-Agent: could not fine a component named |
|
/test e2e-gcp |
|
PR-Agent: could not fine a component named |
|
/test e2e-gcp |
|
PR-Agent: could not fine a component named |
|
/test e2e-aws-ovn-hypershift |
|
PR-Agent: could not fine a component named |
|
@marioferh: 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. |
7 participants
This commit introduces a new API to be introduced as a part of the migration in CMO from ConfigMap to CRDs
This pr replaces #2630 because is broken