Exclude CSINode and VolumeAttachments by default?

[jemag]

Describe the problem/challenge you have

Currently it seems that resources of kind CSINode and VolumeAttachments are automatically included in backups. This may cause problem where CSINodes get restored for nodes that no longer exist.
It seem to also duplicate VolumeAttachments (one is automatically created + the one restored). This can cause problems, most notably, when you try to delete PVs with those duplicate VolumeAttachments, it will only delete one of those VolumeAttachments and PV will get stuck deleting because it thinks it is still attached to the node.

Describe the solution you'd like

Exclude those resources by default?

I am unsure if there are use cases where you would actually want those restored, would love to hear anyone else thoughts. If there aren't such use cases, it might be best to exclude them by default to avoid the kinds of errors mentioned above. If there are such use cases, perhaps a few notes in the documentation regarding CSINodes and VolumeAttachments could help future users.

Environment:

• Velero version (use velero version): main
• Kubernetes version (use kubectl version): 1.22.4
• Kubernetes installer & version: AKS
• Cloud provider or hardware configuration: AKS

Vote on this issue!

This is an invitation to the Velero community to vote on issues, you can see the project's top voted issues listed here.
Use the "reaction smiley face" up to the right of this comment to vote.

• 👍 for "The project would be better with this feature added"
• 👎 for "This feature will not enhance the project in a meaningful way"

[qiuming-best]

@jemag Maybe you could consider using '--exclude-resources' flag to exclude these two kinds of resources backed up. Keep me updated if needed

[jemag]

@qiuming-best yes I know. I guess this issue was more about asking if there really are use cases where these two kinds of resources need to be backed up and restored. For example, CSINode should be there without needing to restore it, and potentially creating a CSINode bound to a node that is no longer present.

If there aren't any use cases for these 2 kinds of resources and they only cause problems, it might be worth considering excluding them by default (without users having to provide the --exlude-resources flag)