Design for global volume policies#9901
Conversation
✅ Deploy Preview for velero canceled.
|
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
81781b0 to
98c16cb
Compare
98c16cb to
0a67b2b
Compare
kaovilai
left a comment
There was a problem hiding this comment.
would be nice if you clarify what happens when configmap configured is missing. warn/error/no-error.
|
|
||
| ## Design | ||
|
|
||
| A new Velero server flag, `--global-backup-volume-policies-configmap`, accepts the name of a ConfigMap that lives in the Velero install namespace. The ConfigMap has the exact same format as an existing per-backup resource policies ConfigMap (a single data key holding a `ResourcePolicies` YAML document). |
There was a problem hiding this comment.
The design should specify the behavior when --global-backup-volume-policies-configmap is set but the referenced ConfigMap doesn't exist, both at server startup and at backup time (in case it's deleted after startup). Should the backup fail with a validation error? Or warn and proceed without global policies?
There was a problem hiding this comment.
Sure I'll update it to add more details.
There was a problem hiding this comment.
I added a "Validation" section.
|
|
||
| The merge combines two `ResourcePolicies` documents: the global policy (`G`) and the backup-level policy (`B`). The guiding principle is that the global policy provides a baseline, and the backup-level policy is layered with it. | ||
|
|
||
| - **`volumePolicies`**: `volumePolicies` is an ordered list where the *first* matching policy wins (per the existing `Policies.match` logic). The merged list is the concatenation of the backup-level policies followed by the global policies: |
There was a problem hiding this comment.
The issue description says the global policy should be merged "if the VolumePolicy is absent," which reads like a fallback-only behavior. This design proposes always merging (backup-level first, then global). The Alternatives section acknowledges the fallback approach but rejects it. Always-merge means existing backups that already have volume policies will start picking up global rules they didn't have before, which could be surprising.
There was a problem hiding this comment.
I think this is the intention, b/c when the admin configures the global volume policy for velero he wanna influence the behavior of all backups, unless over-written by the user. I clarified it in the "Compatibility" section.
|
|
||
| ## Design | ||
|
|
||
| A new Velero server flag, `--global-backup-volume-policies-configmap`, accepts the name of a ConfigMap that lives in the Velero install namespace. The ConfigMap has the exact same format as an existing per-backup resource policies ConfigMap (a single data key holding a `ResourcePolicies` YAML document). |
There was a problem hiding this comment.
Minor: the flag name --global-backup-volume-policies-configmap is quite long. Since it's a server flag (already global scope) and the value is always a ConfigMap name, something shorter like --default-volume-policy or --global-volume-policy might be friendlier. Not a blocker, just a usability thought.
There was a problem hiding this comment.
There was a problem hiding this comment.
@shubham-pampattiwar Thanks for the comment.
I chose to use xxx-volume-policies-configmap to be consistent with the parameter --resource-policies-configmap of velero backup create.
I think the backup is also needed in the parameter, b/c it's a policy for backups, and there could be policy for restores.
0a67b2b to
95dae20
Compare
Add the design for global volume policies to address the requirement in velero-io#9858 Signed-off-by: Daniel Jiang <daniel.jiang@broadcom.com>
95dae20 to
8a31544
Compare
Add the design for global volume policies to address the requirement in #9858
make new-changelog) or comment/kind changelog-not-requiredon this PR.site/content/docs/main.