Skip to content

NETOBSERV-2657: Allow external/contributed recording rules in Network Health#2500

Open
leandroberetta wants to merge 1 commit intonetobserv:mainfrom
leandroberetta:contrib-recording-rules
Open

NETOBSERV-2657: Allow external/contributed recording rules in Network Health#2500
leandroberetta wants to merge 1 commit intonetobserv:mainfrom
leandroberetta:contrib-recording-rules

Conversation

@leandroberetta
Copy link
Contributor

@leandroberetta leandroberetta commented Feb 26, 2026

Description

PrometheusRule CRD won't allow to have annotations in rules of type "record", for this reason, today is not possible to for third party users to bring new recording rules, just alerts. This PR changes that, allowing users to bring their own recording rules using the following convention:

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: my-recording-rules
  namespace: netobserv
  labels:
    netobserv: "true"
  annotations:
    netobserv.io/network-health: |
      {
        "my_metric_per_namespace": {
          "summary": "Custom metric is {{ $value }} in the namespace {{ $labels.namespace }}",
          "description": "Custom metric is {{ $value }} in the namespace {{ $labels.namespace }}",
          "netobserv_io_network_health": "{\"unit\":\"%\",\"upperBound\":\"100\",\"namespaceLabels\":[\"namespace\"],\"recordingThresholds\":{\"info\":\"10\",\"warning\":\"25\",\"critical\":\"50\"}}"
        }
      }
spec:
  groups:
    - name: MyRecordingRules
      interval: 30s
      rules:
        - record: my_metric_per_namespace
          expr: (count by (namespace) (kube_pod_info) * 0 + 20)
          labels:
            netobserv: "true"

Dependencies

netobserv/netobserv-web-console#1311

Checklist

