Skip to content

Conversation

@kaovilai
Copy link
Member

@kaovilai kaovilai commented Nov 5, 2025

  • Introduced PriorityClassName field in PodConfig struct to allow specification of pod priority.
  • Updated CRD and related manifests to include PriorityClassName description.
  • Modified NodeAgent and Velero deployment builders to utilize PriorityClassName from DataProtectionApplication spec.
  • Enhanced tests to validate PriorityClassName functionality in NodeAgent and Velero deployments.

Why the changes were made

How to test the changes made

- Introduced PriorityClassName field in PodConfig struct to allow specification of pod priority.
- Updated CRD and related manifests to include PriorityClassName description.
- Modified NodeAgent and Velero deployment builders to utilize PriorityClassName from DataProtectionApplication spec.
- Enhanced tests to validate PriorityClassName functionality in NodeAgent and Velero deployments.
@openshift-ci-robot openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Nov 5, 2025
@openshift-ci-robot
Copy link

openshift-ci-robot commented Nov 5, 2025

@kaovilai: This pull request references OADP-2785 which is a valid jira issue.

In response to this:

  • Introduced PriorityClassName field in PodConfig struct to allow specification of pod priority.
  • Updated CRD and related manifests to include PriorityClassName description.
  • Modified NodeAgent and Velero deployment builders to utilize PriorityClassName from DataProtectionApplication spec.
  • Enhanced tests to validate PriorityClassName functionality in NodeAgent and Velero deployments.

Why the changes were made

How to test the changes made

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.

@coderabbitai
Copy link

coderabbitai bot commented Nov 5, 2025

Walkthrough

Adds an optional PriorityClassName to PodConfig, updates CRD schemas to expose the field, and propagates the value into NodeAgent DaemonSet and Velero Deployment pod specs with accompanying tests.

Changes

