Testing Kopia Backup to Local Volume Provider

[kaovilai]

Thank you for contributing to Velero!

Please add a summary of your change

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 (make new-changelog) or comment /kind changelog-not-required on this PR.
• Updated the corresponding documentation in site/content/docs/main.

[Lyndon-Li]

@kaovilai
Some high level advices before you continue this PR:

1. NFS support has several sub tasks, please clarify which sub task this PR is for.
2. If this PR is for sub task Unified repo support file system store #6197, the unified repo backend already supports the NFS/local volume by FSBackend type. But it is not exposed to the upper level, neither tested, which could be the following tasks.
3. As far as I understand, Velero's current implementations, including the repo part and data mover part, go away from the community's NFS plugin implementation(e.g., the one from replicated for Restic path), so the target is not to integrate to any of the community's plugin, but to develop Velero's native NFS support which complies with the high level designs, i.e., unified repo design, volume snapshot data mover design and VGDP micro service design, etc.
4. For the same reason of 3, before we work on each of the sub tasks, it's better that we have a high level design to elaborate on the architecture, workflow and user scenarios based on the aforementioned designs, but it may not be mandatory.

[kaovilai]

It is aimed at #6197 mentioned. I'm going to be doing some testing in this area so figured I use this PR to write some notes down for potential design discussions.

[kaovilai]

Making smallest change possible so hoping to not have to replace the local volume provider (LVP) object store plugin yet and aiming solely at enabling kopia usage from within velero code by detecting LVP and using bsl info for kopia.

[kaovilai]

My goal is to enable ASAP testing of kopia performance via local volume as backup store. Once we have some ideas we can pursue long term vision around replacing LVP integration. So perhaps this design will just close and we'll open another.

[codecov]

Codecov Report

Attention: Patch coverage is 16.66667% with 10 lines in your changes missing coverage. Please review.

Project coverage is 58.96%. Comparing base (db470a7) to head (7e6045a).

Files with missing lines	Patch %	Lines
pkg/repository/provider/unified_repo.go	9.09%	9 Missing and 1 partial ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #8358   +/-   ##
=======================================
  Coverage   58.95%   58.96%           
=======================================
  Files         367      367           
  Lines       38876    38886   +10     
=======================================
+ Hits        22920    22928    +8     
- Misses      14493    14495    +2     
  Partials     1463     1463           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[kaovilai]

looks like there is already a filesystem store in the code so looking into that.

var backendStores = []kopiaBackendStore{
	{udmrepo.StorageTypeAzure, "an Azure blob storage", &backend.AzureBackend{}},
	{udmrepo.StorageTypeFs, "a filesystem", &backend.FsBackend{}},
	{udmrepo.StorageTypeGcs, "a Google Cloud Storage bucket", &backend.GCSBackend{}},
	{udmrepo.StorageTypeS3, "an S3 bucket", &backend.S3Backend{}},

[kaovilai]

BSL needs to have backupLocation.Spec.Provider set to velero.io/fs or fs to trigger this path. For testing I will make modifications such that replicated LVP plugin is also considered equivalent to velero.io/fs and see if that allows kopia to work.

[kaovilai]

replicated/lvp will handle pvc creation and mounting to nodeagents and hopefully the spice flows.

[weshayutin]

woot! thanks for pushing on this @kaovilai