[do no merge] Add CodeRabbit configuration for runbook reviews

[avlitman]

Configure CodeRabbit to cross-reference runbooks against alert source code in kubevirt org repositories. Includes path-specific review instructions and runbook review guidelines.

[kubevirt-bot]

Thanks for your pull request. Before we can look at it, you'll need to add a 'DCO signoff' to your commits.

📝 Please follow instructions in the contributing guide to update your commits with the DCO

Full details of the Developer Certificate of Origin can be found at developercertificate.org.

The list of commits missing DCO signoff:

• 90f19fc Add CodeRabbit configuration for runbook reviews

Details

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. I understand the commands that are listed here.

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[sourcery-ai]

Hey - I've left some high level feedback:

• The edits to the LowReadyVirtControllersCount and VirtAPIDown runbooks appear to change the alert semantics and even swap components (e.g., virt-controller → virt-handler, virt-api selector → virt-controller), which likely no longer match the underlying alerts; recheck these runbook descriptions and commands against the actual alert definitions to avoid introducing incorrect guidance.
• In the new CodeRabbit configuration, the path-specific instructions impose a strict, verbose alert-context block for every runbook review; consider whether all the listed fields (e.g., full metrics/recording-rule paths and line numbers) are always realistically obtainable by the reviewer tooling, or if some should be optional to avoid frequent unfulfillable requirements.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The edits to the LowReadyVirtControllersCount and VirtAPIDown runbooks appear to change the alert semantics and even swap components (e.g., virt-controller → virt-handler, virt-api selector → virt-controller), which likely no longer match the underlying alerts; recheck these runbook descriptions and commands against the actual alert definitions to avoid introducing incorrect guidance.
- In the new CodeRabbit configuration, the path-specific instructions impose a strict, verbose alert-context block for every runbook review; consider whether all the listed fields (e.g., full metrics/recording-rule paths and line numbers) are always realistically obtainable by the reviewer tooling, or if some should be optional to avoid frequent unfulfillable requirements.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[coderabbitai]

Walkthrough

This PR establishes a CodeRabbit review automation framework for KubeVirt alert runbooks and updates two runbook alert definitions. The .coderabbit.yaml configuration enables path-specific review instructions for markdown runbooks under docs/runbooks/, enforces linting via markdownlint, languagetool, and shellcheck, and configures a knowledge base with linked repositories to facilitate alert definition lookups. The new docs/review-guidelines/runbooks.md documents the review standards: verifying alert definitions across linked repositories, tracing PromQL expressions through metrics and recording rules, validating runbook sections against source code, and enforcing formatting conventions. Two runbooks are then updated: LowReadyVirtControllersCount now specifies zero available replicas over 5 minutes as the trigger and updates the diagnosis command to check virt-handler; VirtAPIDown now describes fewer-than-expected replicas over 5 minutes as a warning-level condition and updates the diagnosis label selector to virt-controller.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 2

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 42591091-8c5c-440d-828a-630a1e7339a7

📥 Commits

Reviewing files that changed from the base of the PR and between 725060d and 90f19fc.

📒 Files selected for processing (4)

• .coderabbit.yaml
• docs/review-guidelines/runbooks.md
• docs/runbooks/LowReadyVirtControllersCount.md
• docs/runbooks/VirtAPIDown.md

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

LowReadyVirtControllersCount runbook semantics drift from the actual alert.

---

Alert source code: kubevirt/kubevirt — pkg/monitoring/rules/alerts/virt-controller.go (line 490)
Alert expr: cluster:kubevirt_virt_controller_ready:sum < cluster:kubevirt_virt_controller_pods_running:count and cluster:kubevirt_virt_controller_ready:sum > 0
Alert for: 10m
Alert labels: severity=warning, operator_health_impact=warning,
kubernetes_operator_part_of=kubevirt, kubernetes_operator_component=kubevirt
Recording rules:

• cluster:kubevirt_virt_controller_ready:sum: sum(kube_pod_status_ready{pod=~'virt-controller-.*', namespace='%s', condition='true'} * on(pod, namespace) kubevirt_virt_controller_ready_status{namespace='%s'}) or vector(0) — kubevirt/kubevirt/pkg/monitoring/rules/recordingrules/virt.go
• cluster:kubevirt_virt_controller_pods_running:count: count(kube_pod_status_phase{pod=~'virt-controller-.*', namespace='%s', phase='Running'} == 1) or vector(0) — kubevirt/kubevirt/pkg/monitoring/rules/recordingrules/virt.go
  Metrics:
• kubevirt_virt_controller_ready_status (gauge): kubevirt/kubevirt/pkg/monitoring/metrics/virt-controller/component_metrics.go (line 440)

---

Line 5-6 says “zero available replicas for 5 minutes,” but this alert is “ready < running and ready > 0 for 10 minutes.”
Line 30 checks virt-handler; the diagnosis must target virt-controller readiness/running state.

Suggested doc fix

-This alert fires when the `virt-controller` deployment has zero available
-replicas for the last 5 minutes.
+This alert fires when `virt-controller` has fewer ready pods than running
+pods for 10 minutes, while at least one pod is still ready.

-   $ kubectl get deployment -n $NAMESPACE virt-handler -o jsonpath='{.status.readyReplicas}'
+   $ kubectl get deployment -n $NAMESPACE virt-controller -o jsonpath='{.status.readyReplicas}'

As per coding guidelines, “Must state the correct firing condition (threshold, duration)” and “kubectl/oc commands must target the correct resources and labels for the component the alert monitors”.

Also applies to: 30-30

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Runbook now documents a different alert than VirtAPIDown.

---

Alert source code: kubevirt/kubevirt — pkg/monitoring/rules/alerts/virt-api.go (line 524)
Alert expr: cluster:kubevirt_virt_api_pods_running:count == 0
Alert for: 10m
Alert labels: severity=critical, operator_health_impact=critical,
kubernetes_operator_part_of=kubevirt, kubernetes_operator_component=kubevirt
Recording rules:

• cluster:kubevirt_virt_api_pods_running:count: count(kube_pod_status_phase{pod=~'virt-api-.*', namespace='%s', phase='Running'} == 1) or vector(0) — kubevirt/kubevirt/pkg/monitoring/rules/recordingrules/virt.go
  Metrics:
• kube_pod_status_phase (gauge): kubevirt/kubevirt/pkg/monitoring/rules/recordingrules/virt.go (line 736)

---

Line 5-6 and Line 10-11 describe a warning-level “fewer replicas for 5 minutes” condition, but this alert is a critical “no running virt-api pods for 10 minutes” condition.
Line 24 also queries kubevirt.io=virt-controller, which is the wrong component for this runbook.

Suggested doc fix

-The `virt-api` deployment has fewer than the expected number of
-replicas available for 5 minutes.
+This alert fires when no `virt-api` pods are running for 10 minutes.

-This is a warning level alert. KubeVirt objects may experience degraded
-API performance.
+This is a critical alert. KubeVirt API operations can become unavailable.

-   $ kubectl -n $NAMESPACE get pods -l kubevirt.io=virt-controller
+   $ kubectl -n $NAMESPACE get pods -l kubevirt.io=virt-api

As per coding guidelines, “Must accurately describe what the PromQL expression evaluates” and “Do the kubectl/oc commands target the correct resources, labels, and namespaces for the component the alert actually monitors?”.

Also applies to: 10-11, 24-24