Cohort / File(s) Summary
API Type Definition
api/v1alpha1/dataprotectionapplication_types.go
Added PriorityClassName string json:"priorityClassName,omitempty"toPodConfig`.
CRD Manifests and Schemas
bundle/manifests/.../oadp.openshift.io_dataprotectionapplications.yaml, config/crd/bases/.../oadp.openshift.io_dataprotectionapplications.yaml
Inserted priorityClassName (string) into Pod spec schema blocks in three locations in each CRD file.
NodeAgent Implementation & Tests
internal/controller/nodeagent.go, internal/controller/nodeagent_test.go
Propagates Spec.Configuration.NodeAgent.PodConfig.PriorityClassName into the NodeAgent DaemonSet (Spec.Template.Spec.PriorityClassName). Tests updated/added to assert presence/absence.
Velero Implementation & Tests
internal/controller/velero.go, internal/controller/velero_test.go
Propagates Spec.Configuration.Velero.PodConfig.PriorityClassName into the Velero Deployment (Spec.Template.Spec.PriorityClassName). Tests updated/added and test helper structs extended.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

  • Check CRD YAML insertions for correct schema placement, YAML formatting, and consistency across the three locations.
  • Verify controllers set Spec.Template.Spec.PriorityClassName only when provided and do not alter other PodSpec fields.
  • Review tests to ensure both present/absent cases are covered and helper constructors correctly set PriorityClassName.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Cache: Disabled due to data retention organization setting

Knowledge base: Disabled due to Reviews -> Disable Knowledge Base setting

📥 Commits

Reviewing files that changed from the base of the PR and between c24396c and 5e23ee3.

📒 Files selected for processing (2)
  • internal/controller/nodeagent_test.go (3 hunks)
  • internal/controller/velero_test.go (3 hunks)
🔇 Additional comments (6)
internal/controller/velero_test.go (3)

617-635: LGTM: Struct field addition follows established patterns.

The priorityClassName field is correctly added to TestBuiltVeleroDeploymentOptions and follows the same pattern as other optional pod-level configuration fields.


774-777: LGTM: Implementation correctly propagates PriorityClassName.

The conditional assignment follows the same pattern as other optional fields and correctly sets Spec.Template.Spec.PriorityClassName only when a value is provided.


1038-1083: LGTM: Comprehensive test coverage with both positive and negative cases.

Both test cases are well-structured:

  • Lines 1038-1061: Validates PriorityClassName propagation when set
  • Lines 1062-1083: Validates field remains empty when not specified

The negative test case addresses the concern raised in previous reviews to explicitly test the scenario where PodConfig is present but PriorityClassName is omitted.

internal/controller/nodeagent_test.go (3)

258-258: LGTM: Struct field addition is consistent and well-placed.

The priorityClassName field is correctly added to TestBuiltNodeAgentDaemonSetOptions and follows the established pattern for optional pod-level configuration.


571-573: LGTM: Implementation correctly propagates PriorityClassName to DaemonSet.

The conditional assignment follows the same pattern as the Velero implementation and correctly sets Spec.Template.Spec.PriorityClassName only when a value is provided.


714-759: LGTM: Comprehensive test coverage addresses previous review feedback.

Both test cases provide thorough coverage:

  • Lines 714-737: Validates PriorityClassName propagation when set to "node-agent-critical"
  • Lines 738-759: Validates field remains empty when PodConfig exists but PriorityClassName is omitted

The negative test case at lines 738-759 directly addresses the concern raised in the previous review comment, which requested an explicit test where PodConfig is present but PriorityClassName is not set. This follows the same pattern as other PodConfig field tests (Env at line 613, labels at line 639, annotations at line 689).

Based on learnings


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

@openshift-ci openshift-ci bot requested review from mpryc and sseago November 5, 2025 17:27
@openshift-ci
Copy link

openshift-ci bot commented Nov 5, 2025

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: kaovilai

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

The pull request process is described here

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

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Nov 5, 2025
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 2

🧹 Nitpick comments (3)
internal/controller/nodeagent.go (2)

362-367: Mirror the safer pattern used for Velero

Prefer computing the string with guards and passing it without an IIFE for readability and consistency.

Apply this diff:

-        install.WithPriorityClassName(func() string {
-            if dpa.Spec.Configuration.NodeAgent != nil && dpa.Spec.Configuration.NodeAgent.PodConfig != nil {
-                return dpa.Spec.Configuration.NodeAgent.PodConfig.PriorityClassName
-            }
-            return ""
-        }()),
+        func() install.Option {
+            pc := ""
+            if dpa.Spec.Configuration != nil &&
+               dpa.Spec.Configuration.NodeAgent != nil &&
+               dpa.Spec.Configuration.NodeAgent.PodConfig != nil {
+                pc = dpa.Spec.Configuration.NodeAgent.PodConfig.PriorityClassName
+            }
+            return install.WithPriorityClassName(pc)
+        }(),

303-307: Nit: event message says “deployment” for a DaemonSet

Use “daemonset” to avoid confusion in events.

-            fmt.Sprintf("performed %s on NodeAgent deployment %s/%s", op, ds.Namespace, ds.Name),
+            fmt.Sprintf("performed %s on NodeAgent daemonset %s/%s", op, ds.Namespace, ds.Name),
internal/controller/nodeagent_test.go (1)

571-573: PriorityClassName assignment OK; consider simplifying

You can set PriorityClassName unconditionally (zero-value is “”) to reduce branching. Behavior is identical.

- if len(options.priorityClassName) > 0 {
-   testBuiltNodeAgentDaemonSet.Spec.Template.Spec.PriorityClassName = options.priorityClassName
- }
+ testBuiltNodeAgentDaemonSet.Spec.Template.Spec.PriorityClassName = options.priorityClassName
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Cache: Disabled due to data retention organization setting

Knowledge base: Disabled due to Reviews -> Disable Knowledge Base setting

📥 Commits

Reviewing files that changed from the base of the PR and between 5048a8f and c24396c.

📒 Files selected for processing (7)
  • api/v1alpha1/dataprotectionapplication_types.go (1 hunks)
  • bundle/manifests/oadp.openshift.io_dataprotectionapplications.yaml (3 hunks)
  • config/crd/bases/oadp.openshift.io_dataprotectionapplications.yaml (3 hunks)
  • internal/controller/nodeagent.go (1 hunks)
  • internal/controller/nodeagent_test.go (3 hunks)
  • internal/controller/velero.go (1 hunks)
  • internal/controller/velero_test.go (3 hunks)
🔇 Additional comments (7)
api/v1alpha1/dataprotectionapplication_types.go (1)

365-367: API change is correct

Optional PriorityClassName on PodConfig with the expected json tag aligns with the CRD.

config/crd/bases/oadp.openshift.io_dataprotectionapplications.yaml (1)

497-499: Bundle is in sync with base CRD

Verification confirms priorityClassName is present at all three locations in the bundle (497–499, 854–856, 1374–1376) with consistent field definitions. The change has been properly propagated.

internal/controller/nodeagent_test.go (1)

258-259: New test option field looks good

The addition aligns with PodSpec’s string field. No issues.

bundle/manifests/oadp.openshift.io_dataprotectionapplications.yaml (1)

497-500: CRD schema additions are correct and consistent

All verification checks passed:

  • API type has correct json tag: api/v1alpha1/dataprotectionapplication_types.go:367
  • Base and bundle CRDs are in sync with 3 priorityClassName occurrences each (nodeAgent, restic, velero)
  • Velero controller correctly applies the field from dpa.Spec.Configuration.Velero.PodConfig.PriorityClassName (velero.go:204-209)
  • NodeAgent controller correctly applies the field from dpa.Spec.Configuration.NodeAgent.PodConfig.PriorityClassName (nodeagent.go:362-367)
  • Restic field exists in CRD for backwards compatibility despite being deprecated in favor of nodeAgent
internal/controller/velero_test.go (3)

634-634: LGTM! Clean addition of the test option field.

The priorityClassName field addition follows the existing naming conventions and patterns in the test helper struct.


774-777: LGTM! Correct implementation of PriorityClassName assignment.

The conditional logic properly checks for a non-empty string before setting the field on the deployment's pod template spec, following the same pattern as other optional fields in this helper function.


1038-1061: LGTM! Comprehensive test coverage for PriorityClassName feature.

The test case properly validates that a PriorityClassName specified in the DPA's PodConfig is correctly propagated to the Velero deployment. The test follows established patterns and uses realistic test data.

@kaovilai
Copy link
Member Author

kaovilai commented Nov 5, 2025

@coderabbitai help

@coderabbitai
Copy link

coderabbitai bot commented Nov 5, 2025

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

CodeRabbit commands

These commands are invoked using PR/Issue comments.

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai evaluate custom pre-merge check --instructions <custom-checks-instructions> --name <custom-checks-title> [--mode <error|warning>] to validate the custom pre-merge checks instructions. Defaults to error when --mode is omitted.
    • @coderabbitai ignore pre-merge checks to override pre-merge checks and get an approval on PR.
    • @coderabbitai run pre-merge checks to run pre-merge checks on the pull request.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
  • @coderabbitai generate unit tests to generate unit tests for this PR.
  • @coderabbitai resolve to resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore or @coderabbit ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit configuration file (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Status, support, documentation and community

  • Visit our status page to check the current availability of CodeRabbit.
  • Create a ticket on our support page for assistance with any issues or questions.
  • Visit our documentation site for detailed information on how to use CodeRabbit.
  • Join our Discord community to connect with other users and get help from the community.
  • Follow us on X/Twitter for updates and announcements.

@kaovilai
Copy link
Member Author

kaovilai commented Nov 5, 2025

/retest

ai-retester: The e2e test failed because the "Mongo application CSI" test timed out after 540 seconds with the error container "todolist" in pod "todolist-6d7bb9554c-6t2hj" is waiting to start: PodInitializing. Also, the container "test" exited with code 2.

The e2e-test-cli-aws test failed because the Mongo application CSI via CLI test timed out, and the todolist pod was stuck in the PodInitializing state.

The e2e-test-aws step failed because the Mongo application CSI test timed out after 540 seconds due to the todolist pod failing to become ready (container "todolist" in pod "todolist-6d7bb9554c-jkmb5" is waiting to start: PodInitializing).

@kaovilai
Copy link
Member Author

kaovilai commented Nov 5, 2025

/retest

ai-retester: The Mongo application CSI e2e test timed out after 540 seconds waiting for the todolist pod to become ready. This pod was stuck in PodInitializing state.

The pod todolist-6d7bb9554c-cnwld failed to start because it was stuck in PodInitializing. This resulted in the "Mongo application CSI via CLI" test failing due to a timeout.

The e2e-test-aws step failed because the "Mongo application CSI" test timed out and a container exited with a non-zero exit code (2). The todolist Pod wasn't succeeding, indicating issues with the application deployment or test environment.

@kaovilai
Copy link
Member Author

kaovilai commented Nov 6, 2025

/retest

ai-retester: The e2e-test-aws-e2e step failed because the Mongo application CSI test timed out after 540 seconds, and the todolist pod did not succeeded. This happened despite numerous attempts to resolve pod conditions, so the tests failed and the container exited.

The e2e-test-cli-aws-e2e test step failed because the Mongo application CSI via CLI test timed out after 540 seconds, and a pod was stuck in PodInitializing state. This indicates a potential issue with the deployment or configuration of the MongoDB application within the test environment.

The e2e-test-aws step failed because the "Mongo application CSI" test timed out after 540 seconds, and the todolist container in the pod was stuck in the PodInitializing state.

@kaovilai
Copy link
Member Author

kaovilai commented Nov 6, 2025

/retest

@kaovilai
Copy link
Member Author

kaovilai commented Nov 6, 2025

/retest-required

@kaovilai
Copy link
Member Author

kaovilai commented Nov 6, 2025

/retest

ai-retester: The end-to-end test e2e-test-cli-aws failed because the test container in pod e2e-test-cli-aws-e2e exited with code 2, indicating an error during the OADP CLI backup and restore test of a Mongo application. Specifically, the Mongo application CSI via CLI test timed out while waiting for a pod to become ready.

The OADP e2e test failed because the "Mongo application CSI" test timed out after 540 seconds, and the "todolist" application pod failed to initialize.

The e2e-test-aws test failed because the Mongo application CSI end-to-end test timed out after 540 seconds. The todolist container in one of the pods never became ready (PodInitializing), causing the test to hang.

@kaovilai
Copy link
Member Author

kaovilai commented Nov 6, 2025

/retest

ai-retester: The e2e-test-aws step failed because the "Mongo application CSI" test timed out while waiting for the todolist pod to become ready. The error message container "todolist" in pod "todolist-6d7bb9554c-l5c2v" is waiting to start: PodInitializing indicates that the pod got stuck during initialization.

The e2e-test-aws step failed, specifically the test container within the e2e-test-aws-e2e pod exited with an error code 2, indicating a test failure. The Mongo application CSI test timed out trying to get the todolist pod to a running state.

It was a “pod‑not‑ready” failure – the Mongo CSI restore brought up the test Apps, but the todolist container never reached a running state. The Ginkgo Eventually wait hit its timeout with the message

container "todolist" in pod "todolist‑6d7bb9554c‑tbjlr" is waiting to start: PodInitializing

So the restore test failed because the restored pod stayed stuck in the PodInitializing state and never became ready.

@kaovilai
Copy link
Member Author

kaovilai commented Nov 6, 2025

/retest

ai-retester: The e2e-test-cli-aws-e2e step failed because the "Mongo application CSI via CLI" test timed out waiting for the todolist pod to become ready. Specifically, the todolist container was stuck in the "PodInitializing" state which led to a timeout after 540 seconds. Also there was an error during the after each phase: container "todolist" in pod "todolist-6d7bb9554c-jcjlc" is waiting to start: PodInitializing.

The e2e-test-aws step failed because the "Mongo application CSI" test timed out after 540 seconds, failing to verify if the todolist pod succeeded. This pod initialization issue likely prevented the backup and restore process from completing successfully within the allocated time.

The e2e-test-aws step failed because the Mongo application CSI test timed out while waiting for a pod to succeed, resulting in a ContainerFailed error.

@kaovilai
Copy link
Member Author

kaovilai commented Nov 7, 2025

/retest

ai-retester: The e2e tests failed because the "Mongo application CSI" test timed out while waiting for a Pod to succeed, leading to "ContainerFailed" and a failure within the "e2e-test-aws-e2e" step. Specifically, the pod "todolist-6d7bb9554c-x7q2q" in namespace mongo-persistant didn't achieve success.

The e2e test e2e-test-aws failed because the Mongo application CSI test timed out in the test container, causing the pod e2e-test-aws-e2e to fail. Specifically, the pod "todolist-6d7bb9554c-2d4nc" never succeeded and was in the PodInitializing state.

The e2e-test-cli-aws-e2e step failed because one of the e2e tests, Mongo application CSI via CLI, timed out after 540 seconds. The test was trying to verify that a pod (todolist-6d7bb9554c-bvsns) reached a succeeded state, but it kept waiting in the PodInitializing state, eventually causing the timeout.

@kaovilai
Copy link
Member Author

kaovilai commented Nov 7, 2025

/retest

ai-retester: The end-to-end (e2e) test for the oadp-operator, specifically the "Mongo application CSI" test, timed out and failed because a pod (todolist-6d7bb9554c-f264g) was stuck in the PodInitializing state, preventing the test from completing successfully. Additionally, numerous PodCondition checks constantly showed that that Pod was never available through the 45min that failure occured.

The e2e-test-aws end-to-end test failed because the "[It] Mongo application CSI" test timed out after 540 seconds, and the test suite as a whole failed. The todolist pod was stuck in the "PodInitializing" state, preventing the test from succeeding.

The e2e tests failed because the todolist Pod in the mongo-persistent namespace never succeeded, timing out after a significant period. This likely indicates an issue with the application deployment or its connectivity within the test environment.

@kaovilai
Copy link
Member Author

kaovilai commented Nov 7, 2025

/retest

ai-retester: The e2e-test-cli-aws test failed because the Mongo application CSI via CLI test timed out after a long period where the todolist pod remained in the PodInitializing state.

The e2e-test-aws-e2e step, specifically the Mongo application CSI test, failed because the todolist container within the todolist-6d7bb9554c-h8pvc pod remained in the PodInitializing state, eventually timing out. This likely prevented the application from becoming ready, causing the backup and restore test to fail. The container test exited with code 2, reason Error.

The e2e test failed because the Mongo application CSI test timed out after 540 seconds waiting for the todolist pod to become ready, with the error container "todolist" in pod "todolist-6d7bb9554c-phf9s" is waiting to start: PodInitializing.

@kaovilai
Copy link
Member Author

kaovilai commented Nov 7, 2025

/retest

ai-retester: The e2e-test-cli-aws-e2e step failed because the "Mongo application CSI via CLI" test timed out waiting for the todolist pod to become ready. This pod's container was stuck in PodInitializing, preventing the test from completing successfully. Make command also failed because one or more containers exited.

The e2e-test-aws-e2e step failed because the "Mongo application CSI" test timed out waiting for pods to become ready. Specifically, the todolist-6d7bb9554c-5pb7h pod was stuck in the PodInitializing state.

The test blew up because the application pod that backup‑restore‑suite_test.go tried to spin up never got to the Ready state – it hung in PodInitializing. The test waited up to 540 s and timed out with:

container "todolist" in pod "todolist‑6d7bb9554c‑8s57m" is waiting to start: PodInitializing

The failing step was the “Mongo application CSI” test, which creates a todolist pod (a side‑car for a Mongo instance).

In this run the pod that was created from that manifest did not start, so the eventual consistency checks inside the test (Eventually(...)) never satisfied. Consequently the test timed out and was marked a failure. The root cause was that the pod never reached a running state (likely a mis‑configured Deployment/Pod spec or a missing container readiness check that caused the container to stay in the initializing phase).

@kaovilai
Copy link
Member Author

kaovilai commented Nov 7, 2025

/retest

1 similar comment
@kaovilai
Copy link
Member Author

/retest

@openshift-ci
Copy link

openshift-ci bot commented Nov 10, 2025

@kaovilai: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name Commit Details Required Rerun command
ci/prow/4.20-e2e-test-aws 5e23ee3 link false /test 4.20-e2e-test-aws
ci/prow/4.19-e2e-test-aws 5e23ee3 link true /test 4.19-e2e-test-aws
ci/prow/4.19-e2e-test-cli-aws 5e23ee3 link true /test 4.19-e2e-test-cli-aws

Full PR test history. Your PR dashboard.

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.

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

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants