🐛 fix annotations on pvc migration

[stillalearner]

Summary

Copy user-defined annotations from source PVC to destination PVC during transfer-pvc, stripping server-managed annotations that are cluster-specific.

Problem

buildDestinationPVC() copies labels and spec from the source PVC but skips annotations entirely. User-defined annotations (e.g. backup.company.com/schedule: daily) are silently lost on the destination PVC.

Fix

Added stripServerManagedPVCAnnotations() which copies all annotations except those with known server-managed prefixes:

• pv.kubernetes.io/
• volume.kubernetes.io/
• volume.beta.kubernetes.io/
• kubectl.kubernetes.io/

These prefixes cover all K8s distributions (EKS, GKE, AKS, OCP). CSI-specific annotations use these same prefixes on PVCs — the CSI driver name appears in the annotation value (e.g.
volume.kubernetes.io/storage-provisioner: ebs.csi.aws.com), not as a separate key prefix.

User annotations use company/org domain prefixes (backup.company.com/, app.kubernetes.io/) which are never stripped.

Tests

5 test cases for TestStripServerManagedPVCAnnotations:

• nil annotations — returns nil
• empty annotations — returns nil
• user-only annotations — all preserved
• server-managed only — all stripped
• mixed — user preserved, server stripped

Fixes #672

Summary by CodeRabbit

• Bug Fixes

  • Destination persistent volume claims now preserve user-defined annotations while excluding Kubernetes server-managed metadata.
  • Empty annotation sets are handled correctly during PVC transfers.

• Tests

  • Added coverage for nil, empty, user-defined, server-managed, and mixed annotation sets.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 4787edfb-7902-4252-ae4b-9841d67473fd

📥 Commits

Reviewing files that changed from the base of the PR and between 1713da1 and 9b3679c.

📒 Files selected for processing (2)

• cmd/transfer-pvc/transfer-pvc.go
• cmd/transfer-pvc/transfer-pvc_test.go

---

📝 Walkthrough

Walkthrough

transfer-pvc now copies source PVC annotations to the destination after removing known server-managed keys. Tests cover nil, empty, user-defined, server-managed, and mixed annotation maps.

Changes

PVC annotation preservation

Layer / File(s)	Summary
Filter and copy PVC annotations cmd/transfer-pvc/transfer-pvc.go, cmd/transfer-pvc/transfer-pvc_test.go	buildDestinationPVC assigns filtered source annotations. The helper removes server-managed prefixes and returns nil when no annotations remain. Table-driven tests validate the filtering behavior.

Estimated code review effort: 2 (Simple) | ~10 minutes

Suggested labels: ready-for-review-notified

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly describes the fix to preserve annotations during PVC migration.
Linked Issues check	✅ Passed	The changes preserve user-defined PVC annotations and remove server-managed keys, which meets issue #672.
Out of Scope Changes check	✅ Passed	The implementation and tests are limited to annotation handling for PVC migration and are within issue #672 scope.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[aufi]

LGTM

[stillalearner]

Tested on OCP successfully. All existing tests pass.

[Tamar-Dinavetsky]

[review-docs]

[Tamar-Dinavetsky]

📚 Documentation Review

Analyzed PR: #754
Latest commit: 9b3679c

Found 1 file(s) that may need updates:

📋 Select files to update

Uncheck any files you do not want updated:

• commands/transfer-pvc.md: This documentation file outlines the crane transfer-pvc command used for migrating persistent volume data between Kubernetes clusters. I suggest adding a note to the "Description" and the "Examples" section to clarify that the command now automatically preserves user-defined annotations while stripping Kubernetes-managed annotations to ensure the destination PVC is provisioned correctly.

---

💡 Next Steps:

• Uncheck any files above that you don't want updated
• When ready, comment [​update-docs] to generate a PR with only the checked files
• You can add instructions in your [​update-docs] comment:
  • Global (first line): [​update-docs] keep changes minimal, don't add new sections
  • Per-file (next lines): config-ref.rst: only update the CLI usage example

Powered by code-to-docs AI ✨

[Tamar-Dinavetsky]

[update-docs]
commands/transfer-pvc.md: add one sentence to the Description only -no code example needed, this behavior is
automatic with no new flags

[Tamar-Dinavetsky]

📚 Documentation Update

Updated 1 file(s) based on your review selections:

• ✅ commands/transfer-pvc.md

📄 Changes

commands/transfer-pvc.md

View diff

--- a/commands/transfer-pvc.md
+++ b/commands/transfer-pvc.md
@@ -10,7 +10,7 @@
 
 ## Description
 
-The `transfer-pvc` subcommand transfers a PersistentVolumeClaim resource and its volume data to a destination cluster. It establishes a connection to the destination cluster by creating a public endpoint of the user's choice in the destination namespace. It then creates a PVC and an rsync daemon Pod in the destination namespace to receive data from the source PVC. Finally, it creates an rsync client Pod in the source namespace which transfers data to the rsync daemon using the endpoint. The connection is encrypted using self-signed certificates created automatically at the time of transfer.
+The `transfer-pvc` subcommand transfers a PersistentVolumeClaim resource and its volume data to a destination cluster. It establishes a connection to the destination cluster by creating a public endpoint of the user's choice in the destination namespace. It then creates a PVC and an rsync daemon Pod in the destination namespace to receive data from the source PVC. Finally, it creates an rsync client Pod in the source namespace which transfers data to the rsync daemon using the endpoint. The connection is encrypted using self-signed certificates created automatically at the time of transfer. During the transfer, user-defined annotations are preserved on the destination PVC, while Kubernetes server-managed annotations (such as those related to storage provisioners or binding status) are automatically stripped to ensure compatibility with the destination environment.
 
 `transfer-pvc` supports transfers between different clusters or within the same cluster. When performing transfers within the same cluster and namespace, the source and destination PVC names must be different.
 

A docs PR has been created: #775