ivampiresp/longhorn
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix(typo): codespell tested failed

Browse Source 
Fixed some typos that codespell found.

Signed-off-by: James Lu <james.lu@suse.com>
This commit is contained in:
James Lu 2023-10-05 09:22:41 +08:00 committed by David Ko
parent e1914963a6
commit 8c6a3f5142
3 changed files with 14 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
enhancements/20220428-storage-network-through-grpc-proxy.md
View File

@ -51,7 +51,7 @@ https://github.com/longhorn/longhorn/issues/3546
- Introduce a new gRPC server in Instance Manager. - 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. - 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. 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 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 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. 1. I see pod logs indicate the network directions.
#### Story 2 - upgrade #### Story 2 - upgrade

8
enhancements/20230526-volume-backup-policy-for-longhorn-system-backup.md
View File

@ -4,7 +4,7 @@ The current implementation of the Longhorn system backup lacks integration with
## Summary ## 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. 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: 1. When volume backup policy is specified:
- `if-not-present`: Longhorn will create a backup for volumes that do not have an existing backup. - `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. - `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. 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. 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 ### API changes
@ -75,7 +75,7 @@ Add a new `volumeBackupPolicy` field to the HTTP request and response payload.
#### Mutate empty volume backup policy #### 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 ### Test plan

16
enhancements/20230807-backingimage-backup-support.md
View File

@ -1,7 +1,7 @@
# BackingImage Backup Support # BackingImage Backup Support
## Summary ## 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 ### Related Issues
@ -44,7 +44,7 @@ This improve the user experience and reduce the operation overhead.
#### Backup BackingImage - BackupStore #### 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`. - 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. - 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. - 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` - When restoring `BackingImage`
- `loadBackupBacking()`: load the metadata of the `BackupBackingImage` from the backup store - `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. - 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. - 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. - Check and update the ownership.
- Do cleanup if the deletion timestamp is set. - Do cleanup if the deletion timestamp is set.
- Cleanup the backup `BackingImage` on backup store - 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 - If `Status.LastSyncedAt.IsZero() && Spec.BackingImageName != ""` means **it is created by the User/API layer**, we need to do the backup
- Start the monitor - Start the monitor
- Pick one `BackingImageManager` - Pick one `BackingImageManager`
@ -181,7 +181,7 @@ This improve the user experience and reduce the operation overhead.
5. In `BackingImageDataSourceController` 5. In `BackingImageDataSourceController`
- No need to change, it will create the `BackingImageDataSourcePod` to do the restore. - No need to change, it will create the `BackingImageDataSourcePod` to do the restore.
6. In `BackingImageManager - data_source` 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 ```go
requestURL := fmt.Sprintf("http://%s/v1/files", client.Remote) requestURL := fmt.Sprintf("http://%s/v1/files", client.Remote)
req, err := http.NewRequest("POST", requestURL, nil) 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 #### API and UI changes In Summary
1. `longhorn-ui`: 1. `longhorn-ui`:
- Add a new page of `BackupBackingImage` like `Backup` - Add a new page of `BackupBackingImage` like `Backup`
- The columns on `BackupBackingImage` list page should be: `Name`, `Size`, `State`, `Created At`, `Operation`. - 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` - `Name` can be clicked and will show `Checksum` of the `BackupBackingImage`
@ -254,7 +254,7 @@ Integration tests
- Restore the Volume with same `BackingImage` - Restore the Volume with same `BackingImage`
- `BackingImage` should be restored and the `Volume` should also be restored successfully - `BackingImage` should be restored and the `Volume` should also be restored successfully
- `Volume` checksum is the same - `Volume` checksum is the same
Manual tests Manual tests
1. `BackupBackingImage` reuse blocks 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 - Create a `Volume` with `BackingImage` A, write some data and export to another `BackingImage` B
- Back up `BackingImage` A - Back up `BackingImage` A
- Back up `BackingImage` B - Back up `BackingImage` B
- Check it reuses the blocks when backing up `BackingImage` B (by trace log) - Check it reuses the blocks when backing up `BackingImage` B (by trace log)