Skip to content

feat: Add defaultVolumesToFsBackup field to Backup#2654

Open
qwang1 wants to merge 1 commit intoRedHatQE:mainfrom
qwang1:qwang-backup-add
Open

feat: Add defaultVolumesToFsBackup field to Backup#2654
qwang1 wants to merge 1 commit intoRedHatQE:mainfrom
qwang1:qwang-backup-add

Conversation

@qwang1
Copy link
Contributor

@qwang1 qwang1 commented Feb 18, 2026

According to the velero code definition:
// DefaultVolumesToFsBackup specifies whether pod volume file system backup should be used
// for all volumes by default.
// +optional
// +nullable
DefaultVolumesToFsBackup *bool json:"defaultVolumesToFsBackup,omitempty"

Short description:
More details:
What this PR does / why we need it:
Which issue(s) this PR fixes:
Special notes for reviewer:
Bug:

Summary by CodeRabbit

  • New Features
    • Added a new configuration option to control default filesystem backup behavior for volumes, providing users with additional flexibility in backup operations.

@coderabbitai
Copy link

coderabbitai bot commented Feb 18, 2026

Walkthrough

Adds an optional default_volumes_to_fs_backup parameter to Backup.__init__, stores it on the instance, and serializes it as defaultVolumesToFsBackup in to_dict only when the value is not None.

Changes

Cohort / File(s) Summary
Backup Configuration
ocp_resources/backup.py
Added optional `default_volumes_to_fs_backup: bool

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

🚥 Pre-merge checks | ✅ 1 | ❌ 2

❌ Failed checks (2 warnings)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
Description check ⚠️ Warning PR description lacks required sections; only shows Velero code reference with empty template placeholders for short description, details, rationale, issues, reviewer notes, and bug references. Fill in all required template sections: provide a clear short description, explain why this field is needed, reference related issues, add any special notes for reviewers, and specify if fixing any bugs.
✅ Passed checks (1 passed)
Check name Status Explanation
Title check ✅ Passed The title directly matches the main change: adding a new field to the Backup class.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

Tip

Try Coding Plans. Let us write the prompt for your AI agent so you can ship faster (with fewer bugs).
Share your feedback on Discord.


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

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

@redhat-qe-bot
Copy link
Contributor

Report bugs in Issues

Welcome! 🎉

This pull request will be automatically processed with the following features:

🔄 Automatic Actions

  • Reviewer Assignment: Reviewers are automatically assigned based on the OWNERS file in the repository root
  • Size Labeling: PR size labels (XS, S, M, L, XL, XXL) are automatically applied based on changes
  • Issue Creation: Disabled for this repository
  • Branch Labeling: Branch-specific labels are applied to track the target branch
  • Auto-verification: Auto-verified users have their PRs automatically marked as verified
  • Labels: All label categories are enabled (default configuration)

📋 Available Commands

PR Status Management

  • /wip - Mark PR as work in progress (adds WIP: prefix to title)
  • /wip cancel - Remove work in progress status
  • /hold - Block PR merging (approvers only)
  • /hold cancel - Unblock PR merging
  • /verified - Mark PR as verified
  • /verified cancel - Remove verification status
  • /reprocess - Trigger complete PR workflow reprocessing (useful if webhook failed or configuration changed)
  • /regenerate-welcome - Regenerate this welcome message

Review & Approval

  • /lgtm - Approve changes (looks good to me)
  • /approve - Approve PR (approvers only)
  • /automerge - Enable automatic merging when all requirements are met (maintainers and approvers only)
  • /assign-reviewers - Assign reviewers based on OWNERS file
  • /assign-reviewer @username - Assign specific reviewer
  • /check-can-merge - Check if PR meets merge requirements

Testing & Validation

  • /retest tox - Run Python test suite with tox
  • /retest python-module-install - Test Python package installation
  • /retest conventional-title - Validate commit message format
  • /retest all - Run all available tests

Cherry-pick Operations

  • /cherry-pick <branch> - Schedule cherry-pick to target branch when PR is merged
    • Multiple branches: /cherry-pick branch1 branch2 branch3

Label Management

  • /<label-name> - Add a label to the PR
  • /<label-name> cancel - Remove a label from the PR

✅ Merge Requirements

This PR will be automatically approved when the following conditions are met:

  1. Approval: /approve from at least one approver
  2. LGTM Count: Minimum 0 /lgtm from reviewers
  3. Status Checks: All required status checks must pass
  4. No Blockers: No WIP, hold, conflict labels
  5. Verified: PR must be marked as verified (if verification is enabled)

📊 Review Process

Approvers and Reviewers

Approvers:

  • myakove
  • rnetser

Reviewers:

  • myakove
  • rnetser
Available Labels
  • hold
  • verified
  • wip
  • lgtm
  • approve
  • automerge

💡 Tips

  • WIP Status: Use /wip when your PR is not ready for review
  • Verification: The verified label is automatically removed on each new commit
  • Cherry-picking: Cherry-pick labels are processed when the PR is merged
  • Permission Levels: Some commands require approver permissions
  • Auto-verified Users: Certain users have automatic verification and merge privileges

For more information, please refer to the project documentation or contact the maintainers.

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: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
ocp_resources/backup.py (1)

23-32: ⚠️ Potential issue | 🟡 Minor

Add docstring entry for the new default_volumes_to_fs_backup parameter.

The Args block documents every other parameter but omits default_volumes_to_fs_backup.

📝 Proposed fix
             snapshot_move_data (bool, optional): If set to true, deploys the volume snapshot mover
                 controller and a modified CSI Data Mover plugin.
+            default_volumes_to_fs_backup (bool, optional): If set to true, all pod volumes are backed
+                up via file system backup by default.
             storage_location (string, optional): Define the location for the DataMover.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@ocp_resources/backup.py` around lines 23 - 32, The docstring Args block is
missing an entry for the new parameter default_volumes_to_fs_backup; update the
existing docstring in ocp_resources/backup.py (the function/class docstring that
currently lists included_namespaces, excluded_resources, snapshot_move_data,
storage_location) to add a line describing default_volumes_to_fs_backup (bool,
optional): explain its default behavior and what enabling it does (e.g., whether
volumes are backed up as filesystem snapshots by default), matching the style of
the other parameter entries.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@ocp_resources/backup.py`:
- Around line 59-61: In to_dict() fix the unconditional emission of
spec_dict["defaultVolumesToFsBackup"] — instead of always writing False when
self.default_volumes_to_fs_backup is None, only set
spec_dict["defaultVolumesToFsBackup"] when self.default_volumes_to_fs_backup is
not None (so an explicit False is preserved but None omits the key); locate the
logic around the default_volumes_to_fs_backup attribute in the to_dict() method
and change the assignment to a conditional presence check before adding the
"defaultVolumesToFsBackup" key.

---

Outside diff comments:
In `@ocp_resources/backup.py`:
- Around line 23-32: The docstring Args block is missing an entry for the new
parameter default_volumes_to_fs_backup; update the existing docstring in
ocp_resources/backup.py (the function/class docstring that currently lists
included_namespaces, excluded_resources, snapshot_move_data, storage_location)
to add a line describing default_volumes_to_fs_backup (bool, optional): explain
its default behavior and what enabling it does (e.g., whether volumes are backed
up as filesystem snapshots by default), matching the style of the other
parameter entries.

According to the velero code definition:
// DefaultVolumesToFsBackup specifies whether pod volume file system backup should be used
// for all volumes by default.
// +optional
// +nullable
DefaultVolumesToFsBackup *bool `json:"defaultVolumesToFsBackup,omitempty"`

Signed-off-by: Qixuan Wang <qwang@redhat.com>
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.

🧹 Nitpick comments (1)
ocp_resources/backup.py (1)

24-32: Add missing docstring entry for the new constructor parameter.

default_volumes_to_fs_backup was added to __init__ but is not documented in the Args section yet.

📝 Proposed docstring patch
         Args:
             included_namespaces (list, optional): Namespaces to include in the backup.
                 If unspecified, all namespaces are included.
             excluded_resources (list, optional): Resources to exclude from the backup.
                 Resources may be shortcuts (e.g. 'po' for 'pods') or fully-qualified.
             snapshot_move_data (bool, optional): If set to true, deploys the volume snapshot mover
                 controller and a modified CSI Data Mover plugin.
+            default_volumes_to_fs_backup (bool | None, optional): Controls whether pod volumes
+                are backed up with file-system backup by default. If None, the field is omitted.
             storage_location (string, optional): Define the location for the DataMover.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@ocp_resources/backup.py` around lines 24 - 32, The docstring for the class
