Remove Restic dependencies in Velero plugins

[Lyndon-Li]

Some Velero BackupItemAction/RestoreItemAction plugins, for example, CSI plugin, vSphere plugin, contain some code to actively check and exclude the volumes handled by Velero's Pod Volume Backup/Restore. As a result, these plugins depend on Velero's code in PodVolume/Restic package.

In v1.10, we've refactored the code, plugins need to call the new function.
It is recommended to remove the irrational "Restic" text in plugins' code.

Moreover, it is not reasonable for the plugins to depend on Velero's logic, the plugins should have no knowledge of what Velero does, for example, Pod Volume Backup/Restore. Moreover, whenever the related code changes in Velero, changes are required in the plugins.
Therefore, let's refactor the BackupItemAction/RestoreItemAction plugin interface, so that this kind of dependencies can be removed.

[sseago]

@Lyndon-Li Is the suggestion that we add explicit information to the BIA/RIA interface about restic/PodVolume stuff? It's not clear to me what we're suggesting that Velero would want to provide to the plugins. Are there additional parameters that velero would supply to the plugin? What exactly would those be? (and note, that if this is to be a change to the BIA/RIA interface, it can't really be type-specific, since all resource types use the same plugin interface.

@shubham-pampattiwar Since you've done more CSI work than I have, what sort of generic plugin interface additions would eliminate the problem described above?

[Lyndon-Li]

@sseago
The direct problem we see here is that some BIA/RIA involve some restic/PodVolume logics to check the volumes handled by restic/PodVolume, it is weird for some BIA/RIA that have nothing to do with restic/PodVolume to have restic/PodVolume logics.
Therefore, we want to remove these restic/PodVolume specific logics from the BIA/RIA.

I don't have a specific design for the interface change. Generally speaking, this requires the BIA/RIA interface to expose some way to exclude some volumes, so that Velero could have the logics in itself and deliver the result to BIA/RIA as volumes to be excluded.

[sseago]

@Lyndon-Li OK. It sounds like we need to get a design proposed (and approved) for that before we could consider adding that to the API. If that happens before we're ready to approve the current v2 API, then I can add it to that design. Otherwise it can go in its own design -- still in v2 if it's in the same release cycle (i.e. we won't do v2 and v3 before Velero 1.11 releases), although it would probably be in v3 if it's not ready to implement in the 1.11 dev cycle.

[sseago]

In any case, the main challenge would be that whatever new inputs are added to the Execute() API method need to be generic. These APIs apply to all resource types, so any API methods added should probably not be volume-specific.

[shubham-pampattiwar]

@Lyndon-Li Are you talking about instances like these https://github.com/vmware-tanzu/velero-plugin-for-csi/blob/main/internal/backup/pvc_action.go#L92

[Lyndon-Li]

@sseago
so any API methods added should probably not be volume-specific
Agree

[Lyndon-Li]

@shubham-pampattiwar
Are you talking about instances like these https://github.com/vmware-tanzu/velero-plugin-for-csi/blob/main/internal/backup/pvc_action.go#L92
Yes

[reasonerjt]

In v1.10 we'll only consider renaming.
cc @blackpiglet
After that we'll close this issue and open another one to track the work to update the interface.

IMHO, that's not very high priority

[reasonerjt]

AWS and Azure plugins are set
@blackpiglet let's resolve this one once GCP and CSI plugins are cleared