From 8c6a3f5142749f10e5719cb7833a2a8519a84f4f Mon Sep 17 00:00:00 2001 From: James Lu Date: Thu, 5 Oct 2023 09:22:41 +0800 Subject: [PATCH] fix(typo): codespell tested failed Fixed some typos that codespell found. Signed-off-by: James Lu --- ...0220428-storage-network-through-grpc-proxy.md | 4 ++-- ...e-backup-policy-for-longhorn-system-backup.md | 8 ++++---- .../20230807-backingimage-backup-support.md | 16 ++++++++-------- 3 files changed, 14 insertions(+), 14 deletions(-) diff --git a/enhancements/20220428-storage-network-through-grpc-proxy.md b/enhancements/20220428-storage-network-through-grpc-proxy.md index 45629bc..c3bda1b 100644 --- a/enhancements/20220428-storage-network-through-grpc-proxy.md +++ b/enhancements/20220428-storage-network-through-grpc-proxy.md @@ -51,7 +51,7 @@ https://github.com/longhorn/longhorn/issues/3546 - Introduce a new gRPC server in Instance Manager. -- Keep re-usable connections between Manager and Instance Managers. +- Keep reusable connections between Manager and Instance Managers. - Allow Manager to fall back to engine binary call when communicating with old Instance Manager. @@ -101,7 +101,7 @@ So I can decide when to upgrade the Engine Image. 1. When updating the setting I see engine/replica instance manager pod and backing image manager pods is restarted. 1. I attach the volumes. 1. I describe Engine, Replica, and BackingImageManager, and see the `storageIP` in CR status is in the range of the `NetworkAttachmentDefinition` subnet/CIDR. I also see the `storageIP` is different from the `ip` in CR status. -1. I describe the Engine and see the `replicaAddressMap` in CR spec and status is using the storage IP. +1. I describe the Engine and see the `replicaAddressMap` in CR spec and status is using the storage IP. 1. I see pod logs indicate the network directions. #### Story 2 - upgrade diff --git a/enhancements/20230526-volume-backup-policy-for-longhorn-system-backup.md b/enhancements/20230526-volume-backup-policy-for-longhorn-system-backup.md index 5018205..ef060fc 100644 --- a/enhancements/20230526-volume-backup-policy-for-longhorn-system-backup.md +++ b/enhancements/20230526-volume-backup-policy-for-longhorn-system-backup.md @@ -4,7 +4,7 @@ The current implementation of the Longhorn system backup lacks integration with ## Summary -This document proposed to include the volume backup feature in the Longhorn system backup by introducing volume backup policies. +This document proposed to include the volume backup feature in the Longhorn system backup by introducing volume backup policies. By implementing the volume backup policies, users will gain the ability to define how volume data should be backed up during the Longhorn system backup. @@ -30,7 +30,7 @@ Overall, the proposed volume backup policies aim to improve the Longhorn system 1. When volume backup policy is specified: - `if-not-present`: Longhorn will create a backup for volumes that do not have an existing backup. - - `alway`: Longhorn will create a backup for all volumes, regardless of their existing backups. + - `always`: Longhorn will create a backup for all volumes, regardless of their existing backups. - `disabled`: Longhorn will not create any backups for volumes. 1. If a volume backup policy is not specified, the policy will be automatically set to `if-not-present`. This ensures that volumes without any existing backups will be backed up during the Longhorn system backup. @@ -50,7 +50,7 @@ In cases where I don't explicitly specify the volume backup policy during the sy To set the volume backup policy, users can set the volume backup policy when creating the system backup through the UI. Alternatively, users can specify it in the manifest when creating the SystemBackup custom resource using the kubectl command. -In scenarios where no specific volume backup policy is provided, Longhorn will automatically set the policy as `if-not-present`. +In scenarios where no specific volume backup policy is provided, Longhorn will automatically set the policy as `if-not-present`. ### API changes @@ -75,7 +75,7 @@ Add a new `volumeBackupPolicy` field to the HTTP request and response payload. #### Mutate empty volume backup policy -When the volume backup policy is not provided in the SystemBackup custom resource, automatically set the policy to `if-not-present`. +When the volume backup policy is not provided in the SystemBackup custom resource, automatically set the policy to `if-not-present`. ### Test plan diff --git a/enhancements/20230807-backingimage-backup-support.md b/enhancements/20230807-backingimage-backup-support.md index d97c2a6..14c6869 100644 --- a/enhancements/20230807-backingimage-backup-support.md +++ b/enhancements/20230807-backingimage-backup-support.md @@ -1,7 +1,7 @@ # BackingImage Backup Support ## Summary -This feature enables Longhorn to backup the BackingImage to backup store and restore it. +This feature enables Longhorn to backup the BackingImage to backup store and restore it. ### Related Issues @@ -44,7 +44,7 @@ This improve the user experience and reduce the operation overhead. #### Backup BackingImage - BackupStore - Backup `BackingImage` is not the same as backup `Volume` which consists of a series of `Snapshots`. Instead, a `BackingImage` already has all the blocks we need to backup. Therefore, we don't need to find the delta between two `BackingImages` like what we do for`Snapshots` which delta might exist in other `Snapshots` between the current `Snapshot` and the last backup `Snapshot`. -- All the `BackingImages` share the same block pools in backup store, so we can reuse the blocks to increase the backup speed and save the space. This can happen when user create v1 `BackingImage`, use the image to add more data and then export another v2 `BackingImage`. +- All the `BackingImages` share the same block pools in backup store, so we can reuse the blocks to increase the backup speed and save the space. This can happen when user create v1 `BackingImage`, use the image to add more data and then export another v2 `BackingImage`. - For restoration, we still restore fully on one of the ready disk. - Different from `Volume` backup, `BackingImage` does not have any size limit. It can be less than 2MB or not a multiple of 2MB. Thus, the last block might not be 2MB. @@ -58,7 +58,7 @@ This improve the user experience and reduce the operation overhead. - When restoring `BackingImage` - `loadBackupBacking()`: load the metadata of the `BackupBackingImage` from the backup store - - `populateBlocksForFullRestore() + restoreBlocks()`: based on the mapping, write the block data to the correct offset. + - `populateBlocksForFullRestore() + restoreBlocks()`: based on the mapping, write the block data to the correct offset. - We backup the blocks in async way to increase the backup speed. - For qcow2 `BackingImage`, the format is not the same as raw file, we can't detect the hole and the data sector. So we back up all the blocks. @@ -111,7 +111,7 @@ This improve the user experience and reduce the operation overhead. - Check and update the ownership. - Do cleanup if the deletion timestamp is set. - Cleanup the backup `BackingImage` on backup store - - Stop the monitoring + - Stop the monitoring - If `Status.LastSyncedAt.IsZero() && Spec.BackingImageName != ""` means **it is created by the User/API layer**, we need to do the backup - Start the monitor - Pick one `BackingImageManager` @@ -181,7 +181,7 @@ This improve the user experience and reduce the operation overhead. 5. In `BackingImageDataSourceController` - No need to change, it will create the `BackingImageDataSourcePod` to do the restore. 6. In `BackingImageManager - data_source` - - When init the service, if the type is `restore`, then restore from `backup-url` by resquesting sync service in the same pod. + - When init the service, if the type is `restore`, then restore from `backup-url` by requesting sync service in the same pod. ```go requestURL := fmt.Sprintf("http://%s/v1/files", client.Remote) req, err := http.NewRequest("POST", requestURL, nil) @@ -212,7 +212,7 @@ This improve the user experience and reduce the operation overhead. #### API and UI changes In Summary -1. `longhorn-ui`: +1. `longhorn-ui`: - Add a new page of `BackupBackingImage` like `Backup` - The columns on `BackupBackingImage` list page should be: `Name`, `Size`, `State`, `Created At`, `Operation`. - `Name` can be clicked and will show `Checksum` of the `BackupBackingImage` @@ -254,7 +254,7 @@ Integration tests - Restore the Volume with same `BackingImage` - `BackingImage` should be restored and the `Volume` should also be restored successfully - `Volume` checksum is the same - + Manual tests 1. `BackupBackingImage` reuse blocks @@ -264,4 +264,4 @@ Manual tests - Create a `Volume` with `BackingImage` A, write some data and export to another `BackingImage` B - Back up `BackingImage` A - Back up `BackingImage` B - - Check it reuses the blocks when backing up `BackingImage` B (by trace log) \ No newline at end of file + - Check it reuses the blocks when backing up `BackingImage` B (by trace log)