constructor is missing documentation for the new parameter
default_volumes_to_fs_backup; update the Args section in the __init__ docstring
to add an entry describing default_volumes_to_fs_backup (type: bool, optional)
and its behavior (e.g., whether volumes default to filesystem backup vs block,
default value, and effect on snapshot_move_data or DataMover behavior) so
callers understand the new parameter semantics and default.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@ocp_resources/backup.py`:
- Around line 24-32: The docstring for the class constructor is missing
documentation for the new parameter default_volumes_to_fs_backup; update the
Args section in the __init__ docstring to add an entry describing
default_volumes_to_fs_backup (type: bool, optional) and its behavior (e.g.,
whether volumes default to filesystem backup vs block, default value, and effect
on snapshot_move_data or DataMover behavior) so callers understand the new
parameter semantics and default.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: e4e1da38-485e-491e-83f4-efb9a1267bc6

📥 Commits

Reviewing files that changed from the base of the PR and between 572ca2e and 76bff35.

📒 Files selected for processing (1)
  • ocp_resources/backup.py

Copy link
Collaborator

@rnetser rnetser left a comment

Choose a reason for hiding this comment

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

please use the class-generator to generate the resource

@qwang1
Copy link
Contributor Author

qwang1 commented Mar 5, 2026

@rnetser How to generate backup.velero.io resources?

$ class-generator -k Backup --dry-run

will generate Resource.ApiGroup.POSTGRESQL_CNPG_NOOBAA_IO, which is not my target.
Because there are serveral backup CRDs in the cluster:

[cloud-user@worker1 openshift-python-wrapper]$ oc get crd | grep backup
backuprepositories.velero.io                                               2026-03-04T14:41:56Z
backups.postgresql.cnpg.noobaa.io                                          2026-03-04T14:28:30Z
backups.velero.io                                                          2026-03-04T14:41:56Z
backupstoragelocations.velero.io                                           2026-03-04T14:41:56Z
deletebackuprequests.velero.io                                             2026-03-04T14:41:56Z
nonadminbackups.oadp.openshift.io                                          2026-03-04T14:41:56Z
nonadminbackupstoragelocationrequests.oadp.openshift.io                    2026-03-04T14:41:56Z
nonadminbackupstoragelocations.oadp.openshift.io                           2026-03-04T14:41:56Z
podvolumebackups.velero.io                                                 2026-03-04T14:41:57Z
scheduledbackups.postgresql.cnpg.noobaa.io                                 2026-03-04T14:28:31Z

Then I did:

$ oc version -o json | jq -r '.openshiftVersion'

$ echo "4.21.4" > class_generator/__cluster_version__.txt

$ class-generator --update-schema

Schema was updated successfully. Checking mapping, I got

$ zcat class_generator/schema/__resources-mappings.json.gz | jq '.Backup'
null

Since no mapping for Backup, why did it could generate backups.postgresql.cnpg.noobaa.io?

If I tried different ways:

[cloud-user@worker1 openshift-python-wrapper]$ class-generator -k backups.velero.io --dry-run
2026-03-05T09:09:54.068760 class_generator INFO Generating class for backups.velero.io
backups.velero.io not found in class_generator/schema/__resources-mappings.json, Do you want to run --update-schema and retry? [Y/N]y
......
2026-03-05T09:10:14.219229 class_generator INFO Schema update completed successfully
2026-03-05T09:10:14.250089 class_generator INFO Generating class for backups.velero.io
2026-03-05T09:10:14.250428 class_generator ERROR backups.velero.io not found in class_generator/schema/__resources-mappings.json after update-schema executed.

Seems class-generator doesn't support -k CRD.

I exported backups.velero.io and put it under class_generator/schema/velero.io_Backup.json

[cloud-user@worker1 openshift-python-wrapper]$ jq '.spec.names' class_generator/schema/velero.io_Backup.json
{
  "kind": "Backup",
  "listKind": "BackupList",
  "plural": "backups",
  "singular": "backup"
}
[cloud-user@worker1 openshift-python-wrapper]$ class-generator --schema class_generator/schema/velero.io_Backup.json --dry-run
Usage: class-generator [OPTIONS]
Try 'class-generator --help' for help.

Error: No such option: --schema (Possible options: --update-schema, --use-cache)

Seems class-generator doesn't support using specific schema.

$ class-generator --kind Backup --api-group velero.io --dry-run
Usage: class-generator [OPTIONS]
Try 'class-generator --help' for help.

Error: No such option: --api-group

$ class-generator --kind Backup --api-version velero.io/v1 --dry-run
Usage: class-generator [OPTIONS]
Try 'class-generator --help' for help.

Error: No such option: --api-version

Where did I go wrong?

@qwang1
Copy link
Contributor Author

qwang1 commented Mar 5, 2026

@rnetser Is it possible to merge the tiny change and then I will open a new PR to use class generator for the whole backup.py?

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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants