Merge branch 'main' of https://github.com/qiuming-best/velero into pe…

…rf-test

.github/workflows/crds-verify-kind.yaml

@@ -49,7 +49,7 @@ jobs:
         run: |
           make local
 
-  # Check the common CLI against all kubernetes versions
+  # Check the common CLI against all Kubernetes versions
   crd-check:
     needs: build-cli
     runs-on: ubuntu-latest

.github/workflows/e2e-test-kind.yaml

@@ -53,7 +53,7 @@ jobs:
         run: |
           IMAGE=velero VERSION=pr-test make container
           docker save velero:pr-test -o ./velero.tar
-  # Run E2E test against all kubernetes versions on kind
+  # Run E2E test against all Kubernetes versions on kind
   run-e2e-test:
     needs: build
     runs-on: ubuntu-latest

.github/workflows/pr-codespell.yml

@@ -14,7 +14,44 @@ jobs:
       uses: codespell-project/actions-codespell@master
       with:
         # ignore the config/.../crd.go file as it's generated binary data that is edited elswhere.
-        skip: .git,*.png,*.jpg,*.woff,*.ttf,*.gif,*.ico,./config/crd/v1beta1/crds/crds.go,./config/crd/v1/crds/crds.go,,./config/crd/v2alpha1/crds/crds.go,./go.sum,./LICENSE
+        skip: .git,*.png,*.jpg,*.woff,*.ttf,*.gif,*.ico,./config/crd/v1beta1/crds/crds.go,./config/crd/v1/crds/crds.go,./config/crd/v2alpha1/crds/crds.go,./go.sum,./LICENSE
         ignore_words_list: iam,aks,ist,bridget,ue,shouldnot,atleast
         check_filenames: true
         check_hidden: true
+
+    - name: Velero.io word list check
+      shell: bash {0}
+      run: |
+        IGNORE_COMMENT="Velero.io word list : ignore"
+        FILES_TO_CHECK=$(find . -type f \
+          ! -path "./.git/*" \
+          ! -path "./site/content/docs/v*" \
+          ! -path "./changelogs/CHANGELOG-*" \
+          ! -path "./.github/workflows/pr-codespell.yml" \
+          ! -path "./site/static/fonts/Metropolis/Open Font License.md" \
+          ! -regex '.*\.\(png\|jpg\|woff\|ttf\|gif\|ico\|svg\)'
+        )
+        function check_word_in_files() {
+            local word=$1
+
+            xargs grep -Iinr "$word" <<< "$FILES_TO_CHECK" | \
+            grep -v "$IGNORE_COMMENT" | \
+            grep -i --color=always "$word" && \
+            EXIT_STATUS=1
+        }
+        function check_word_case_sensitive_in_files() {
+            local word=$1
+
+            xargs grep -Inr "$word" <<< "$FILES_TO_CHECK" | \
+            grep -v "$IGNORE_COMMENT" | \
+            grep --color=always "$word" && \
+            EXIT_STATUS=1
+        }
+        EXIT_STATUS=0
+        check_word_case_sensitive_in_files ' kubernetes '
+        check_word_in_files 'on-premise\b'
+        check_word_in_files 'back-up'
+        check_word_in_files 'plug-in'
+        check_word_in_files 'whitelist'
+        check_word_in_files 'blacklist'
+        exit $EXIT_STATUS

ADOPTERS.md

@@ -22,10 +22,10 @@ Below is a list of adopters of Velero in **production environments** that have
 publicly shared the details of how they use it.
 
 **[BitGo][20]**  
-BitGo uses Velero backup and restore capabilities to seamlessly provision and scale fullnode statefulsets on the fly as well as having it serve an integral piece for our kubernetes disaster-recovery story.
+BitGo uses Velero backup and restore capabilities to seamlessly provision and scale fullnode statefulsets on the fly as well as having it serve an integral piece for our Kubernetes disaster-recovery story.
 
 **[Bugsnag][30]**  
-We use Velero for managing backups of an internal instance of our on-premise clustered solution. We also recommend our users of [on-premise Bugsnag installations][31] use Velero for [managing their own backups][32].
+We use Velero for managing backups of an internal instance of our on-premise clustered solution. We also recommend our users of [on-premise Bugsnag installations](https://www.bugsnag.com/on-premise) use Velero for [managing their own backups](https://docs.bugsnag.com/on-premise/clustered/backup-restore/). <!-- Velero.io word list : ignore -->
 
 **[Banzai Cloud][60]**  
 [Banzai Cloud Pipeline][61] is a Kubernetes-based microservices platform that integrates services needed for Day-1 and Day-2 operations along with first-class support both for on-prem and hybrid multi-cloud deployments. We use Velero to periodically [backup and restore these clusters in case of disasters][62].
@@ -83,8 +83,6 @@ If you would like to add your logo to a future `Adopters of Velero` section on [
 [20]: https://bitgo.com
 
 [30]: https://bugsnag.com
-[31]: https://www.bugsnag.com/on-premise
-[32]: https://docs.bugsnag.com/on-premise/clustered/backup-restore/
 
 [40]: https://kyma-project.io
 [41]: https://kyma-project.io/docs/components/backup/#overview-overview

CHANGELOG.md

@@ -1,7 +1,9 @@
 ## Current release:
-  * [CHANGELOG-1.9.md][19]
+  * [CHANGELOG-1.11.md][21]
 
 ## Older releases:
+  * [CHANGELOG-1.10.md][20]
+  * [CHANGELOG-1.9.md][19]
   * [CHANGELOG-1.8.md][18]
   * [CHANGELOG-1.7.md][17]
   * [CHANGELOG-1.6.md][16]
@@ -22,6 +24,8 @@
   * [CHANGELOG-0.3.md][1]
 
 
+[21]: https://github.com/vmware-tanzu/velero/blob/main/changelogs/CHANGELOG-1.11.md
+[20]: https://github.com/vmware-tanzu/velero/blob/main/changelogs/CHANGELOG-1.10.md
 [19]: https://github.com/vmware-tanzu/velero/blob/main/changelogs/CHANGELOG-1.9.md
 [18]: https://github.com/vmware-tanzu/velero/blob/main/changelogs/CHANGELOG-1.8.md
 [17]: https://github.com/vmware-tanzu/velero/blob/main/changelogs/CHANGELOG-1.7.md

assets/README.md

@@ -1,6 +1,6 @@
 # Velero Assets
 
-This folder contains logo images for Velero in gray (for light backgrounds) and white (for dark backgrounds like black tshirts or dark mode!) – horizontal and stacked… in .eps and .svg.
+This folder contains logo images for Velero in gray (for light backgrounds) and white (for dark backgrounds like black t-shirts or dark mode!) – horizontal and stacked… in .eps and .svg.
 
 ## Some general guidelines for usage
 

changelogs/unreleased/6397-Nutrymaco

@@ -0,0 +1 @@
+Add missing CompletionTimestamp and metrics when restore moved into terminal phase in restoreOperationsReconciler

changelogs/unreleased/6415-mateusoliveira43

@@ -0,0 +1 @@
+fix: Typos and add more spell checking rules to CI

changelogs/unreleased/6476-reasonerjt

@@ -0,0 +1 @@
+Delete the expired deletebackuprequests that are stuck in "InProgress"

changelogs/unreleased/6481-blackpiglet

@@ -0,0 +1 @@
+Remove PVC's selector in backup's PVC action.

changelogs/unreleased/6533-Lyndon-Li

@@ -0,0 +1 @@
+Fix issue #6534, reset PVB CR's StorageLocation to the latest one during backup sync as same as the backup CR. Also fix similar problem with DataUploadResult for data mover restore.

changelogs/unreleased/6544-allenxu404

@@ -0,0 +1 @@
+check if restore crd exist before operating restores

changelogs/unreleased/6547-reasonerjt

@@ -0,0 +1 @@
+Delete moved snapshots when the backup is deleted

config/crd/v1/bases/velero.io_downloadrequests.yaml

@@ -55,7 +55,7 @@ spec:
                     - CSIBackupVolumeSnapshotContents
                     type: string
                   name:
-                    description: Name is the name of the kubernetes resource with
+                    description: Name is the name of the Kubernetes resource with
                       which the file is associated.
                     type: string
                 required:

config/crd/v1/bases/velero.io_restores.yaml

@@ -55,7 +55,7 @@ spec:
                 type: array
               existingResourcePolicy:
                 description: ExistingResourcePolicy specifies the restore behavior
-                  for the kubernetes resource to be restored
+                  for the Kubernetes resource to be restored
                 nullable: true
                 type: string
               hooks:

design/CLI/PoC/base/CRDs.yaml

@@ -509,7 +509,7 @@ spec:
                       - CSIBackupVolumeSnapshotContents
                   type: string
                 name:
-                  description: Name is the name of the kubernetes resource with
+                  description: Name is the name of the Kubernetes resource with
                     which the file is associated.
                   type: string
               required:

design/Implemented/backup-resources-order.md

@@ -6,7 +6,7 @@ During backup process, user may need to back up resources of specific type in so
 (Ex: primary-secondary database pods in a cluster).
 
 ## Goals
-- Enable user to specify an order of back up resources belong to specific resource type
+- Enable user to specify an order of backup resources belong to specific resource type
 
 ## Alternatives Considered
 - Use a plugin to backup an resources and all the sub resources.  For example use a plugin for StatefulSet and backup pods belong to the StatefulSet in specific order.  This plugin solution is not generic and requires plugin for each resource type.

design/Implemented/existing-resource-policy_design.md

@@ -1,6 +1,6 @@
 # Add support for `ExistingResourcePolicy` to restore API
 ## Abstract
-Velero currently does not support any restore policy on kubernetes resources that are already present in-cluster. Velero skips over the restore of the resource if it already exists in the namespace/cluster irrespective of whether the resource present in the restore is the same or different from the one present on the cluster. It is desired that Velero gives the option to the user to decide whether or not the resource in backup should overwrite the one present in the cluster.
+Velero currently does not support any restore policy on Kubernetes resources that are already present in-cluster. Velero skips over the restore of the resource if it already exists in the namespace/cluster irrespective of whether the resource present in the restore is the same or different from the one present on the cluster. It is desired that Velero gives the option to the user to decide whether or not the resource in backup should overwrite the one present in the cluster.
 
 ## Background
 As of Today, Velero will skip over the restoration of resources that already exist in the cluster. The current workflow followed by Velero is (Using a `service` that is backed up for example):
@@ -145,7 +145,7 @@ type RestoreSpec struct {
 .
 .
 .
-// ExistingResourcePolicy specifies the restore behaviour for the kubernetes resource to be restored
+// ExistingResourcePolicy specifies the restore behaviour for the Kubernetes resource to be restored
 // +optional
 ExistingResourcePolicy PolicyType
 
@@ -167,7 +167,7 @@ type RestoreSpec struct {
 .
 .
 .
-// ExistingResourcePolicyConfig specifies the restore behaviour for a particular/list of kubernetes resource(s) to be restored
+// ExistingResourcePolicyConfig specifies the restore behaviour for a particular/list of Kubernetes resource(s) to be restored
 // +optional
 ExistingResourcePolicyConfig []PolicyConfiguration
 
@@ -205,11 +205,11 @@ type RestoreSpec struct {
 .
 .
 .
-// ExistingResourceDefaultPolicy specifies the default restore behaviour for the kubernetes resource to be restored
+// ExistingResourceDefaultPolicy specifies the default restore behaviour for the Kubernetes resource to be restored
 // +optional
 existingResourceDefaultPolicy PolicyType
 
-// ExistingResourcePolicyOverrides specifies the restore behaviour for a particular/list of kubernetes resource(s) to be restored
+// ExistingResourcePolicyOverrides specifies the restore behaviour for a particular/list of Kubernetes resource(s) to be restored
 // +optional
 existingResourcePolicyOverrides []PolicyConfiguration
 

design/Implemented/general-progress-monitoring.md

@@ -5,9 +5,9 @@ This is intended as a replacement for the previously-approved Upload Progress Mo
 snapshot uploads to include what was previously called Async Backup/Restore Item Actions. This
 updated design should handle the combined set of use cases for those previously separate designs.
 
-Volume snapshotter plug-in are used by Velero to take snapshots of persistent volume contents. 
+Volume snapshotter plugin are used by Velero to take snapshots of persistent volume contents. 
 Depending on the underlying storage system, those snapshots may be available to use immediately, 
-they may be uploaded to stable storage internally by the plug-in or they may need to be uploaded after
+they may be uploaded to stable storage internally by the plugin or they may need to be uploaded after
 the snapshot has been taken. We would like for Velero to continue on to the next part of the backup as quickly
 as possible but we would also like the backup to not be marked as complete until it is a usable backup.  We'd also
 eventually like to bring the control of upload under the control of Velero and allow the user to make decisions
@@ -36,7 +36,7 @@ backup and restore *could* make use of this framework if their actions are refac
 Backup/RestoreItemActions.
 
 - Data Movers
-    - Data movers are asynchronous processes executed inside backup/restore item actions that applies to a specific kubernetes resources. A common use case for data mover is to backup/restore PVCs whose data we want to move to some form of backup storage outside of using velero kopia/restic implementations.
+    - Data movers are asynchronous processes executed inside backup/restore item actions that applies to a specific Kubernetes resources. A common use case for data mover is to backup/restore PVCs whose data we want to move to some form of backup storage outside of using velero kopia/restic implementations.
     - Workflow
         - User takes velero backup of PVC A
         - BIA plugin applies to PVCs with compatible storage driver
@@ -91,7 +91,7 @@ ID).
 
 ### Internal configuration and management
 In this model, movement of the snapshot to stable storage is under the control of the snapshot
-plug-in.  Decisions about where and when the snapshot gets moved to stable storage are not
+plugin.  Decisions about where and when the snapshot gets moved to stable storage are not
 directly controlled by Velero.  This is the model for the current VolumeSnapshot plugins.
 
 ### Velero controlled management
@@ -120,7 +120,7 @@ will remain in the "WaitingForPluginOperations" phase until all BIA/RIA operatio
 (for example, for a volume snapshotter, until all data has been successfully moved to persistent
 storage).  The backup/restore will not fail once it reaches this phase, although an error return
 from a plugin could cause a backup or restore to move to "PartiallyFailed".  If the backup is
-deleted (cancelled), the plug-ins will attempt to delete the snapshots and stop the data movement -
+deleted (cancelled), the plugins will attempt to delete the snapshots and stop the data movement -
 this may not be possible with all storage systems.
 
 In addition, for backups (but not restores), there will also be two additional phases, "Finalizing"
@@ -145,7 +145,7 @@ terminates
 When work on the backup/restore begins, it moves to the "InProgress" phase.  It remains in the
 "InProgress" phase until all pre/post execution hooks have been executed, all snapshots have been
 taken and the Kubernetes metadata and backup/restore info is safely written to the object store
-plug-in.
+plugin.
 
 In the current implementation, Restic backups will move data during the "InProgress" phase.  In the
 future, it may be possible to combine a snapshot with a Restic (or equivalent) backup which would
@@ -263,7 +263,7 @@ InProgress backups will not have a `velero-backup.json` present in the object st
 reconciliation, backups which do not have a `velero-backup.json` object in the object store will be
 ignored.
 
-## Plug-in API changes
+## Plugin API changes
 
 ### OperationProgress struct
 
@@ -289,15 +289,15 @@ Two new methods will be added to the VolumeSnapshotter interface:
     Cancel(snapshotID string) (error)
 
 Progress will report the current status of a snapshot upload.  This should be callable at
-any time after the snapshot has been taken.  In the event a plug-in is restarted, if the operationID
+any time after the snapshot has been taken.  In the event a plugin is restarted, if the operationID
 (snapshot ID) continues to be valid it should be possible to retrieve the progress.
 
 `error` is set if there is an issue retrieving progress.  If the snapshot is has encountered an
 error during the upload, the error should be returned in OperationProgress and error should be nil.
 
-### BackupItemAction and RestoreItemAction plug-in changes
+### BackupItemAction and RestoreItemAction plugin changes
 
-Currently CSI snapshots and the Velero Plug-in for vSphere are implemented as BackupItemAction
+Currently CSI snapshots and the Velero Plugin for vSphere are implemented as BackupItemAction
 plugins.  While the majority of BackupItemAction plugins do not take snapshots or upload data, this
 functionality is useful for any longstanding plugin operation managed by an external
 process/controller so we will modify BackupItemAction and RestoreItemAction to optionally return an
@@ -333,7 +333,7 @@ will be modified:
 	// initiate asynchronous actions, and a second slice of ResourceIdentifiers specifying related items
 	// which should be backed up after all asynchronous operations have completed. This last field will be
 	// ignored if operationID is empty, and should not be filled in unless the resource must be updated in the
-	// backup after async operations complete (i.e. some of the item's kubernetes metadata will be updated
+	// backup after async operations complete (i.e. some of the item's Kubernetes metadata will be updated
 	// during the asynch operation which will be required during restore)
 	Execute(item runtime.Unstructured, backup *api.Backup) (runtime.Unstructured, []velero.ResourceIdentifier, string, []velero.ResourceIdentifier, error)
     	
@@ -464,10 +464,10 @@ snapshot to stable storage.  CSI snapshots expose the _readyToUse_ state that, i
 indicates that the snapshot has been transferred to durable storage and is ready to be used.  The
 CSI BackupItemAction.Progress method will poll that field and when completed, return completion.
 
-## vSphere plug-in
+## vSphere plugin
 
-The vSphere Plug-in for Velero uploads snapshots to S3 in the background.  This is also a
-BackupItemAction plug-in, it will check the status of the Upload records for the snapshot and return
+The vSphere Plugin for Velero uploads snapshots to S3 in the background.  This is also a
+BackupItemAction plugin, it will check the status of the Upload records for the snapshot and return
 progress.
 
 ## Backup workflow changes
@@ -553,14 +553,14 @@ RestoreItemAction new plugin APIs
 New backup phases  
 New restore phases  
 Defer uploading `velero-backup.json`  
-AWS EBS plug-in Progress implementation  
+AWS EBS plugin Progress implementation  
 Operation monitoring  
 Implementation of `<backup-name>-itemoperations.json.gz` file  
 Implementation of `<restore-name>-itemoperations.json.gz` file
 Restart logic  
 Change in reconciliation logic to ignore backups/restores that have not completed  
-CSI plug-in BackupItemAction Progress implementation  
-vSphere plug-in BackupItemAction Progress implementation (vSphere plug-in team)  
+CSI plugin BackupItemAction Progress implementation  
+vSphere plugin BackupItemAction Progress implementation (vSphere plugin team)  
 
 
 # Open Questions

design/Implemented/multiple-label-selectors_design.md

@@ -3,7 +3,7 @@
 As of today Velero supports filtering of resources based on single label selector per backup. It is desired that Velero
 support backing up of resources based on multiple labels (OR logic).
 
-**Note:** This solution is required because kubernetes label selectors only allow AND logic of labels.
+**Note:** This solution is required because Kubernetes label selectors only allow AND logic of labels.
 
 ## Background
 Currently, Velero's Backup/Restore API has a spec field `LabelSelector` which helps in filtering of resources based on

design/Implemented/plugin-backup-and-restore-progress-design.md

@@ -393,7 +393,7 @@ Deletion of `VolumePluginBackup` CR can be delegated to plugin. Plugin can perfo
 ### 'core' Velero client/server required changes
 
 - Creation of the VolumePluginBackup/VolumePluginRestore CRDs at installation time
-- Persistence of VolumePluginBackup CRs towards the end of the back up operation
+- Persistence of VolumePluginBackup CRs towards the end of the backup operation
 - As part of backup synchronization, VolumePluginBackup CRs related to the backup will be synced.
 - Deletion of VolumePluginBackup when volumeshapshotter's DeleteSnapshot is called
 - Deletion of VolumePluginRestore as part of handling deletion of Restore CR