Post Review Session Update

Signed-off-by: Lyndon-Li <lyonghui@vmware.com>

design/unified-repo-and-kopia-integration/unified-repo-and-kopia-integration.md

@@ -41,6 +41,7 @@ On the other hand, based on a previous analysis and testing, we found that Kopia
 - Use Kopia repository to implement the Unified Repository
 - Use Kopia uploader as the file system data mover for Pod Volume Backup
 - Have Kopia uploader calling the Unified Repository Interface and save/retrieve data to/from the Unified Repository
+- Make Kopia uploader generic enough to move any file system data so that other data movement cases could use it
 - Use the existing logic or add new logic to manage the unified repository and Kopia uploader
 - Preserve the legacy Restic path, this is for the consideration of backward compatibility
 
@@ -48,14 +49,15 @@ On the other hand, based on a previous analysis and testing, we found that Kopia
 
 - The Unified Repository supports all kinds of data movers to save logic objects into it. How these logic objects are organized for a specific data mover (for example, how a volume’s block data is organized and represented by a unified repository object) should be included in the related data mover design.
 - At present, Velero saves Kubernetes resources, backup metedata, debug logs separately. Eventually, we want to save them in the Unified Repository. How to organize these data into the Unified Repository should be included in a separate design.
-- Kopia uploader could be used as a generic file system data mover. How it is integrated in other cases, for example, CSI file system mode BR, should be included in the related data mover design.
+- For PodVolume BR, this design focuses on the data path only, other parts beyond the data read/write and data persistency are irrelevant and kept unchanged. 
+- Kopia uploader is made generic enough to move any file system data. How it is integrated in other cases, is irrelevant to this design. Take CSI snapshot backup for example, how the snapshot is taken and exposed to Kopia uploader should be included in the related data mover design.
 - The adanced modes of the Unified Repository, for example, backup repository/storage plugin, backup repository extension, etc. are not included in this design. We will have separate designs to cover them whenever necessary.
 
 ## Architecture of Unified Repository
 
 Below shows the primary modules and their responsibilities:
 
-- Kopia uploader is used as a generic file system data mover, so it could move all file system data either from the production PV (as Velero’s Pod Volume Backup does), or from any kind of snapshot (i.e., CSI snapshot).
+- Kopia uploader, as been well isolated, could move all file system data either from the production PV (as Velero’s PodVolume BR does), or from any kind of snapshot (i.e., CSI snapshot).
 - Kopia uploader, the same as other data movers, calls the Unified Repository Interface to write/read data to/from the Unified Repository.
 - Kopia repository layers, CAOS and CABS, work as the backup repository and expose the Kopia Repository interface.
 - A Kopia Repository Library works as an adapter between Unified Repository Interface and Kopia Repository interface. Specifically, it implements Unified Repository Interface and calls Kopia Repository interface.
@@ -68,7 +70,7 @@ The Unified Repository takes two kinds of data:
 - Unified Repository Manifest: This could include all other data to maintain the object data, for example, snapshot information, etc.  
 
 For Unified Repository Object/Manifest, a brief guidance to data movers are as below:
-- Data movers treat the simple unit of data they recognize as an Object. For example, a file system data mover treats a file or a directory as an Object; a block data mover treats a volume as an Object
+- Data movers treat the simple unit of data they recognize as an Object. For example, file system data movers treat a file or a directory as an Object; block data movers treat a volume as an Object. However, it is unnecessary that every data mover has a unique data format in the Unified Repository, to the opposite, it is recommended that data movers could share the data formats unless there is any reason not to, in this way, the data generated by one data mover could be used by other data movers.
 - Data movers don't need to care about the differences between full and incremental backups regarding the data organization. Data movers always have full views of their objects, if an object is partially written, they use the object writer's Seek function to skip the unchanged parts
 - Unified Repository may divide the data movers' logical Object into sub-objects or slices, or append internal metadata, but they are transparent to data movers 
 - Every Object has an unified identifier, in order to retrieve the Object later, data movers need to save the identifiers into the snapshot information. The snapshot information is saved as a Manifest.
@@ -256,7 +258,7 @@ The Delete Snapshot workflow follows the similar manner with BR workflow, that i
 Backup Repository/Backup Storage may need to periodically reorganize its data so that it could guarantee its QOS during the long-time service. Some Backup Repository/Backup Storage does this in background automatically, so the user doesn’t need to interfere; some others need the caller to explicitly call their maintenance interface periodically. Restic and Kopia both go with the second way, that is, Velero needs to periodically call their maintenance interface.  
 Velero already has an existing workflow to call Restic maintenance (it is called “Prune” in Restic, so Velero uses the same word). The existing workflow is as follows:
 - The Prune is triggered at the time of the backup
-- When a BackupRepsoitory CR (originally called ResticRepository CR) is created by PodVolumeBackup/Restore Controller, the BackupRepository controller checks if it reaches to the Prune Due Time, if so, it calls PruneRepo  
+- When a BackupRepository CR (originally called ResticRepository CR) is created by PodVolumeBackup/Restore Controller, the BackupRepository controller checks if it reaches to the Prune Due Time, if so, it calls PruneRepo  
 - In the new design, the Repository Provider implements PruneRepo call, it uses the same way to switch between Restic Repository Provider and Unified Repository Provider, then:
   - For Restic Repository, Restic Repository Provider invokes the existing “Prune” CLI of Restic
   - For Unified Repository, Unified Repository Provider calls udmrepo.BackupRepoService’s Maintain function
@@ -278,7 +280,7 @@ In this way, Velero will be able to get the progress as shown in the diagram bel
 ### Logs
 In the current design, Velero is using two unchanged Kopia modules --- the Kopia Uploader and the Kopia Repository. Both will generate debug logs during their run. Velero will collect these logs in order to aid the debug.  
 Kopia’s Uploader and Repository both get the Logger information from the current GO Context, therefore, the Kopia Uploader Provider/Kopia Library could set the Logger interface into the current context and pass the context to Kopia Uploader/Kopia Repository.  
-Velero will set Logger interfaces separately for Kopia Uploader and Kopia Repository. In this way, the Unified Repository could serve other uploaders/data movers without losing the debug log capability; and the Kopia Uploader could write to any repository without losing the debug log capability.  
+Velero will set Logger interfaces separately for Kopia Uploader and Kopia Repository. In this way, the Unified Repository could serve other data movers without losing the debug log capability; and the Kopia Uploader could write to any repository without losing the debug log capability.  
 Kopia’s debug logs will be written to the same log file as Velero server or PodVolumeBackup daemonset, so Velero doesn’t need to upload/download these debug logs separately.  
 ![A Debug Log for Uploader](debug-log-uploader.png) 
 ![A Debug Log for Repository](debug-log-repository.png) 
@@ -301,7 +303,7 @@ Changing path during upgrade is not prohibited, however some mismatches cases wi
 We will change below CRs' name to make them more generic:
 - "ResticRepository" CR to "BackupRepository" CR  
 
-This means, we add a new CR type and desperate the old one. As a result, if users upgrade from the old release, the old CRs will be orphaned, Velero will neither refer to it nor manage it, users need to delete these CRs manually.  
+This means, we add a new CR type and deprecate the old one. As a result, if users upgrade from the old release, the old CRs will be orphaned, Velero will neither refer to it nor manage it, users need to delete these CRs manually.  
 As a side effect, when upgrading from an old release, even though the path is not changed, the repository is initialized all the time, because Velero will not refer to the old CR's status. This means, the same repository will be initialized again. This is a minor side effect, we don't see critical problems.  
 Therefore, users are recommended to uninstall Velero and delete all the resources in the Velero namespace before installing the new release.