If you are not familiar with our processes or don't know what to answer in the list below, let us know in a comment: the maintainers will take care of that.

  • Is this PR backed with a JIRA ticket? If so, make sure it is written as a title prefix (in general, PRs affecting the NetObserv/Network Observability product should be backed with a JIRA ticket - especially if they bring user facing changes).
  • Does this PR require product documentation?
    • If so, make sure the JIRA epic is labeled with "documentation" and provides a description relevant for doc writers, such as use cases or scenarios. Any required step to activate or configure the feature should be documented there, such as new CRD knobs.
  • Does this PR require a product release notes entry?
    • If so, fill in "Release Note Text" in the JIRA.
  • Is there anything else the QE team should know before testing? E.g: configuration changes, environment setup, etc.
    • If so, make sure it is described in the JIRA ticket.
  • QE requirements (check 1 from the list):
    • Standard QE validation, with pre-merge tests unless stated otherwise.
    • Regression tests only (e.g. refactoring with no user-facing change).
    • No QE (e.g. trivial change with high reviewer's confidence, or per agreement with the QE team).

@leandroberetta leandroberetta requested a review from jotak February 26, 2026 21:31
@leandroberetta leandroberetta self-assigned this Feb 26, 2026
@leandroberetta leandroberetta changed the title Allow non-builtin (external/contributed) recording rules in Network Health Allow external/contributed recording rules in Network Health Feb 26, 2026
@codecov
Copy link

codecov bot commented Feb 27, 2026

Codecov Report

❌ Patch coverage is 40.00000% with 24 lines in your changes missing coverage. Please review.
✅ Project coverage is 72.07%. Comparing base (3baee62) to head (05b1033).
⚠️ Report is 1 commits behind head on main.

Files with missing lines Patch % Lines
...ntroller/consoleplugin/consoleplugin_reconciler.go 23.07% 17 Missing and 3 partials ⚠️
.../controller/consoleplugin/consoleplugin_objects.go 60.00% 1 Missing and 1 partial ⚠️
internal/controller/flowcollector_controller.go 77.77% 1 Missing and 1 partial ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2500      +/-   ##
==========================================
- Coverage   72.39%   72.07%   -0.33%     
==========================================
  Files         105      105              
  Lines       10851    10889      +38     
==========================================
- Hits         7856     7848       -8     
- Misses       2518     2557      +39     
- Partials      477      484       +7     
Flag Coverage Δ
unittests 72.07% <40.00%> (-0.33%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines Coverage Δ
.../controller/consoleplugin/consoleplugin_objects.go 89.95% <60.00%> (-0.34%) ⬇️
internal/controller/flowcollector_controller.go 80.37% <77.77%> (-0.24%) ⬇️
...ntroller/consoleplugin/consoleplugin_reconciler.go 68.00% <23.07%> (-8.00%) ⬇️

... and 4 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@leandroberetta leandroberetta requested a review from jotak March 6, 2026 20:08
jotak
jotak previously approved these changes Mar 9, 2026
Copy link
Member

@jotak jotak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks!
/lgtm

@openshift-ci openshift-ci bot added the lgtm label Mar 9, 2026
@leandroberetta leandroberetta changed the title Allow external/contributed recording rules in Network Health NETOBSERV-2657: Allow external/contributed recording rules in Network Health Mar 9, 2026
@openshift-ci-robot
Copy link
Collaborator

openshift-ci-robot commented Mar 9, 2026

@leandroberetta: This pull request references NETOBSERV-2657 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 the "4.22.0" version, but no target version was set.

Details

In response to this:

Description

PrometheusRule CRD won't allow to have annotations in rules of type "record", for this reason, today is not possible to for third party users to bring new recording rules, just alerts. This PR changes that, allowing users to bring their own recording rules using the following convention:

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
 name: my-recording-rules
 namespace: netobserv
 annotations:
   netobserv.io/recording-annotations: |
     {
       "my_metric_per_namespace": {
         "summary": "Custom metric is {{ $value }} in the namespace {{ $labels.namespace }}",
         "description": "Custom metric is {{ $value }} in the namespace {{ $labels.namespace }}",
         "netobserv_io_network_health": "{\"unit\":\"%\",\"upperBound\":\"100\",\"namespaceLabels\":[\"namespace\"],\"recordingThresholds\":{\"info\":\"10\",\"warning\":\"25\",\"critical\":\"50\"}}"
       }
     }
spec:
 groups:
   - name: MyRecordingRules
     interval: 30s
     rules:
       - record: my_metric_per_namespace
         expr: (count by (namespace) (kube_pod_info) * 0 + 20)
         labels:
           netobserv: "true"

Dependencies

netobserv/netobserv-web-console#1311

Checklist

If you are not familiar with our processes or don't know what to answer in the list below, let us know in a comment: the maintainers will take care of that.

  • Is this PR backed with a JIRA ticket? If so, make sure it is written as a title prefix (in general, PRs affecting the NetObserv/Network Observability product should be backed with a JIRA ticket - especially if they bring user facing changes).
  • Does this PR require product documentation?
  • If so, make sure the JIRA epic is labeled with "documentation" and provides a description relevant for doc writers, such as use cases or scenarios. Any required step to activate or configure the feature should be documented there, such as new CRD knobs.
  • Does this PR require a product release notes entry?
  • If so, fill in "Release Note Text" in the JIRA.
  • Is there anything else the QE team should know before testing? E.g: configuration changes, environment setup, etc.
  • If so, make sure it is described in the JIRA ticket.
  • QE requirements (check 1 from the list):
  • Standard QE validation, with pre-merge tests unless stated otherwise.
  • Regression tests only (e.g. refactoring with no user-facing change).
  • No QE (e.g. trivial change with high reviewer's confidence, or per agreement with the QE team).

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.

Copy link
Member

@memodi memodi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @leandroberetta - few questions/comments:

  • could you add documentation for this feature describing the example and the fields that are necessary ?
  • It looks like users can add recording for any metric they would like and it would show up on Network Health page - my concerns is - netobserv NS is deleted when flowcollector is deleted and users would lose their rules, I wonder how do we make users aware of this?
  • do we provide hint in UI to differentiate user defined rules?

list := &monitoringv1.PrometheusRuleList{}
if err := cl.List(ctx, list, client.MatchingLabels{"netobserv": "true"}); err != nil {
log.FromContext(ctx).Error(err, "Failed to list PrometheusRules for recording annotations")
return out
Copy link
Member

@memodi memodi Mar 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

when there are transient issues (API request failing etc.) retrieving the rules, it would overwrite existing rules with empty recording rules?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch, I'll fix it.

raw, hasAnnot := pr.Annotations[recordingAnnotationsAnnotation]
if hasAnnot && raw != "" {
var perRule map[string]map[string]string
if err := json.Unmarshal([]byte(raw), &perRule); err != nil {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is simply validating JSON is sufficient? do we want to validate specific fields?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think is ok, but we can improve this on a follow up PR is your ok.

@openshift-ci
Copy link

openshift-ci bot commented Mar 17, 2026

New changes are detected. LGTM label has been removed.

@openshift-ci
Copy link

openshift-ci bot commented Mar 17, 2026

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from jotak. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@leandroberetta
Copy link
Contributor Author

leandroberetta commented Mar 17, 2026

Hi @leandroberetta - few questions/comments:

  • could you add documentation for this feature describing the example and the fields that are necessary ?
  • It looks like users can add recording for any metric they would like and it would show up on Network Health page - my concerns is - netobserv NS is deleted when flowcollector is deleted and users would lose their rules, I wonder how do we make users aware of this?
  • do we provide hint in UI to differentiate user defined rules?

Hi @memodi, sorry for the delay and thanks for the review.

  • could you add documentation for this feature describing the example and the fields that are necessary ?

I added the documentation to the HealthRules.md

  • It looks like users can add recording for any metric they would like and it would show up on Network Health > page - my concerns is - netobserv NS is deleted when flowcollector is deleted and users would lose their rules, I wonder how do we make users aware of this?

PrometheusRules can be on any namespace. I added a mention of this in the docs.

  • do we provide hint in UI to differentiate user defined rules?

We aren't today. I will create an issue for that if you're ok.

@leandroberetta
Copy link
Contributor Author

@memodi in the description of the issue you have a simple HealthRule which you can update to play with the thresholds, the recording rules will appear in the Namespaces tab.

@memodi
Copy link
Member

memodi commented Mar 18, 2026

Hi @leandroberetta - thanks for addressing feedback. could you resolve merge conflicts and add /ok-to-test label after that?

@memodi
Copy link
Member

memodi commented Mar 18, 2026

/ok-to-test

@openshift-ci openshift-ci bot added the ok-to-test To set manually when a PR is safe to test. Triggers image build on PR. label Mar 18, 2026
@github-actions
Copy link

New images:

quay.io/netobserv/network-observability-operator:ff365a2
quay.io/netobserv/network-observability-operator-bundle:v0.0.0-sha-ff365a2
quay.io/netobserv/network-observability-operator-catalog:v0.0.0-sha-ff365a2

They will expire in two weeks.

To deploy this build:

# Direct deployment, from operator repo
IMAGE=quay.io/netobserv/network-observability-operator:ff365a2 make deploy

# Or using operator-sdk
operator-sdk run bundle quay.io/netobserv/network-observability-operator-bundle:v0.0.0-sha-ff365a2

Or as a Catalog Source:

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: netobserv-dev
  namespace: openshift-marketplace
spec:
  sourceType: grpc
  image: quay.io/netobserv/network-observability-operator-catalog:v0.0.0-sha-ff365a2
  displayName: NetObserv development catalog
  publisher: Me
  updateStrategy:
    registryPoll:
      interval: 1m

@github-actions github-actions bot removed the ok-to-test To set manually when a PR is safe to test. Triggers image build on PR. label Mar 18, 2026
@memodi
Copy link
Member

memodi commented Mar 18, 2026

/ok-to-test

@openshift-ci openshift-ci bot added ok-to-test To set manually when a PR is safe to test. Triggers image build on PR. needs-rebase labels Mar 18, 2026
@leandroberetta leandroberetta force-pushed the contrib-recording-rules branch from 87c26ac to 70f4b09 Compare March 18, 2026 22:39
@github-actions github-actions bot removed the ok-to-test To set manually when a PR is safe to test. Triggers image build on PR. label Mar 18, 2026
@memodi
Copy link
Member

memodi commented Mar 19, 2026

/ok-to-test

@openshift-ci openshift-ci bot added the ok-to-test To set manually when a PR is safe to test. Triggers image build on PR. label Mar 19, 2026

### Lifecycle and namespace

Custom PrometheusRules are **not** owned by the FlowCollector. If you put them in the **NetObserv namespace** (e.g. `netobserv`), that namespace may be removed when the FlowCollector is uninstalled (depending on install mode), and your rules would be deleted. To avoid that, create your PrometheusRules in **another namespace** (e.g. `monitoring` or a dedicated `netobserv-rules`); they will still be picked up cluster-wide. If you do keep rules in the NetObserv namespace, back them up (e.g. in Git) and re-apply after reinstalling.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should add that those ns will need:
openshift.io/cluster-monitoring: "true" label

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That annotation is used for letting know Prometheus that that namespace should be scraped. That is not required, but I think the example in the description was outdated and for that reason, you didn't see any rule in the page.

I've updated the docs to improve and add more clarity to the requirements.

A label netobserv true was missing and also the annotaion was renamed some commits ago (now is network-health). Sorry @memodi !

@github-actions github-actions bot removed the ok-to-test To set manually when a PR is safe to test. Triggers image build on PR. label Mar 20, 2026
@openshift-ci-robot
Copy link
Collaborator

openshift-ci-robot commented Mar 20, 2026

@leandroberetta: This pull request references NETOBSERV-2657 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 the "4.22.0" version, but no target version was set.

Details

In response to this:

Description

PrometheusRule CRD won't allow to have annotations in rules of type "record", for this reason, today is not possible to for third party users to bring new recording rules, just alerts. This PR changes that, allowing users to bring their own recording rules using the following convention:

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
 name: my-recording-rules
 namespace: netobserv
 annotations:
   netobserv.io/network-health: |
     {
       "my_metric_per_namespace": {
         "summary": "Custom metric is {{ $value }} in the namespace {{ $labels.namespace }}",
         "description": "Custom metric is {{ $value }} in the namespace {{ $labels.namespace }}",
         "netobserv_io_network_health": "{\"unit\":\"%\",\"upperBound\":\"100\",\"namespaceLabels\":[\"namespace\"],\"recordingThresholds\":{\"info\":\"10\",\"warning\":\"25\",\"critical\":\"50\"}}"
       }
     }
spec:
 groups:
   - name: MyRecordingRules
     interval: 30s
     rules:
       - record: my_metric_per_namespace
         expr: (count by (namespace) (kube_pod_info) * 0 + 20)
         labels:
           netobserv: "true"

Dependencies

netobserv/netobserv-web-console#1311

Checklist

If you are not familiar with our processes or don't know what to answer in the list below, let us know in a comment: the maintainers will take care of that.

  • Is this PR backed with a JIRA ticket? If so, make sure it is written as a title prefix (in general, PRs affecting the NetObserv/Network Observability product should be backed with a JIRA ticket - especially if they bring user facing changes).
  • Does this PR require product documentation?
  • If so, make sure the JIRA epic is labeled with "documentation" and provides a description relevant for doc writers, such as use cases or scenarios. Any required step to activate or configure the feature should be documented there, such as new CRD knobs.
  • Does this PR require a product release notes entry?
  • If so, fill in "Release Note Text" in the JIRA.
  • Is there anything else the QE team should know before testing? E.g: configuration changes, environment setup, etc.
  • If so, make sure it is described in the JIRA ticket.
  • QE requirements (check 1 from the list):
  • Standard QE validation, with pre-merge tests unless stated otherwise.
  • Regression tests only (e.g. refactoring with no user-facing change).
  • No QE (e.g. trivial change with high reviewer's confidence, or per agreement with the QE team).

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.

@openshift-ci-robot
Copy link
Collaborator

openshift-ci-robot commented Mar 20, 2026

@leandroberetta: This pull request references NETOBSERV-2657 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 the "4.22.0" version, but no target version was set.

Details

In response to this:

Description

PrometheusRule CRD won't allow to have annotations in rules of type "record", for this reason, today is not possible to for third party users to bring new recording rules, just alerts. This PR changes that, allowing users to bring their own recording rules using the following convention:

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
 name: my-recording-rules
 namespace: netobserv
 labels:
   netobserv: "true"
 annotations:
   netobserv.io/network-health: |
     {
       "my_metric_per_namespace": {
         "summary": "Custom metric is {{ $value }} in the namespace {{ $labels.namespace }}",
         "description": "Custom metric is {{ $value }} in the namespace {{ $labels.namespace }}",
         "netobserv_io_network_health": "{\"unit\":\"%\",\"upperBound\":\"100\",\"namespaceLabels\":[\"namespace\"],\"recordingThresholds\":{\"info\":\"10\",\"warning\":\"25\",\"critical\":\"50\"}}"
       }
     }
spec:
 groups:
   - name: MyRecordingRules
     interval: 30s
     rules:
       - record: my_metric_per_namespace
         expr: (count by (namespace) (kube_pod_info) * 0 + 20)
         labels:
           netobserv: "true"

Dependencies

netobserv/netobserv-web-console#1311

Checklist

If you are not familiar with our processes or don't know what to answer in the list below, let us know in a comment: the maintainers will take care of that.

  • Is this PR backed with a JIRA ticket? If so, make sure it is written as a title prefix (in general, PRs affecting the NetObserv/Network Observability product should be backed with a JIRA ticket - especially if they bring user facing changes).
  • Does this PR require product documentation?
  • If so, make sure the JIRA epic is labeled with "documentation" and provides a description relevant for doc writers, such as use cases or scenarios. Any required step to activate or configure the feature should be documented there, such as new CRD knobs.
  • Does this PR require a product release notes entry?
  • If so, fill in "Release Note Text" in the JIRA.
  • Is there anything else the QE team should know before testing? E.g: configuration changes, environment setup, etc.
  • If so, make sure it is described in the JIRA ticket.
  • QE requirements (check 1 from the list):
  • Standard QE validation, with pre-merge tests unless stated otherwise.
  • Regression tests only (e.g. refactoring with no user-facing change).
  • No QE (e.g. trivial change with high reviewer's confidence, or per agreement with the QE team).

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.

@leandroberetta leandroberetta force-pushed the contrib-recording-rules branch from 64d29d5 to 05b1033 Compare March 20, 2026 15:02
@memodi
Copy link
Member

memodi commented Mar 24, 2026

/ok-to-test

@openshift-ci openshift-ci bot added the ok-to-test To set manually when a PR is safe to test. Triggers image build on PR. label Mar 24, 2026
@github-actions
Copy link

New images:

quay.io/netobserv/network-observability-operator:305b85f
quay.io/netobserv/network-observability-operator-bundle:v0.0.0-sha-305b85f
quay.io/netobserv/network-observability-operator-catalog:v0.0.0-sha-305b85f

They will expire in two weeks.

To deploy this build:

# Direct deployment, from operator repo
IMAGE=quay.io/netobserv/network-observability-operator:305b85f make deploy

# Or using operator-sdk
operator-sdk run bundle quay.io/netobserv/network-observability-operator-bundle:v0.0.0-sha-305b85f

Or as a Catalog Source:

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: netobserv-dev
  namespace: openshift-marketplace
spec:
  sourceType: grpc
  image: quay.io/netobserv/network-observability-operator-catalog:v0.0.0-sha-305b85f
  displayName: NetObserv development catalog
  publisher: Me
  updateStrategy:
    registryPoll:
      interval: 1m

@memodi
Copy link
Member

memodi commented Mar 24, 2026

/label qe-approved

thanks @leandroberetta

@openshift-ci openshift-ci bot added the qe-approved QE has approved this pull request label Mar 24, 2026
@openshift-ci-robot
Copy link
Collaborator

openshift-ci-robot commented Mar 24, 2026

@leandroberetta: This pull request references NETOBSERV-2657 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 the "4.22.0" version, but no target version was set.

Details

In response to this:

Description

PrometheusRule CRD won't allow to have annotations in rules of type "record", for this reason, today is not possible to for third party users to bring new recording rules, just alerts. This PR changes that, allowing users to bring their own recording rules using the following convention:

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
 name: my-recording-rules
 namespace: netobserv
 labels:
   netobserv: "true"
 annotations:
   netobserv.io/network-health: |
     {
       "my_metric_per_namespace": {
         "summary": "Custom metric is {{ $value }} in the namespace {{ $labels.namespace }}",
         "description": "Custom metric is {{ $value }} in the namespace {{ $labels.namespace }}",
         "netobserv_io_network_health": "{\"unit\":\"%\",\"upperBound\":\"100\",\"namespaceLabels\":[\"namespace\"],\"recordingThresholds\":{\"info\":\"10\",\"warning\":\"25\",\"critical\":\"50\"}}"
       }
     }
spec:
 groups:
   - name: MyRecordingRules
     interval: 30s
     rules:
       - record: my_metric_per_namespace
         expr: (count by (namespace) (kube_pod_info) * 0 + 20)
         labels:
           netobserv: "true"

Dependencies

netobserv/netobserv-web-console#1311

Checklist

If you are not familiar with our processes or don't know what to answer in the list below, let us know in a comment: the maintainers will take care of that.

  • Is this PR backed with a JIRA ticket? If so, make sure it is written as a title prefix (in general, PRs affecting the NetObserv/Network Observability product should be backed with a JIRA ticket - especially if they bring user facing changes).
  • Does this PR require product documentation?
  • If so, make sure the JIRA epic is labeled with "documentation" and provides a description relevant for doc writers, such as use cases or scenarios. Any required step to activate or configure the feature should be documented there, such as new CRD knobs.
  • Does this PR require a product release notes entry?
  • If so, fill in "Release Note Text" in the JIRA.
  • Is there anything else the QE team should know before testing? E.g: configuration changes, environment setup, etc.
  • If so, make sure it is described in the JIRA ticket.
  • QE requirements (check 1 from the list):
  • Standard QE validation, with pre-merge tests unless stated otherwise.
  • Regression tests only (e.g. refactoring with no user-facing change).
  • No QE (e.g. trivial change with high reviewer's confidence, or per agreement with the QE team).

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

jira/valid-reference ok-to-test To set manually when a PR is safe to test. Triggers image build on PR. qe-approved QE has approved this pull request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants