Add CBT interfaces for block data mover

[Lyndon-Li]

Fix issue #9709, add interfaces for CBT service and CBT bitmap

[codecov]

Codecov Report

❌ Patch coverage is 0% with 13 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
pkg/uploader/cbt/set.go	0.00%	13 Missing ⚠️

📢 Thoughts on this report? Let us know!

[Lyndon-Li]

@kaovilai Please help to take another look, I made some adjustments.

[kaovilai]

edit: lgtm.

[EunbiZhang]

To maintain consistency with the SnapshotMetadataService specification, should we align the input parameters of GetChangedBlocks with GetMetadataDeltaRequest, which contain "base_snapshot_id", "target_snapshot_name", "starting_offset", etc?

Same for the method "GetAllocatedBlocks".

[kaovilai]

This was covered in the design perhaps to be abstract just in case.

ChangeId

ChangeId identifies the base that CBT is generated from, it must strictly map to the parent snapshot in the repository. Otherwise, there will be data corruption in the incremental backup.
Therefore, ChangeId is saved together with the repository snapshot.
The data mover always queries parent snapshot from Unified Repo together with the ChangeId. In this way, no mismatch would happen.
Inside the uploader, the upper layer (DataUpload controller) could also provide the ChangeId as a mechanism of double confirmation. The received ChangeId would be re-evaluated against the one in the provided snapshot.

For Kubernetes API, changeId is represented by BaseSnapshotId.
changeId retrieval is storage specific, generally, it is retrieved from the SnapshotHandle of the VolumeSnapshotContent object; however, storages may also refer to other places to retrieve the changeId.
That is, SnapshotHandle and changeId may be two different values, in this case, the both values need to be preserved.

[Lyndon-Li]

This is an abstraction provided by Velero, as the design shared by @kaovilai, this abstraction is for the below purpose:

1. Support both Kubernetes native CBT service (SnapshotMetadataService) and the possible customized CBT service
2. It is used by the uploader to translate the entire allocated/changed blocks into the CBT bitmap

Because of 1, the abstraction just purposefully avoids to use the primatives from Kubernetes upstream, e.g., in the upstream target_snapshot_name means the name of the VolumeSnapshot, however, for customized CBT service, it could not be the name of VolumeSnapshot or even not a name (e.g., a snapshot ID instead).
Because of 2, it means it is a special/compacted version when comparing to the upstream primitives, e.g., starting_offset is not required since the uploader always expects to translates the entire CBT, from the begining to end.

[EunbiZhang]

Looks good to me as far as I can tell. Thanks for working on the change Lyndon!

[Lyndon-Li]

@kaovilai @EunbiZhang
Please take another look. Added one more field VolumeID into SourceInfo of CBTService to address below statement in the design:

SnapshotHandle and changeId may be two different values, in this case, the both values need to be preserved

For the same PVC, the underlying volumes may be changed, but the CBT associates to the a specific volume only. So the VolumeID uniquely identifies the volume, and do necessary checks to detect the volume change cases.