Feature/add provider interface for block mode

[shawn-hurley]

Thank you for contributing to Velero!

Please add a summary of your change

Adding the block mode to the interfaces, to be included in 1.12.

This will allow us to solve the issue of block support in a Z-stream without breaking the API's in a Z-stream.

Does your change fix a particular issue?

Fixes #(issue)

Please indicate you've done the following:

• Accepted the DCO. Commits without the DCO will delay acceptance.
• Created a changelog file or added /kind changelog-not-required as a comment on this pull request.
• Updated the corresponding documentation in site/content/docs/main.

[weshayutin]

Thank you @shawn-hurley! @draghuram @dzaninovic FYI :)

[dzaninovic]

I will refactor my code to adjust for these changes.

[codecov-commenter]

Codecov Report

Merging #6608 (284f7c8) into main (411bd54) will decrease coverage by 0.16%.
The diff coverage is 78.57%.

❗ Current head 284f7c8 differs from pull request most recent head 563a16c. Consider uploading reports for the commit 563a16c to get more accurate results

@@            Coverage Diff             @@
##             main    #6608      +/-   ##
==========================================
- Coverage   60.31%   60.16%   -0.16%     
==========================================
  Files         242      242              
  Lines       25924    25735     -189     
==========================================
- Hits        15637    15484     -153     
+ Misses       9186     9167      -19     
+ Partials     1101     1084      -17     

Files Changed	Coverage Δ
pkg/uploader/provider/provider.go	100.00% <ø> (ø)
pkg/uploader/types.go	100.00% <ø> (ø)
pkg/datapath/file_system.go	31.09% <40.00%> (-0.44%)	⬇️
pkg/uploader/kopia/snapshot.go	80.00% <100.00%> (+0.28%)	⬆️
pkg/uploader/provider/kopia.go	85.71% <100.00%> (+0.68%)	⬆️
pkg/uploader/provider/restic.go	80.55% <100.00%> (+1.14%)	⬆️

... and 5 files with indirect coverage changes

[sseago]

Note for other maintainers/reviewers: This PR just implements the API change, adding volMode to RunBackup(), but errors out as unsupported if Block is specified. The hope is to get the API change into 1.12 before anyone is actually using this API, but then we can add the kopia implementation bits (Restic will continue to error out on block mode) in a future release. Making the API change later increases the likelihood that it will break someone's implementation of it, but at the moment there are no implementations of this API outside of Velero core code.

[dzaninovic]

We also need to add volMode to RunRestore():
https://github.com/catalogicsoftware/velero_block/pull/1/files#diff-0c7524c0c1d97816a32e51877ae12c8f8d2b24f8ab305388196efe7d2a539edaR59

[Lyndon-Li]

Per my understanding, the changes in this PR won't take effect under the current code context.

As you can see from the controller and the exposer , the snapshot volume mode has been hard-coded to FileSystem, and the AccessPoint has been hard-coded to ByPath. So with the current code changes only, the data path won't call the uploader with PersistentVolumeBlock as the volMode.
I am not sure there is anywhere else in the current code that conflicts with the block mode volumes/snapshots. This has never been tested.

If so, what is the purpose to have this separate PR, why don't we submit the entire functioning code in one PR later when they are ready?
If we want to block data mover from processing block mode PVCs (so that we could get a clearer error message), I think we should check it before taking snapshot or before submitting DataUpload CR. cc @blackpiglet

[sseago]

@Lyndon-Li "If so, what is the purpose to have this separate PR, why don't we submit the entire functioning code in one PR later when they are ready?"

One reason is that this introduces an API change to RunBackup and RunRestore, so it's better to introduce the API change in 1.12 now (before anyone is using it). Ideally we wouldn't have API changes in 1.12.x, when we're ready to submit the block-mode functionality, and while it may be unlikely that anyone outside of velero core will be using these APIs by then, it's not impossible. It's probably better to add it now (even though there is no new functionality associated with volMode=block) rather than in a patch release.

[shawn-hurley]

If so, what is the purpose to have this separate PR, why don't we submit the entire functioning code in one PR later when they are ready?

The biggest reason is that we want the API changes for the 1.12.0 release. This will make sure that we don't add a breaking API change for folks who are attempting to use the VGDP (I think that is the right acronym that I have been reading?) Please let me know if this makes sense.

Also note, I will add code around when ByPath or ByBlock should be set.

[weshayutin]

Thanks for the progress!

[Lyndon-Li]

@shawn-hurley Please help to fix the CI errors. Thanks!

[shawn-hurley]

@Lyndon-Li @sseago @shubham-pampattiwar @mateusoliveira43

To get in, just pinging folks for awareness that I have updated and it should be ready to go!

[shubham-pampattiwar]

@shawn-hurley please squash all the commits and/or remove the design commit.