RM support for Escaped bool, float, null (#7118) (#7131)

* RM support for Escaped bool, float, null



* fix ci



---------

Signed-off-by: Anshul Ahuja <anshul.ahu@gmail.com>

.github/ISSUE_TEMPLATE/bug_report.md

@@ -5,7 +5,7 @@ about: Tell us about a problem you are experiencing
 ---
 
 **What steps did you take and what happened:**
-[A clear and concise description of what the bug is, and what commands you ran.)
+<!--A clear and concise description of what the bug is, and what commands you ran.-->
 
 
 **What did you expect to happen:**
@@ -25,7 +25,7 @@ Please provide the output of the following commands (Pasting long output into a
 
 
 **Anything else you would like to add:**
-[Miscellaneous information that will assist in solving the issue.]
+<!--Miscellaneous information that will assist in solving the issue.-->
 
 
 **Environment:**

.github/ISSUE_TEMPLATE/feature-enhancement-request.md

@@ -5,15 +5,15 @@ about: Suggest an idea for this project
 ---
 
 **Describe the problem/challenge you have**
-[A description of the current limitation/problem/challenge that you are experiencing.]
+<!--A description of the current limitation/problem/challenge that you are experiencing.-->
 
 
 **Describe the solution you'd like**
-[A clear and concise description of what you want to happen.]
+<!--A clear and concise description of what you want to happen.-->
 
 
 **Anything else you would like to add:**
-[Miscellaneous information that will assist in solving the issue.]
+<!--Miscellaneous information that will assist in solving the issue.-->
 
 
 **Environment:**

.github/auto-assignees.yml

@@ -9,7 +9,6 @@ reviewers:
 
   groups:
     maintainers:
-      - dsu-igeek
       - sseago
       - reasonerjt
       - ywk253100
@@ -19,7 +18,10 @@ reviewers:
       - Lyndon-Li
 
     tech-writer:
-      - a-mccarthy
+      - sseago
+      - reasonerjt
+      - ywk253100
+      - Lyndon-Li
 
 files:
   'site/**':

.github/stale.yml

@@ -1,44 +0,0 @@
-# Number of days of inactivity before an issue becomes stale
-daysUntilStale: 60
-# Number of days of inactivity before a stale issue is closed
-daysUntilClose: 14
-# Issues with these labels will never be considered stale
-exemptLabels:
-  - Epic
-  - Area/CLI
-  - Area/Cloud/AWS
-  - Area/Cloud/Azure
-  - Area/Cloud/GCP
-  - Area/Cloud/vSphere
-  - Area/CSI
-  - Area/Design
-  - Area/Documentation
-  - Area/Plugins
-  - Bug
-  - Enhancement/User
-  - kind/requirement
-  - kind/refactor
-  - kind/tech-debt
-  - limitation
-  - Needs investigation
-  - Needs triage
-  - Needs Product
-  - P0 - Hair on fire
-  - P1 - Important
-  - P2 - Long-term important
-  - P3 - Wouldn't it be nice if...
-  - Product Requirements
-  - Restic - GA
-  - Restic
-  - release-blocker
-  - Security
-# Label to use when marking an issue as stale
-staleLabel: staled
-# Comment to post when marking an issue as stale. Set to `false` to disable
-markComment: >
-  This issue has been automatically marked as stale because it has not had
-  recent activity. It will be closed if no further activity occurs. Thank you
-  for your contributions.
-# Comment to post when closing a stale issue. Set to `false` to disable
-closeComment: >
-  Closing the stale issue.

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

@@ -12,9 +12,9 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Set up Go
-        uses: actions/setup-go@v2
+        uses: actions/setup-go@v4
         with:
-          go-version: 1.20.3
+          go-version: '1.20.10'
         id: go
       # Look for a CLI that's made for this PR
       - name: Fetch built CLI
@@ -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

@@ -12,9 +12,9 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Set up Go
-        uses: actions/setup-go@v2
+        uses: actions/setup-go@v4
         with:
-          go-version: 1.20.3
+          go-version: '1.20.10'
         id: go
       # Look for a CLI that's made for this PR
       - name: Fetch built CLI
@@ -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
@@ -70,9 +70,9 @@ jobs:
       fail-fast: false
     steps:
       - name: Set up Go
-        uses: actions/setup-go@v2
+        uses: actions/setup-go@v4
         with:
-          go-version: 1.20.3
+          go-version: '1.20.10'
         id: go
       - name: Check out the code
         uses: actions/checkout@v2

.github/workflows/milestoned-issues.yml

@@ -1,18 +0,0 @@
-name: Add issues with a milestone to the milestone's board
-
-on:
-  issues:
-    types: [milestoned]
-
-jobs:
-  automate-project-columns:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: alex-page/github-project-automation-plus@v0.3.0
-        with:
-          # Do NOT add PRs to the board, as that's duplication. Their corresponding issue should be on the board.
-          if: ${{ !github.event.issue.pull_request }}
-          project: "${{ github.event.issue.milestone.title }}"
-          column: "To Do"
-          repo-token: ${{ secrets.GH_TOKEN }}
-

.github/workflows/nightly-trivy-scan.yml

@@ -0,0 +1,36 @@
+name: Trivy Nightly Scan
+on:
+  schedule:
+    - cron: '0 2 * * *' # run at 2 AM UTC
+
+jobs:
+  nightly-scan:
+    name: Trivy nightly scan
+    runs-on: ubuntu-latest
+    strategy:
+      fail-fast: false
+      matrix:
+        # maintain the versions of Velero those need security scan
+        versions: [main]
+        # list of images that need scan
+        images: [velero, velero-restore-helper]
+    permissions:
+      security-events: write  # for github/codeql-action/upload-sarif to upload SARIF results
+
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v3
+
+      - name: Run Trivy vulnerability scanner
+        uses: aquasecurity/trivy-action@master
+        with:
+          image-ref: 'docker.io/velero/${{ matrix.images }}:${{ matrix.versions }}'
+          severity: 'CRITICAL,HIGH,MEDIUM'
+          format: 'template'
+          template: '@/contrib/sarif.tpl'
+          output: 'trivy-results.sarif'
+
+      - name: Upload Trivy scan results to GitHub Security tab
+        uses: github/codeql-action/upload-sarif@v2
+        with:
+          sarif_file: 'trivy-results.sarif'

.github/workflows/pr-ci-check.yml

@@ -4,11 +4,13 @@ jobs:
   build:
     name: Run CI
     runs-on: ubuntu-latest
+    strategy:
+      fail-fast: false
     steps:
       - name: Set up Go
-        uses: actions/setup-go@v2
+        uses: actions/setup-go@v4
         with:
-          go-version: 1.20.3
+          go-version: '1.20.10'
         id: go
       - name: Check out the code
         uses: actions/checkout@v2
@@ -22,8 +24,9 @@ jobs:
       - name: Make ci
         run: make ci
       - name: Upload test coverage
-        uses: codecov/codecov-action@v2
+        uses: codecov/codecov-action@v3
         with:
           token: ${{ secrets.CODECOV_TOKEN }}
           files: coverage.out
           verbose: true
+          fail_ci_if_error: true

.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,./go.sum,./LICENSE
-        ignore_words_list: iam,aks,ist,bridget,ue,shouldnot
+        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

.github/workflows/pr-goreleaser.yml

@@ -0,0 +1,29 @@
+name: Verify goreleaser change
+
+on:
+  pull_request:
+    branches:
+      - 'main'
+      - 'release-**'
+    paths:
+      - '.goreleaser.yml'
+      - 'hack/release-tools/goreleaser.sh'
+
+jobs:
+  build:
+    name: Build
+    runs-on: ubuntu-latest
+    steps:
+    - uses: actions/checkout@v3
+      name: Checkout
+
+    - name: Verify .goreleaser.yml and try a dryrun release.
+      if: github.repository == 'vmware-tanzu/velero'
+      run: |
+        CHANGELOG=$(ls changelogs | sort -V -r | head -n 1)
+        GITHUB_TOKEN=${{ secrets.GITHUB_TOKEN }} \
+        REGISTRY=velero \
+        RELEASE_NOTES_FILE=changelogs/$CHANGELOG \
+        PUBLISH=false \
+        make release
+

.github/workflows/push-builder.yml

@@ -2,9 +2,7 @@ name: build-image
 
 on:
   push:
-    branches:
-      - 'main'
-      - 'release-**'
+    branches: [ main ]
     paths:
     - 'hack/build-image/Dockerfile'
 

.github/workflows/push.yml

@@ -16,9 +16,9 @@ jobs:
     steps:
 
     - name: Set up Go
-      uses: actions/setup-go@v2
+      uses: actions/setup-go@v4
       with:
-        go-version: 1.20.3
+        go-version: '1.20.10'
       id: go
 
     - uses: actions/checkout@v3
@@ -48,7 +48,10 @@ jobs:
         version: latest
 
     - name: Build
-      run: make local
+      run: |
+        make local
+        # Clean go cache to ease the build environment storage pressure.
+        go clean -modcache -cache
 
     - name: Test
       run: make test
@@ -60,10 +63,21 @@ jobs:
         files: coverage.out
         verbose: true
 
+    # Use the JSON key in secret to login gcr.io
+    - uses: 'docker/login-action@v2'
+      with:
+        registry: 'gcr.io' # or REGION.docker.pkg.dev
+        username: '_json_key'
+        password: '${{ secrets.GCR_SA_KEY }}'
+
     # Only try to publish the container image from the root repo; forks don't have permission to do so and will always get failures.
     - name: Publish container image
       if: github.repository == 'vmware-tanzu/velero'
       run: |
+        sudo swapoff -a
+        sudo rm -f /mnt/swapfile
+        docker image prune -a --force
+              
         # Build and push Velero image to docker registry
         docker login -u ${{ secrets.DOCKER_USER }} -p ${{ secrets.DOCKER_PASSWORD }}
         VERSION=$(./hack/docker-push.sh | grep 'VERSION:' | awk -F: '{print $2}' | xargs)
@@ -87,19 +101,3 @@ jobs:
         uploader ${VELERO_RESTORE_HELPER_IMAGE_FILE} ${GCS_BUCKET}
         uploader ${VELERO_IMAGE_BACKUP_FILE} ${GCS_BUCKET}
         uploader ${VELERO_RESTORE_HELPER_IMAGE_BACKUP_FILE} ${GCS_BUCKET}
-
-    # Use the JSON key in secret to login gcr.io
-    - uses: 'docker/login-action@v1'
-      with:
-        registry: 'gcr.io' # or REGION.docker.pkg.dev
-        username: '_json_key'
-        password: '${{ secrets.GCR_SA_KEY }}'
-
-    # Push image to GCR to facilitate some environments that have rate limitation to docker hub, e.g. vSphere.
-    - name: Publish container image to GCR
-      if: github.repository == 'vmware-tanzu/velero'
-      run: |
-        sudo swapoff -a
-        sudo rm -f /mnt/swapfile
-        docker image prune -a --force
-        REGISTRY=gcr.io/velero-gcp ./hack/docker-push.sh

.github/workflows/stale-issues.yml

@@ -1,8 +1,7 @@
 name: "Close stale issues and PRs"
 on:
   schedule:
-    # First of every month
-    - cron: "30 1 * * *"
+    - cron: "30 1 * * *" # Every day at 1:30 UTC
 
 jobs:
   stale:
@@ -11,14 +10,14 @@ jobs:
       - uses: actions/stale@v3
         with:
           repo-token: ${{ secrets.GITHUB_TOKEN }}
-          stale-issue-message: "This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days. If a Velero team member has requested log or more information, please provide the output of the shared commands."
-          close-issue-message: "This issue was closed because it has been stalled for 5 days with no activity."
-          days-before-issue-stale: 30
-          days-before-issue-close: 5
+          stale-issue-message: "This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days. If a Velero team member has requested log or more information, please provide the output of the shared commands."
+          close-issue-message: "This issue was closed because it has been stalled for 14 days with no activity."
+          days-before-issue-stale: 60
+          days-before-issue-close: 14
+          stale-issue-label: staled
           # Disable stale PRs for now; they can remain open.
           days-before-pr-stale: -1
           days-before-pr-close: -1
           # Only issues made after Feb 09 2021.
           start-date: "2021-09-02T00:00:00"
-          # Only make issues stale if they have these labels. Comma separated.
-          only-labels: "Needs info,Duplicate"
+          exempt-issue-labels: "Epic,Area/CLI,Area/Cloud/AWS,Area/Cloud/Azure,Area/Cloud/GCP,Area/Cloud/vSphere,Area/CSI,Area/Design,Area/Documentation,Area/Plugins,Bug,Enhancement/User,kind/requirement,kind/refactor,kind/tech-debt,limitation,Needs investigation,Needs triage,Needs Product,P0 - Hair on fire,P1 - Important,P2 - Long-term important,P3 - Wouldn't it be nice if...,Product Requirements,Restic - GA,Restic,release-blocker,Security"

.gitignore

@@ -38,6 +38,7 @@ _testmain.go
 # Hugo compiled data
 site/public
 site/resources
+site/.hugo_build.lock
 
 .vs
 
@@ -49,4 +50,7 @@ tilt-resources/deployment.yaml
 tilt-resources/node-agent.yaml
 tilt-resources/cloud
 
+# test generated files
 test/e2e/report.xml
+coverage.out
+__debug_bin*

.goreleaser.yml

@@ -46,6 +46,9 @@ archives:
     files:
       - LICENSE
       - examples/**/*
+    # Add the setting to resolve the DEPRECATED warning. Actually, Velero's case is not affected by the rlcp behavior change.
+    # https://github.com/orgs/goreleaser/discussions/3659#discussioncomment-4587257
+    rlcp: true 
 checksum:
   name_template: 'CHECKSUM'
 release:
@@ -54,3 +57,10 @@ release:
     name: velero
   draft: true
   prerelease: auto
+
+git:
+  # What should be used to sort tags when gathering the current and previous
+  # tags if there are more than one tag in the same commit.
+  #
+  # Default: `-version:refname`
+  tag_sort: -version:creatordate

ADOPTERS.md

@@ -3,6 +3,7 @@
 If you're using Velero and want to add your organization to this list, 
 [follow these directions][1]!
 
+<a href="https://www.pitsdatarecovery.net/" border="0" target="_blank"><img alt="pitsdatarecovery.net" src="site/static/img/adopters/PITSGlobalDataRecoveryServices.svg" height="50"></a>
 <a href="https://www.bitgo.com" border="0" target="_blank"><img alt="bitgo.com" src="site/static/img/adopters/BitGo.svg" height="50"></a>&nbsp; &nbsp; &nbsp;
 <a href="https://www.nirmata.com" border="0" target="_blank"><img alt="nirmata.com" src="site/static/img/adopters/nirmata.svg" height="50"></a>&nbsp; &nbsp; &nbsp;
 <a href="https://kyma-project.io/" border="0" target="_blank"><img alt="kyma-project.io" src="site/static/img/adopters/kyma.svg" height="50"></a>&nbsp; &nbsp; &nbsp;
@@ -21,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].
@@ -82,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

Dockerfile

@@ -13,7 +13,7 @@
 # limitations under the License.
 
 # Velero binary build section
-FROM --platform=$BUILDPLATFORM golang:1.20.3-bullseye as velero-builder
+FROM --platform=$BUILDPLATFORM golang:1.20.10-bullseye as velero-builder
 
 ARG GOPROXY
 ARG BIN
@@ -41,10 +41,13 @@ COPY . /go/src/github.com/vmware-tanzu/velero
 RUN mkdir -p /output/usr/bin && \
     export GOARM=$( echo "${GOARM}" | cut -c2-) && \
     go build -o /output/${BIN} \
-    -ldflags "${LDFLAGS}" ${PKG}/cmd/${BIN}
+    -ldflags "${LDFLAGS}" ${PKG}/cmd/${BIN} && \
+    go build -o /output/velero-helper \
+    -ldflags "${LDFLAGS}" ${PKG}/cmd/velero-helper && \
+    go clean -modcache -cache
 
 # Restic binary build section
-FROM --platform=$BUILDPLATFORM golang:1.19.8-bullseye as restic-builder
+FROM --platform=$BUILDPLATFORM golang:1.20.10-bullseye as restic-builder
 
 ARG BIN
 ARG TARGETOS
@@ -52,7 +55,7 @@ ARG TARGETARCH
 ARG TARGETVARIANT
 ARG RESTIC_VERSION
 
-env CGO_ENABLED=0 \
+ENV CGO_ENABLED=0 \
     GO111MODULE=on \
     GOPROXY=${GOPROXY} \
     GOOS=${TARGETOS} \
@@ -63,16 +66,17 @@ COPY . /go/src/github.com/vmware-tanzu/velero
 
 RUN mkdir -p /output/usr/bin && \
     export GOARM=$(echo "${GOARM}" | cut -c2-) && \
-    /go/src/github.com/vmware-tanzu/velero/hack/build-restic.sh
+    /go/src/github.com/vmware-tanzu/velero/hack/build-restic.sh && \
+    go clean -modcache -cache
 
 # Velero image packing section
-FROM gcr.io/distroless/base-nossl-debian11@sha256:9523ef8cf054e23a81e722d231c6f604ab43a03c5b174b5c8386c78c0b6473d0
+FROM paketobuildpacks/run-jammy-tiny:0.2.11
 
-LABEL maintainer="Nolan Brubaker <brubakern@vmware.com>"
+LABEL maintainer="Xun Jiang <jxun@vmware.com>"
 
 COPY --from=velero-builder /output /
 
 COPY --from=restic-builder /output /
 
-USER nonroot:nonroot
+USER cnb:cnb
 

MAINTAINERS.md

@@ -4,16 +4,16 @@
 
 ## Maintainers
 
-| Maintainer | GitHub ID | Affiliation |
-| --------------- | --------- | ----------- |
-| Dave Smith-Uchida | [dsu-igeek](https://github.com/dsu-igeek) | [Kasten](https://github.com/kastenhq/) |
-| Scott Seago | [sseago](https://github.com/sseago) | [OpenShift](https://github.com/openshift)
-| Daniel Jiang | [reasonerjt](https://github.com/reasonerjt) | [VMware](https://www.github.com/vmware/)
-| Wenkai Yin | [ywk253100](https://github.com/ywk253100) | [VMware](https://www.github.com/vmware/) |
-| Xun Jiang | [blackpiglet](https://github.com/blackpiglet) | [VMware](https://www.github.com/vmware/) |
-| Ming Qiu | [qiuming-best](https://github.com/qiuming-best) | [VMware](https://www.github.com/vmware/) |
-| Shubham Pampattiwar | [shubham-pampattiwar](https://github.com/shubham-pampattiwar) | [OpenShift](https://github.com/openshift)
-| Yonghui Li | [Lyndon-Li](https://github.com/Lyndon-Li) | [VMware](https://www.github.com/vmware/) |
+| Maintainer          | GitHub ID                                                     | Affiliation                               |
+|---------------------|---------------------------------------------------------------|-------------------------------------------|
+| Dave Smith-Uchida   | [dsu-igeek](https://github.com/dsu-igeek)                     | [Kasten](https://github.com/kastenhq/)    |
+| Scott Seago         | [sseago](https://github.com/sseago)                           | [OpenShift](https://github.com/openshift) |
+| Daniel Jiang        | [reasonerjt](https://github.com/reasonerjt)                   | [VMware](https://www.github.com/vmware/)  |
+| Wenkai Yin          | [ywk253100](https://github.com/ywk253100)                     | [VMware](https://www.github.com/vmware/)  |
+| Xun Jiang           | [blackpiglet](https://github.com/blackpiglet)                 | [VMware](https://www.github.com/vmware/)  |
+| Ming Qiu            | [qiuming-best](https://github.com/qiuming-best)               | [VMware](https://www.github.com/vmware/)  |
+| Shubham Pampattiwar | [shubham-pampattiwar](https://github.com/shubham-pampattiwar) | [OpenShift](https://github.com/openshift) |
+| Yonghui Li          | [Lyndon-Li](https://github.com/Lyndon-Li)                     | [VMware](https://www.github.com/vmware/)  |
 
 ## Emeritus Maintainers
 * Adnan Abdulhussein ([prydonius](https://github.com/prydonius))
@@ -28,12 +28,12 @@
 
 ## Velero Contributors & Stakeholders
 
-| Feature Area | Lead |
-| ----------------------------- | :---------------------: |
-| Architect | Dave Smith-Uchida [dsu-igeek](https://github.com/dsu-igeek) |
-| Technical Lead | Daniel Jiang [reasonerjt](https://github.com/reasonerjt) |
-| Kubernetes CSI Liaison |  |
-| Deployment |  |
-| Community Management | Orlin Vasilev [OrlinVasilev](https://github.com/OrlinVasilev) |
-| Product Management | Pradeep Kumar Chaturvedi [pradeepkchaturvedi](https://github.com/pradeepkchaturvedi) |
+| Feature Area           |                                         Lead                                         |
+|------------------------|:------------------------------------------------------------------------------------:|
+| Architect              |             Dave Smith-Uchida [dsu-igeek](https://github.com/dsu-igeek)              |
+| Technical Lead         |               Daniel Jiang [reasonerjt](https://github.com/reasonerjt)               |
+| Kubernetes CSI Liaison |                                                                                      |
+| Deployment             |                                                                                      |
+| Community Management   |            Orlin Vasilev [OrlinVasilev](https://github.com/OrlinVasilev)             |
+| Product Management     | Pradeep Kumar Chaturvedi [pradeepkchaturvedi](https://github.com/pradeepkchaturvedi) |
 

Makefile

@@ -22,9 +22,11 @@ PKG := github.com/vmware-tanzu/velero
 
 # Where to push the docker image.
 REGISTRY ?= velero
+GCR_REGISTRY ?= gcr.io/velero-gcp
 
 # Image name
 IMAGE ?= $(REGISTRY)/$(BIN)
+GCR_IMAGE ?= $(GCR_REGISTRY)/$(BIN)
 
 # We allow the Dockerfile to be configurable to enable the use of custom Dockerfiles
 # that pull base images from different registries.
@@ -66,8 +68,10 @@ TAG_LATEST ?= false
 
 ifeq ($(TAG_LATEST), true)
 	IMAGE_TAGS ?= $(IMAGE):$(VERSION) $(IMAGE):latest
+	GCR_IMAGE_TAGS ?= $(GCR_IMAGE):$(VERSION) $(GCR_IMAGE):latest
 else
 	IMAGE_TAGS ?= $(IMAGE):$(VERSION)
+	GCR_IMAGE_TAGS ?= $(GCR_IMAGE):$(VERSION)
 endif
 
 ifeq ($(shell docker buildx inspect 2>/dev/null | awk '/Status/ { print $$2 }'), running)
@@ -96,9 +100,6 @@ else
 	GIT_TREE_STATE ?= clean
 endif
 
-# The default linters used by lint and local-lint
-LINTERS ?= "gosec,goconst,gofmt,goimports,unparam"
-
 ###
 ### These variables should not need tweaking.
 ###
@@ -186,6 +187,7 @@ endif
 	--output=type=$(BUILDX_OUTPUT_TYPE) \
 	--platform $(BUILDX_PLATFORMS) \
 	$(addprefix -t , $(IMAGE_TAGS)) \
+	$(addprefix -t , $(GCR_IMAGE_TAGS)) \
 	--build-arg=GOPROXY=$(GOPROXY) \
 	--build-arg=PKG=$(PKG) \
 	--build-arg=BIN=$(BIN) \
@@ -221,27 +223,21 @@ endif
 
 lint:
 ifneq ($(SKIP_TESTS), 1)
-	@$(MAKE) shell CMD="-c 'hack/lint.sh $(LINTERS)'"
+	@$(MAKE) shell CMD="-c 'hack/lint.sh'"
 endif
 
 local-lint:
 ifneq ($(SKIP_TESTS), 1)
-	@hack/lint.sh $(LINTERS)
-endif
-
-lint-all:
-ifneq ($(SKIP_TESTS), 1)
-	@$(MAKE) shell CMD="-c 'hack/lint.sh $(LINTERS) true'"
-endif
-
-local-lint-all:
-ifneq ($(SKIP_TESTS), 1)
-	@hack/lint.sh $(LINTERS) true
+	@hack/lint.sh
 endif
 
 update:
 	@$(MAKE) shell CMD="-c 'hack/update-all.sh'"
 
+# update-crd is for development purpose only, it is faster than update, so is a shortcut when you want to generate CRD changes only
+update-crd:
+	@$(MAKE) shell CMD="-c 'hack/update-3generated-crd-code.sh'"	
+
 build-dirs:
 	@mkdir -p _output/bin/$(GOOS)/$(GOARCH)
 	@mkdir -p .go/src/$(PKG) .go/pkg .go/bin .go/std/$(GOOS)/$(GOARCH) .go/go-build .go/golangci-lint
@@ -353,7 +349,7 @@ serve-docs: build-image-hugo
 	-v "$$(pwd)/site:/srv/hugo" \
 	-it -p 1313:1313 \
 	$(HUGO_IMAGE) \
-	hugo server --bind=0.0.0.0 --enableGitInfo=false
+	server --bind=0.0.0.0 --enableGitInfo=false
 # gen-docs generates a new versioned docs directory under site/content/docs.
 # Please read the documentation in the script for instructions on how to use it.
 gen-docs:
@@ -362,3 +358,10 @@ gen-docs:
 .PHONY: test-e2e
 test-e2e: local
 	$(MAKE) -e VERSION=$(VERSION) -C test/e2e run
+
+.PHONY: test-perf
+test-perf: local
+	$(MAKE) -e VERSION=$(VERSION) -C test/perf run
+
+go-generate:
+	go generate ./pkg/...

README.md

@@ -1,11 +1,13 @@
 ![100]
 
 [![Build Status][1]][2] [![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/3811/badge)](https://bestpractices.coreinfrastructure.org/projects/3811)
-
+![GitHub release (latest SemVer)](https://img.shields.io/github/v/release/vmware-tanzu/velero)
 
 ## Overview
 
-Velero (formerly Heptio Ark) gives you tools to back up and restore your Kubernetes cluster resources and persistent volumes. You can run Velero with a public cloud platform or on-premises. Velero lets you:
+Velero (formerly Heptio Ark) gives you tools to back up and restore your Kubernetes cluster resources and persistent volumes. You can run Velero with a public cloud platform or on-premises. 
+
+Velero lets you:
 
 * Take backups of your cluster and restore in case of loss.
 * Migrate cluster resources to other clusters.
@@ -18,7 +20,7 @@ Velero consists of:
 
 ## Documentation
 
-[The documentation][29] provides a getting started guide and information about building from source, architecture, extending Velero, and more.
+[The documentation][29] provides a getting started guide and information about building from source, architecture, extending Velero and more.
 
 Please use the version selector at the top of the site to ensure you are using the appropriate documentation for your version of Velero.
 
@@ -38,15 +40,13 @@ See [the list of releases][6] to find out about feature changes.
 
 The following is a list of the supported Kubernetes versions for each Velero version.
 
-| Velero version | Expected Kubernetes version compatibility| Tested on Kubernetes version|
-|----------------|--------------------|--------------------|
-| 1.10           | 1.16-latest        |  1.22.5, 1.23.8, 1.24.6 and 1.25.1 |
-| 1.9            | 1.16-latest        |  1.20.5, 1.21.2, 1.22.5, 1.23, and 1.24 |
-| 1.8            | 1.16-latest        |  |
-| 1.6.3-1.7.1    | 1.12-latest        ||
-| 1.60-1.6.2     | 1.12-1.21          ||
-| 1.5            | 1.12-1.21          ||
-| 1.4            | 1.10-1.21          | |
+| Velero version | Expected Kubernetes version compatibility | Tested on Kubernetes version           |
+|----------------|-------------------------------------------|----------------------------------------|
+| 1.12           | 1.18-latest                               | 1.25.7, 1.26.5, 1.27.6 and 1.28.0      |
+| 1.11           | 1.18-latest                               | 1.23.10, 1.24.9, 1.25.5, and 1.26.1    |
+| 1.10           | 1.18-latest                               | 1.22.5, 1.23.8, 1.24.6 and 1.25.1      |
+| 1.9            | 1.18-latest                               | 1.20.5, 1.21.2, 1.22.5, 1.23, and 1.24 |
+| 1.8            | 1.18-latest                               |                                        |
 
 Velero supports IPv4, IPv6, and dual stack environments. Support for this was tested against Velero v1.8.
 
@@ -54,6 +54,8 @@ The Velero maintainers are continuously working to expand testing coverage, but
 
 If you are interested in using a different version of Kubernetes with a given Velero version, we'd recommend that you perform testing before installing or upgrading your environment. For full information around capabilities within a release, also see the Velero [release notes](https://github.com/vmware-tanzu/velero/releases) or Kubernetes [release notes](https://github.com/kubernetes/kubernetes/tree/master/CHANGELOG). See the Velero [support page](https://velero.io/docs/latest/support-process/) for information about supported versions of Velero.
 
+For each release, Velero maintainers run the test to ensure the upgrade path from n-2 minor release.  For example, before the release of v1.10.x, the test will verify that the backup created by v1.9.x and v1.8.x can be restored using the build to be tagged as v1.10.x.
+
 [1]: https://github.com/vmware-tanzu/velero/workflows/Main%20CI/badge.svg
 [2]: https://github.com/vmware-tanzu/velero/actions?query=workflow%3A"Main+CI"
 [4]: https://github.com/vmware-tanzu/velero/issues

Tiltfile

@@ -12,6 +12,8 @@ k8s_yaml([
     'config/crd/v1/bases/velero.io_schedules.yaml',
     'config/crd/v1/bases/velero.io_serverstatusrequests.yaml',
     'config/crd/v1/bases/velero.io_volumesnapshotlocations.yaml',
+    'config/crd/v2alpha1/bases/velero.io_datauploads.yaml',
+    'config/crd/v2alpha1/bases/velero.io_datadownloads.yaml',    
 ])
 
 # default values
@@ -50,7 +52,7 @@ git_sha = str(local("git rev-parse HEAD", quiet = True, echo_off = True)).strip(
 
 tilt_helper_dockerfile_header = """
 # Tilt image
-FROM golang:1.20.3 as tilt-helper
+FROM golang:1.20.10 as tilt-helper
 
 # Support live reloading with Tilt
 RUN wget --output-document /restart.sh --quiet https://raw.githubusercontent.com/windmilleng/rerun-process-wrapper/master/restart.sh  && \
@@ -60,9 +62,9 @@ RUN wget --output-document /restart.sh --quiet https://raw.githubusercontent.com
 
 additional_docker_helper_commands = """
 # Install delve to allow debugging
-RUN go get github.com/go-delve/delve/cmd/dlv
+RUN go install github.com/go-delve/delve/cmd/dlv@latest
 
-RUN wget -qO- https://dl.k8s.io/v1.19.2/kubernetes-client-linux-amd64.tar.gz | tar xvz
+RUN wget -qO- https://dl.k8s.io/v1.25.2/kubernetes-client-linux-amd64.tar.gz | tar xvz
 RUN wget -qO- https://get.docker.com | sh
 """
 
@@ -103,12 +105,12 @@ local_resource(
 
 local_resource(
     "restic_binary",
-    cmd = 'cd ' + '.' + ';mkdir -p _tiltbuild/restic; BIN=velero GOOS=linux GOARCH=amd64 RESTIC_VERSION=0.13.1 OUTPUT_DIR=_tiltbuild/restic ./hack/download-restic.sh',
+    cmd = 'cd ' + '.' + ';mkdir -p _tiltbuild/restic; BIN=velero GOOS=linux GOARCH=amd64 GOARM="" RESTIC_VERSION=0.13.1 OUTPUT_DIR=_tiltbuild/restic ./hack/build-restic.sh',
 )
 
 # Note: we need a distro with a bash shell to exec into the Velero container
 tilt_dockerfile_header = """
-FROM ubuntu:focal as tilt
+FROM ubuntu:22.04 as tilt
 
 RUN apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install -qq -y ca-certificates tzdata && rm -rf /var/lib/apt/lists/*
 
@@ -216,7 +218,7 @@ def enable_provider(provider):
 
     # Note: we need a distro with a shell to do a copy of the plugin binary
     tilt_dockerfile_header = """
-    FROM ubuntu:focal as tilt
+    FROM ubuntu:22.04 as tilt
     WORKDIR /
     COPY --from=tilt-helper /start.sh .
     COPY --from=tilt-helper /restart.sh .

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/CHANGELOG-1.10.md

@@ -1,76 +1,4 @@
-## v1.10.3
-### 2023-04-27
-
-### Download
-https://github.com/vmware-tanzu/velero/releases/tag/v1.10.3
-
-### Container Image
-`velero/velero:v1.10.3`
-
-### Documentation
-https://velero.io/docs/v1.10/
-
-### Upgrading
-https://velero.io/docs/v1.10/upgrade-to-1.10/
-
-### All changes
-  * Fix issue #6182. If pod is not running, don't treat it as an error, let it go and leave a warning. (#6188, @Lyndon-Li)
-  * Bump v1.10's Golang version to v1.20 (#6143, @blackpiglet)
-  * Ignore not found error during patching managedFields (#6135, @ywk253100)
-  * Fix issue #5972, don't assume errorField as error type when dealing with logger.WithError (#6086, @Lyndon-Li)
-  * Restore Services before Clusters (#6058, @ywk253100)
-
-## v1.10.2
-### 2023-02-22
-
-### Download
-https://github.com/vmware-tanzu/velero/releases/tag/v1.10.2
-
-### Container Image
-`velero/velero:v1.10.2`
-
-### Documentation
-https://velero.io/docs/v1.10/
-
-### Upgrading
-https://velero.io/docs/v1.10/upgrade-to-1.10/
-
-### All changes
-  * Update distroless image and fix CVE-2022-41717 for release-1.10 (#5891, @blackpiglet)
-  * Set Kopia IgnoreUnknownTypes in ErrorHandlingPolicy to True for ignoring backup unknown file type (#5890, @qiuiming-best)
-  * Add labels for velero installed namespace to support PSA. (#5888, @blackpiglet)
-  * Publish backupresults json to enhance error info during backups. (#5879, @anshulahuja98)
-  * Restore finalizer and managedFields of metadata during the restoration (#5877, @ywk253100)
-  * Add secret restore item action to handle service account token secret (#5869, @ywk253100)
-  * Correct PVB/PVR Failed Phase patching during startup (#5830, @kaovilai)
-
-## v1.10.1
-### 2023-01-19
-
-### Download
-https://github.com/vmware-tanzu/velero/releases/tag/v1.10.1
-
-### Container Image
-`velero/velero:v1.10.1`
-
-### Documentation
-https://velero.io/docs/v1.10/
-
-### Upgrading
-https://velero.io/docs/v1.10/upgrade-to-1.10/
-
-### All changes
-  * Fix Restic v0.14.0 HIGH grade CVEs. (#5817, @blackpiglet)
-  * Bump up golang net to fix CVE-2022-41721 (#5811, @Lyndon-Li)
-  * Bump up golang to 1.18.10 for Velero (#5780, @Lyndon-Li)
-  * Add PR container build action, which will not push image. Add GOARM parameter. Remove container-builder-env section. (#5770, @blackpiglet)
-  * Add Restic builder in Dockerfile, and keep the used built Golang image version in accordance with upstream Restic. (#5765, @blackpiglet)
-  * Fix issue 5696, check if the repo is still openable before running the prune and forget operation, if not, try to reconnect the repo (#5714, @Lyndon-Li)
-  * Fix error with Restic backup empty volumes (#5711, @qiuming-best)
-  * Prevent nil panic on exec restore hooks (#5708, @dymurray)
-  * Fix CVEs scanned by trivy (#5655, @qiuming-best)
-
-## v1.10.0
+  ## v1.10.0
 ### 2022-11-23
 
 ### Download

changelogs/CHANGELOG-1.11.md

@@ -0,0 +1,126 @@
+## v1.11
+### 2023-04-07
+
+### Download
+https://github.com/vmware-tanzu/velero/releases/tag/v1.11.0
+
+### Container Image
+`velero/velero:v1.11.0`
+
+### Documentation
+https://velero.io/docs/v1.11/
+
+### Upgrading
+https://velero.io/docs/v1.11/upgrade-to-1.11/
+
+### Highlights
+
+#### BackupItemAction v2
+This feature implements the BackupItemAction v2. BIA v2 has two new methods: Progress() and Cancel() and modifies the Execute() return value.
+
+The API change is needed to facilitate long-running BackupItemAction plugin actions that may not be complete when the Execute() method returns. This will allow long-running BackupItemAction plugin actions to continue in the background while the Velero moves to the following plugin or the next item.
+
+#### RestoreItemAction v2
+This feature implemented the RestoreItemAction v2. RIA v2 has three new methods: Progress(), Cancel(), and AreAdditionalItemsReady(), and it modifies RestoreItemActionExecuteOutput() structure in the RIA return value.
+
+The Progress() and Cancel() methods are needed to facilitate long-running RestoreItemAction plugin actions that may not be complete when the Execute() method returns. This will allow long-running RestoreItemAction plugin actions to continue in the background while the Velero moves to the following plugin or the next item. The AreAdditionalItemsReady() method is needed to allow plugins to tell Velero to wait until the returned additional items have been restored and are ready for use in the cluster before restoring the current item.
+
+#### Plugin Progress Monitoring
+This is intended as a replacement for the previously-approved Upload Progress Monitoring design ([Upload Progress Monitoring](https://github.com/vmware-tanzu/velero/blob/main/design/upload-progress.md)) to expand the supported use cases beyond snapshot upload to include what was previously called Async Backup/Restore Item Actions.
+
+#### Flexible resource policy that can filter volumes to skip in the backup
+This feature provides a flexible policy to filter volumes in the backup without requiring patching any labels or annotations to the pods or volumes. This policy is configured as k8s ConfigMap and maintained by the users themselves, and it can be extended to more scenarios in the future. By now, the policy rules out volumes from backup depending on the CSI driver, NFS setting, volume size, and StorageClass setting. Please refer to [policy API design](https://github.com/vmware-tanzu/velero/blob/main/design/Implemented/handle-backup-of-volumes-by-resources-filters.md#api-design) for the policy's ConifgMap format. It is not guaranteed to work on unofficial third-party plugins as it may not follow the existing backup workflow code logic of Velero.
+
+#### Resource Filters that can distinguish cluster scope and namespace scope resources
+This feature adds four new resource filters for backup. The new filters are separated into cluster scope and namespace scope. Before this feature, Velero could not filter cluster scope resources precisely. This feature provides the ability and refactors existing resource filter parameters.
+
+#### Add a parameter for setting the Velero server connection with the k8s API server's timeout
+In Velero, some code pieces need to communicate with the k8s API server. Before v1.11, these code pieces used hard-code timeout settings. This feature adds a resource-timeout parameter in the velero server binary to make it configurable.
+
+#### Add resource list in the output of the restore describe command
+Before this feature, Velero restore didn't have a restored resources list as the Velero backup. It's not convenient for users to learn what is restored. This feature adds the resources list and the handling result of the resources (including created, updated, failed, and skipped).
+
+#### Refactor controllers with controller-runtime
+In v1.11, Backup Controller and Restore controller are refactored with controller-runtime. Till v1.11, all Velero controllers use the controller-runtime framework.
+
+#### Runtime and dependencies
+To fix CVEs and keep pace with Golang, Velero made changes as follows:
+* Bump Golang runtime to v1.19.8.
+* Bump several dependent libraries to new versions.
+* Compile Restic (v0.15.0) with Golang v1.19.8 instead of packaging the official binary.
+
+
+### Breaking changes
+* The Velero CSI plugin now determines whether to restore Volume's data from snapshots on the restore's restorePVs setting. Before v1.11, the CSI plugin doesn't check the restorePVs parameter setting. 
+
+
+### Limitations/Known issues
+* The Flexible resource policy that can filter volumes to skip in the backup is not guaranteed to work on unofficial third-party plugins because the plugins may not follow the existing backup workflow code logic of Velero. The ConfigMap used as the policy is supposed to be maintained by users.
+
+
+### All Changes
+* Modify new scope resource filters name. (#6089, @blackpiglet)
+* Make Velero not exits when EnableCSI is on and CSI snapshot not installed (#6062, @blackpiglet)
+* Restore Services before Clusters (#6057, @ywk253100)
+* Fixed backup deletion bug related to async operations (#6041, @sseago)
+* Update Golang version to v1.19 for branch main. (#6039, @blackpiglet)
+* Fix issue #5972, don't assume errorField as error type when dealing with logger.WithError (#6028, @Lyndon-Li)
+* distinguish between New and InProgress operations (#6012, @sseago)
+* Modify golangci.yaml file. Resolve found lint issues. (#6008, @blackpiglet)
+* Remove Reference of itemsnapshotter (#5997, @reasonerjt)
+* minor fixes for backup_operations_controller (#5996, @sseago)
+* RIAv2 async operations controller work (#5993, @sseago)
+* Follow-on fixes for BIAv2 controller work (#5971, @sseago)
+* Refactor backup controller based on the controller-runtime framework. (#5969, @qiuming-best)
+* Fix client wait problem after async operation change, velero backup/restore --wait should check a full list of the terminal status (#5964, @Lyndon-Li)
+* Fix issue #5935, refactor the logics for backup/restore persistent log, so as to remove the contest to gzip writer (#5956, @Lyndon-Li)
+* Switch the base image to distroless/base-nossl-debian11 to reduce the CVE triage efforts (#5939, @ywk253100)
+* Wait for additional items to be ready before restoring current item (#5933, @sseago)
+* Add configurable server setting for default timeouts (#5926, @eemcmullan)
+* Add warning/error result to cmd `velero backup describe` (#5916, @allenxu404)
+* Fix Dependabot alerts. Use 1.18 and 1.19 golang instead of patch image in dockerfile. Add release-1.10 and release-1.9 in Trivy daily scan. (#5911, @blackpiglet)
+* Update client-go to v0.25.6 (#5907, @kaovilai)
+* Limit the concurrent number for backup's VolumeSnapshot operation. (#5900, @blackpiglet)
+* Fix goreleaser issue for resolving tags and updated it's version. (#5899, @anshulahuja98)
+* This is to fix issue 5881, enhance the PVB tracker in two modes, Track and Taken (#5894, @Lyndon-Li)
+* Add labels for velero installed namespace to support PSA. (#5873, @blackpiglet)
+* Add restored resource list in the restore describe command (#5867, @ywk253100)
+* Add a json output to cmd velero backup describe  (#5865, @allenxu404)
+* Make restore controller adopting the controller-runtime framework. (#5864, @blackpiglet)
+* Replace k8s.io/apimachinery/pkg/util/clock with k8s.io/utils/clock (#5859, @hezhizhen)
+* Restore finalizer and managedFields of metadata during the restoration (#5853, @ywk253100)
+* BIAv2 async operations controller work (#5849, @sseago)
+* Add secret restore item action to handle service account token secret (#5843, @ywk253100)
+* Add new resource filters can separate cluster and namespace scope resources. (#5838, @blackpiglet)
+* Correct PVB/PVR Failed Phase patching during startup (#5828, @kaovilai)
+* bump up golang net to fix CVE-2022-41721 (#5812, @Lyndon-Li)
+* Update CRD descriptions for SnapshotVolumes and restorePVs (#5807, @shubham-pampattiwar)
+* Add mapped selected-node existence check (#5806, @blackpiglet)
+* Add option "--service-account-name" to install cmd (#5802, @reasonerjt)
+* Enable staticcheck linter. (#5788, @blackpiglet)
+* Set Kopia IgnoreUnknownTypes in ErrorHandlingPolicy to True for ignoring backup unknown file type (#5786, @qiuming-best)
+* Bump up Restic version to 0.15.0  (#5784, @qiuming-best)
+* Add File system backup related metrics to Grafana dashboard
+  - Add metrics backup_warning_total for record of total warnings
+  - Add metrics backup_last_status for record of last status of the backup  (#5779, @allenxu404)
+* Design for Handling backup of volumes by resources filters (#5773, @qiuming-best)
+* Add PR container build action, which will not push image. Add GOARM parameter. (#5771, @blackpiglet)
+* Fix issue 5458, track pod volume backup until the CR is submitted in case it is skipped half way (#5769, @Lyndon-Li)
+* Fix issue 5226, invalidate the related backup repositories whenever the backup storage info change in BSL (#5768, @Lyndon-Li)
+* Add Restic builder in Dockerfile, and keep the used built Golang image version in accordance with upstream Restic. (#5764, @blackpiglet)
+* Fix issue 5043, after the restore pod is scheduled, check if the node-agent pod is running in the same node. (#5760, @Lyndon-Li)
+* Remove restore controller's redundant client. (#5759, @blackpiglet)
+* Define itemoperations.json format and update DownloadRequest API (#5752, @sseago)
+* Add Trivy nightly scan. (#5740, @jxun)
+* Fix issue 5696, check if the repo is still openable before running the prune and forget operation, if not, try to reconnect the repo (#5715, @Lyndon-Li)
+* Fix error with Restic backup empty volumes (#5713, @qiuming-best)
+* new backup and restore phases to support async plugin operations:
+  - WaitingForPluginOperations
+  - WaitingForPluginOperationsPartiallyFailed (#5710, @sseago)
+* Prevent nil panic on exec restore hooks (#5675, @dymurray)
+* Fix CVEs scanned by trivy (#5653, @qiuming-best)
+* Publish backupresults json to enhance error info during backups. (#5576, @anshulahuja98)
+* RestoreItemAction v2 API implementation (#5569, @sseago)
+* add new RestoreItemAction of "velero.io/change-image-name" to handle the issue mentioned at #5519 (#5540, @wenterjoy)
+* BackupItemAction v2 API implementation (#5442, @sseago)
+* Proposal to separate resource filter into cluster scope and namespace scope (#5333, @blackpiglet)

changelogs/CHANGELOG-1.12.md

@@ -0,0 +1,218 @@
+## v1.12.2
+### 2023-11-20
+
+### Download
+https://github.com/vmware-tanzu/velero/releases/tag/v1.12.2
+
+### Container Image
+`velero/velero:v1.12.2`
+
+### Documentation
+https://velero.io/docs/v1.12/
+
+### Upgrading
+https://velero.io/docs/v1.12/upgrade-to-1.12/
+
+### All changes
+* Fix issue #7068, due to a behavior of CSI external snapshotter, manipulations of VS and VSC may not be handled in the same order inside external snapshotter as the API is called. So add a protection finalizer to ensure the order (#7114, @Lyndon-Li)
+* Update Backup.Status.CSIVolumeSnapshotsCompleted during finalize (#7111, @kaovilai)
+* Cherry-pick #6917 - Support JSON Merge Patch and Strategic Merge Patch in Resource Modifiers (#7049, @27149chen)
+* Bump up Velero base image to latest patch release (#7110, @allenxu404)
+* Fix the node-agent missing metrics-address defines. (#7098, @yanggangtony)
+* Fix issue #7094, fallback to full backup if previous snapshot is not found (#7097, @Lyndon-Li)
+* Add DataUpload Result and CSI VolumeSnapshot check for restore PV. (#7087, @blackpiglet)
+* Fix issue #7027, data mover backup exposer should not assume the first volume as the backup volume in backup pod (#7060, @Lyndon-Li)
+* Truncate the credential file to avoid the change of secret content messing it up (#7058, @ywk253100)
+* restore: Use warning when Create IsAlreadyExist and Get error (#7054, @kaovilai)
+* Read information from the credential specified by BSL (#7033, @ywk253100)
+* Fix issue 6913: Velero Built-in Datamover: Backup stucks in phase WaitingForPluginOperations when Node Agent pod gets restarted (#7025, @shubham-pampattiwar)
+* Fix unified repository (kopia) s3 credentials profile selection (#6997, @kaovilai)
+
+## v1.12.1
+### 2023-10-20
+
+### Download
+https://github.com/vmware-tanzu/velero/releases/tag/v1.12.1
+
+### Container Image
+`velero/velero:v1.12.1`
+
+### Documentation
+https://velero.io/docs/v1.12/
+
+### Upgrading
+https://velero.io/docs/v1.12/upgrade-to-1.12/
+
+### Highlights
+
+#### Data Mover Adds Support for Block Mode Volumes
+For PersistentVolumes with volumeMode set as Block, the volumes are mounted as raw block devices in pods, in 1.12.1, Velero CSI snapshot data movement supports to backup and restore this kind of volumes under linux based Kubernetes clusters.
+
+#### New Parameter in Installation to Enable Data Mover
+The `velero install` sub-command now includes a new parameter,`--default-snapshot-move-data`, which configures Velero server to move data by default for all snapshots supporting data movement. This feature is useful for users who will always want to use VBDM for backups instead of plain CSI , as they no longer need to specify the `--snapshot-move-data` flag for each individual backup. 
+
+#### Velero Base Image change
+The base image previously used by Velero was `distroless`,  which contains several CVEs cannot be addressed quickly. As a result, Velero will now use `paketobuildpacks` image starting from this new version.
+
+### Limitations/Known issues
+* The data mover's support for block mode volumes is currently only applicable to Linux environments.
+
+### All changes
+* Import auth provider plugins (#6970, @0x113)
+* Perf improvements for existing resource restore (#6948, @sseago)
+* Retry failed create when using generateName (#6943, @sseago)
+* Fix issue #6647, add the --default-snapshot-move-data parameter to Velero install, so that users don't need to specify --snapshot-move-data per backup when they want to move snapshot data for all backups (#6940, @Lyndon-Li)
+* Partially fix #6734, guide Kubernetes' scheduler to spread backup pods evenly across nodes as much as possible, so that data mover backup could achieve better parallelism (#6935, @Lyndon-Li)
+* Replace the base image with paketobuildpacks image (#6934, @ywk253100)
+* Add support for block volumes with Kopia (#6897, @dzaninovic)
+* Set ParallelUploadAboveSize as MaxInt64 and flush repo after setting up policy so that policy is retrieved correctly by TreeForSource (#6886, @Lyndon-Li)
+* Kubernetes 1.27 new job label batch.kubernetes.io/controller-uid are deleted during restore per https://github.com/kubernetes/kubernetes/pull/114930 (#6713, @kaovilai)
+* Add `orLabelSelectors` for backup, restore commands (#6881, @nilesh-akhade)
+* Fix issue #6859, move plugin depending podvolume functions to util pkg, so as to remove the dependencies to unnecessary repository packages like kopia, azure, etc. (#6877, @Lyndon-Li)
+* Fix issue #6786, always delete VSC regardless of the deletion policy (#6873, @Lyndon-Li)
+* Fix #6988, always get region from BSL if it is not empty (#6991, @Lyndon-Li)
+* Add both non-Windows version and Windows version code for PVC block mode logic. (#6986, @blackpiglet)
+
+## v1.12
+### 2023-08-18
+
+### Download
+https://github.com/vmware-tanzu/velero/releases/tag/v1.12.0
+
+### Container Image
+`velero/velero:v1.12.0`
+
+### Documentation
+https://velero.io/docs/v1.12/
+
+### Upgrading
+https://velero.io/docs/v1.12/upgrade-to-1.12/
+
+### Highlights
+
+#### CSI Snapshot Data Movement
+CSI Snapshot Data Movement refers to back up CSI snapshot data from the volatile and limited production environment into durable, heterogeneous, and scalable backup storage in a consistent manner; and restore the data to volumes in the original or alternative environment.
+
+CSI Snapshot Data Movement is useful in below scenarios:
+
+* For on-premises users, the storage usually doesn't support durable snapshots, so it is impossible/less efficient/cost ineffective to keep volume snapshots by the storage This feature helps to move the snapshot data to a storage with lower cost and larger scale for long time preservation.
+* For public cloud users, this feature helps users to fulfill the multiple cloud strategy. It allows users to back up volume snapshots from one cloud provider and preserve or restore the data to another cloud provider. Then users will be free to flow their business data across cloud providers based on Velero backup and restore
+
+CSI Snapshot Data Movement is built according to the Volume Snapshot Data Movement design ([Volume Snapshot Data Movement design](https://github.com/vmware-tanzu/velero/blob/main/design/volume-snapshot-data-movement/volume-snapshot-data-movement.md)). Additionally, guidance on how to use the feature can be found in the Volume Snapshot Data Movement doc([Volume Snapshot Data Movement doc](https://velero.io/docs/v1.12/csi-snapshot-data-movement)).
+
+#### Resource Modifiers
+In many use cases, customers often need to substitute specific values in Kubernetes resources during the restoration process like changing the namespace, changing the storage class, etc. 
+
+To address this need, Resource Modifiers (also known as JSON Substitutions) offer a generic solution in the restore workflow. It allows the user to define filters for specific resources and then specify a JSON patch (operator, path, value) to apply to the resource. This feature simplifies the process of making substitutions without requiring the implementation of a new RestoreItemAction plugin. More design details can be found in Resource Modifiers design ([Resource Modifiers design](https://github.com/vmware-tanzu/velero/blob/main/design/Implemented/json-substitution-action-design.md)). For instructions on how to use the feature, please refer to Resource Modifiers doc([Resource Modifiers doc](https://velero.io/docs/v1.12/restore-resource-modifiers)). 
+
+#### Multiple VolumeSnapshotClasses
+Prior to version 1.12, the Velero CSI plugin would choose the VolumeSnapshotClass in the cluster based on matching driver names and the presence of the "velero.io/csi-volumesnapshot-class" label. However,  this approach proved inadequate for many user scenarios.
+
+With the introduction of version 1.12, Velero now offers support for multiple VolumeSnapshotClasses in the CSI Plugin, enabling users to select a specific class for a particular backup. More design details can be found in Multiple VolumeSnapshotClasses design ([Multiple VolumeSnapshotClasses design](https://github.com/vmware-tanzu/velero/blob/main/design/Implemented/multiple-csi-volumesnapshotclass-support.md)). For instructions on how to use the feature, please refer to Multiple VolumeSnapshotClasses doc ([Multiple VolumeSnapshotClasses doc](https://velero.io/docs/v1.12/csi/#implementation-choices)). 
+
+#### Restore Finalizer
+Before v1.12, the restore controller would only delete restore resources but wouldn’t delete restore data from the backup storage location when the command `velero restore delete` was executed. The only chance Velero deletes restores data from the backup storage location is when the associated backup is deleted.
+
+In this version, Velero introduces a finalizer that ensures the cleanup of all associated data for restores when running the command `velero restore delete`.
+
+#### Runtime and dependencies
+To fix CVEs and keep pace with Golang, Velero made changes as follows:
+* Bump Golang runtime to v1.20.7.
+* Bump several dependent libraries to new versions.
+* Bump Kopia to v0.13.
+
+
+### Breaking changes
+* Prior to v1.12, the parameter `uploader-type` for Velero installation had a default value of "restic". However, starting from this version, the default value has been changed to "kopia". This means that Velero will now use Kopia as the default path for file system backup.
+* The ways of setting CSI snapshot time have changed in v1.12. First, the sync waiting time for creating a snapshot handle in the CSI plugin is changed from the fixed 10 minutes into backup.Spec.CSISnapshotTimeout. The second, the async waiting time for VolumeSnapshot and VolumeSnapshotContent's status turning into `ReadyToUse` in operation uses the operation's timeout. The default value is 4 hours.
+* As from [Velero helm chart v4.0.0](https://github.com/vmware-tanzu/helm-charts/releases/tag/velero-4.0.0), it supports multiple BSL and VSL, and the BSL and VSL have changed from the map into a slice, and[ this breaking change](https://github.com/vmware-tanzu/helm-charts/pull/413) is not backward compatible. So it would be best to change the BSL and VSL configuration into slices before the Upgrade.
+* Prior to v1.12, deleting the Velero namespace would easily remove all the resources within it. However, with the introduction of finalizers attached to the Velero CR including `restore`, `dataupload`, and `datadownload` in this version, directly deleting Velero namespace may get stuck indefinitely because the pods responsible for handling the finalizers might be deleted before the resources attached to the finalizers. To avoid this issue, please use the command `velero uninstall` to delete all the Velero resources or ensure that you handle the finalizer appropriately before deleting the Velero namespace.
+
+
+### Limitations/Known issues
+* The Azure plugin supports Azure AD Workload identity way, but it only works for Velero native snapshots. It cannot support filesystem backup and snapshot data mover scenarios. 
+* File System backup under Kopia path and CSI Snapshot Data Movement backup fail to back up files that are large the 2GiB due to issue https://github.com/vmware-tanzu/velero/issues/6668.
+
+
+### All Changes
+* Fixes #6498. Get resource client again after restore actions in case resource's gv is changed. This is an improvement of pr #6499, to support group changes. A group change usually happens in a restore plugin which is used for resource conversion: convert a resource from a not supported gv to a supported gv (#6634, @27149chen)
+* Add API support for volMode block, only error for now. (#6608, @shawn-hurley)
+* Fix how the AWS credentials are obtained from configuration (#6598, @aws_creds)
+* Add performance E2E test (#6569, @qiuming-best)
+* Non default s3 credential profiles work on Unified Repository Provider (kopia) (#6558, @kaovilai)
+* Fix issue #6571, fix the problem for restore item operation to set the errors correctly so that they can be recorded by Velero restore and then reflect the correct status for Velero restore. (#6594, @Lyndon-Li)
+* Fix issue 6575, flush the repo after delete the snapshot, otherwise, the changes(deleting repo snapshot) cannot be committed to the repo. (#6587, @Lyndon-Li)
+* Delete moved snapshots when the backup is deleted (#6547, @reasonerjt)
+* check if restore crd exist before operating restores (#6544, @allenxu404)
+* Remove PVC's selector in backup's PVC action. (#6481, @blackpiglet)
+* Delete the expired deletebackuprequests that are stuck in "InProgress" (#6476, @reasonerjt)
+* 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. (#6533, @Lyndon-Li)
+* Fix issue #6519. Restrict the client manager of node-agent server to include only Velero resources from the server's namespace, otherwise, the controllers will try to reconcile CRs from all the installed Velero namespaces. (#6523, @Lyndon-Li)
+* Track the skipped PVC and print the summary in backup log  (#6496, @reasonerjt)
+* Add restore finalizer to clean up external resources (#6479, @allenxu404)
+* fix: Typos and add more spell checking rules to CI (#6415, @mateusoliveira43)
+* Add missing CompletionTimestamp and metrics when restore moved into terminal phase in restoreOperationsReconciler (#6397, @Nutrymaco)
+* Add support for resource Modifications in the restore flow. Also known as JSON Substitutions. (#6452, @anshulahuja98)
+* Remove dependency of the legacy client code from pkg/cmd directory part 2 (#6497, @blackpiglet)
+* Add data upload and download metrics (#6493, @allenxu404)
+* Fix issue 6490, If a backup/restore has multiple async operations and one operation fails while others are still in-progress, when all the operations finish, the backup/restore will be set as Completed falsely (#6491, @Lyndon-Li)
+* Velero Plugins no longer need kopia indirect dependency in their go.mod (#6484, @kaovilai)
+* Remove dependency of the legacy client code from pkg/cmd directory (#6469, @blackpiglet)
+* Add support for OpenStack CSI drivers topology keys (#6464, @openstack-csi-topology-keys)
+* Add exit code log and possible memory shortage warning log for Restic command failure. (#6459, @blackpiglet)
+* Modify DownloadRequest controller logic (#6433, @blackpiglet)
+* Add data download controller for data mover (#6436, @qiuming-best)
+* Fix hook filter display issue for backup describer (#6434, @allenxu404)
+* Retrieve DataUpload into backup result ConfigMap during volume snapshot restore. (#6410, @blackpiglet)
+* Design to add support for Multiple VolumeSnapshotClasses in CSI Plugin. (#5774, @anshulahuja98)
+* Clarify the deletion frequency for gc controller (#6414, @allenxu404)
+* Add unit tests for pkg/archive (#6396, @allenxu404)
+* Add UT for pkg/discovery (#6394, @qiuming-best)
+* Add UT for pkg/util (#6368, @Lyndon-Li)
+* Add the code for data mover restore expose (#6357, @Lyndon-Li)
+* Restore Endpoints before Services (#6315, @ywk253100)
+* Add warning message for volume snapshotter in data mover case. (#6377, @blackpiglet)
+* Add unit test for pkg/uploader (#6374, @qiuming-best)
+* Change kopia as the default path of PVB (#6370, @Lyndon-Li)
+* Do not persist VolumeSnapshot and VolumeSnapshotContent for snapshot DataMover case. (#6366, @blackpiglet)
+* Add data mover related options in CLI (#6365, @ywk253100)
+* Add dataupload controller (#6337, @qiuming-best)
+* Add UT cases for pkg/podvolume (#6336, @Lyndon-Li)
+* Remove Wait VolumeSnapshot to ReadyToUse logic. (#6327, @blackpiglet)
+* Enhance the code because of #6297, the return value of GetBucketRegion is not recorded, as a result, when it fails, we have no way to get the cause (#6326, @Lyndon-Li)
+* Skip updating status when CRDs are restored (#6325, @reasonerjt)
+* Include namespaces needed by namespaced-scope resources in backup. (#6320, @blackpiglet)
+* Update metrics when backup failed with validation error (#6318, @ywk253100)
+* Add the code for data mover backup expose (#6308, @Lyndon-Li)
+* Fix a PVR issue for generic data path -- the namespace remap was not honored, and enhance the code for better error handling (#6303, @Lyndon-Li)
+* Add default values for defaultItemOperationTimeout and itemOperationSyncFrequency in velero CLI  (#6298, @shubham-pampattiwar)
+* Add UT cases for pkg/repository (#6296, @Lyndon-Li)
+* Fix issue #5875. Since Kopia has supported IAM, Velero should not require static credentials all the time (#6283, @Lyndon-Li)
+* Fixed a bug where status.progress is not getting updated for backups. (#6276, @kkothule)
+* Add code change for async generic data path that is used by both PVB/PVR and data mover (#6226, @Lyndon-Li)
+* Add data mover CRD under v2alpha1, include DataUpload CRD and DataDownload CRD (#6176, @Lyndon-Li)
+* Remove any dataSource or dataSourceRef fields from PVCs in PVC BIA for cases of
+prior PVC restores with CSI (#6111, @eemcmullan)
+* Add the design for Volume Snapshot Data Movement (#5968, @Lyndon-Li)
+* Fix issue #5123, Kopia repository supports self-cert CA for S3 compatible storage. (#6268, @Lyndon-Li)
+* Bump up Kopia to v0.13 (#6248, @Lyndon-Li)
+* log volumes to backup to help debug why `IsPodRunning` is called. (#6232, @kaovilai)
+* Enable errcheck linter and resolve found issues (#6208, @blackpiglet)
+* Enable more linters, and remove mal-functioned milestoned issue action. (#6194, @blackpiglet)
+* Enable stylecheck linter and resolve found issues. (#6185, @blackpiglet)
+* Fix issue #6182. If pod is not running, don't treat it as an error, let it go and leave a warning. (#6184, @Lyndon-Li)
+* Enable staticcheck and resolve found issues (#6183, @blackpiglet)
+* Enable linter revive and resolve found errors: part 2 (#6177, @blackpiglet)
+* Enable linter revive and resolve found errors: part 1 (#6173, @blackpiglet)
+* Fix usestdlibvars and whitespace linters issues. (#6162, @blackpiglet)
+* Update Golang to v1.20 for main. (#6158, @blackpiglet)
+* Make GetPluginConfig accessible from other packages. (#6151, @tkaovila)
+* Ignore not found error during patching managedFields (#6136, @ywk253100)
+* Fix the goreleaser issues and add a new goreleaser action (#6109, @blackpiglet)
+* Add CSI snapshot data movement doc (#6793, @Lyndon-Li)
+* Use old(origin) namespace in resource modifier conditions in case namespace may change during restore (#6724, @27149chen)
+* Fix #6752: add namespace exclude check. (#6762, @blackpiglet)
+* Update restore controller logic for restore deletion (#6761, @ywk253100)
+* Fix issue #6753, remove the check for read-only BSL in restore async operation controller since Velero cannot fully support read-only mode BSL in restore at present (#6758, @Lyndon-Li)
+* Fixes #6636, skip subresource in resource discovery (#6688, @27149chen)
+* This pr made some improvements in Resource Modifiers:1. add label selector 2. change the field name from groupKind to groupResource (#6704, @27149chen)

changelogs/CHANGELOG-1.8.md

@@ -61,7 +61,7 @@ in progress for 1.9.
 * Add rbac and annotation test cases (#4455, @mqiu)
 * remove --crds-version in velero install command. (#4446, @jxun)
 * Upgrade e2e test vsphere plugin (#4440, @mqiu)
-* Fix e2e test failures for the inappropriate optimaze of velero install (#4438, @mqiu)
+* Fix e2e test failures for the inappropriate optimize of velero install (#4438, @mqiu)
 * Limit backup namespaces on test resource filtering cases (#4437, @mqiu)
 * Bump up Go to 1.17 (#4431, @reasonerjt)
 * Added `<backup name>`-itemsnapshots.json.gz to the backup format.  This file exists

cmd/velero-helper/velero-helper.go

@@ -0,0 +1,27 @@
+package main
+
+import (
+	"fmt"
+	"os"
+	"time"
+)
+
+const (
+	// workingModePause indicates it is for general purpose to hold the pod under running state
+	workingModePause = "pause"
+)
+
+func main() {
+	if len(os.Args) < 2 {
+		fmt.Fprintln(os.Stderr, "ERROR: at least one argument must be provided, the working mode")
+		os.Exit(1)
+	}
+
+	switch os.Args[1] {
+	case workingModePause:
+		time.Sleep(time.Duration(1<<63 - 1))
+	default:
+		fmt.Fprintln(os.Stderr, "ERROR: wrong working mode provided")
+		os.Exit(1)
+	}
+}

cmd/velero-restore-helper/velero-restore-helper.go

@@ -18,7 +18,6 @@ package main
 
 import (
 	"fmt"
-	"io/ioutil"
 	"os"
 	"path/filepath"
 	"time"
@@ -34,18 +33,16 @@ func main() {
 	defer ticker.Stop()
 
 	for {
-		select {
-		case <-ticker.C:
-			if done() {
-				fmt.Println("All restic restores are done")
-				err := removeFolder()
-				if err != nil {
-					fmt.Println(err)
-				} else {
-					fmt.Println("Done cleanup .velero folder")
-				}
-				return
+		<-ticker.C
+		if done() {
+			fmt.Println("All restic restores are done")
+			err := removeFolder()
+			if err != nil {
+				fmt.Println(err)
+			} else {
+				fmt.Println("Done cleanup .velero folder")
 			}
+			return
 		}
 	}
 }
@@ -54,7 +51,7 @@ func main() {
 // within the .velero/ subdirectory whose name is equal to os.Args[1], or
 // false otherwise
 func done() bool {
-	children, err := ioutil.ReadDir("/restores")
+	children, err := os.ReadDir("/restores")
 	if err != nil {
 		fmt.Fprintf(os.Stderr, "ERROR reading /restores directory: %s\n", err)
 		return false
@@ -84,7 +81,7 @@ func done() bool {
 
 // remove .velero folder
 func removeFolder() error {
-	children, err := ioutil.ReadDir("/restores")
+	children, err := os.ReadDir("/restores")
 	if err != nil {
 		return err
 	}

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

@@ -1,11 +1,9 @@
-
 ---
 apiVersion: apiextensions.k8s.io/v1
 kind: CustomResourceDefinition
 metadata:
   annotations:
-    controller-gen.kubebuilder.io/version: v0.7.0
-  creationTimestamp: null
+    controller-gen.kubebuilder.io/version: v0.12.0
   name: backuprepositories.velero.io
 spec:
   group: velero.io
@@ -96,9 +94,3 @@ spec:
     served: true
     storage: true
     subresources: {}
-status:
-  acceptedNames:
-    kind: ""
-    plural: ""
-  conditions: []
-  storedVersions: []

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

@@ -1,11 +1,9 @@
-
 ---
 apiVersion: apiextensions.k8s.io/v1
 kind: CustomResourceDefinition
 metadata:
   annotations:
-    controller-gen.kubebuilder.io/version: v0.7.0
-  creationTimestamp: null
+    controller-gen.kubebuilder.io/version: v0.12.0
   name: backups.velero.io
 spec:
   group: velero.io
@@ -42,6 +40,11 @@ spec:
                   CSI VolumeSnapshot status turns to ReadyToUse during creation, before
                   returning error as timeout. The default value is 10 minute.
                 type: string
+              datamover:
+                description: DataMover specifies the data mover to be used by the
+                  backup. If DataMover is "" or "velero", the built-in data mover
+                  will be used.
+                type: string
               defaultVolumesToFsBackup:
                 description: DefaultVolumesToFsBackup specifies whether pod volume
                   file system backup should be used for all volumes by default.
@@ -54,6 +57,24 @@ spec:
                   Use DefaultVolumesToFsBackup instead."
                 nullable: true
                 type: boolean
+              excludedClusterScopedResources:
+                description: ExcludedClusterScopedResources is a slice of cluster-scoped
+                  resource type names to exclude from the backup. If set to "*", all
+                  cluster-scoped resource types are excluded. The default value is
+                  empty.
+                items:
+                  type: string
+                nullable: true
+                type: array
+              excludedNamespaceScopedResources:
+                description: ExcludedNamespaceScopedResources is a slice of namespace-scoped
+                  resource type names to exclude from the backup. If set to "*", all
+                  namespace-scoped resource types are excluded. The default value
+                  is empty.
+                items:
+                  type: string
+                nullable: true
+                type: array
               excludedNamespaces:
                 description: ExcludedNamespaces contains a list of namespaces that
                   are not included in the backup.
@@ -157,6 +178,7 @@ spec:
                                 contains only "value". The requirements are ANDed.
                               type: object
                           type: object
+                          x-kubernetes-map-type: atomic
                         name:
                           description: Name is the name of this hook.
                           type: string
@@ -259,6 +281,23 @@ spec:
                   resources should be included for consideration in the backup.
                 nullable: true
                 type: boolean
+              includedClusterScopedResources:
+                description: IncludedClusterScopedResources is a slice of cluster-scoped
+                  resource type names to include in the backup. If set to "*", all
+                  cluster-scoped resource types are included. The default value is
+                  empty, which means only related cluster-scoped resources are included.
+                items:
+                  type: string
+                nullable: true
+                type: array
+              includedNamespaceScopedResources:
+                description: IncludedNamespaceScopedResources is a slice of namespace-scoped
+                  resource type names to include in the backup. The default value
+                  is "*".
+                items:
+                  type: string
+                nullable: true
+                type: array
               includedNamespaces:
                 description: IncludedNamespaces is a slice of namespace names to include
                   objects from. If empty, all namespaces are included.
@@ -273,6 +312,11 @@ spec:
                   type: string
                 nullable: true
                 type: array
+              itemOperationTimeout:
+                description: ItemOperationTimeout specifies the time used to wait
+                  for asynchronous BackupItemAction operations The default value is
+                  1 hour.
+                type: string
               labelSelector:
                 description: LabelSelector is a metav1.LabelSelector to filter with
                   when adding individual objects to the backup. If empty or nil, all
@@ -320,6 +364,7 @@ spec:
                       are ANDed.
                     type: object
                 type: object
+                x-kubernetes-map-type: atomic
               metadata:
                 properties:
                   labels:
@@ -380,6 +425,7 @@ spec:
                         are ANDed.
                       type: object
                   type: object
+                  x-kubernetes-map-type: atomic
                 nullable: true
                 type: array
               orderedResources:
@@ -392,9 +438,35 @@ spec:
                   "objectname".
                 nullable: true
                 type: object
+              resourcePolicy:
+                description: ResourcePolicy specifies the referenced resource policies
+                  that backup should follow
+                properties:
+                  apiGroup:
+                    description: APIGroup is the group for the resource being referenced.
+                      If APIGroup is not specified, the specified Kind must be in
+                      the core API group. For any other third-party types, APIGroup
+                      is required.
+                    type: string
+                  kind:
+                    description: Kind is the type of resource being referenced
+                    type: string
+                  name:
+                    description: Name is the name of resource being referenced
+                    type: string
+                required:
+                - kind
+                - name
+                type: object
+                x-kubernetes-map-type: atomic
+              snapshotMoveData:
+                description: SnapshotMoveData specifies whether snapshot data should
+                  be moved
+                nullable: true
+                type: boolean
               snapshotVolumes:
-                description: SnapshotVolumes specifies whether to take cloud snapshots
-                  of any PV's referenced in the set of objects included in the Backup.
+                description: SnapshotVolumes specifies whether to take snapshots of
+                  any PV's referenced in the set of objects included in the Backup.
                 nullable: true
                 type: boolean
               storageLocation:
@@ -415,6 +487,20 @@ spec:
           status:
             description: BackupStatus captures the current status of a Velero backup.
             properties:
+              backupItemOperationsAttempted:
+                description: BackupItemOperationsAttempted is the total number of
+                  attempted async BackupItemAction operations for this backup.
+                type: integer
+              backupItemOperationsCompleted:
+                description: BackupItemOperationsCompleted is the total number of
+                  successfully completed async BackupItemAction operations for this
+                  backup.
+                type: integer
+              backupItemOperationsFailed:
+                description: BackupItemOperationsFailed is the total number of async
+                  BackupItemAction operations for this backup which ended with an
+                  error.
+                type: integer
               completionTimestamp:
                 description: CompletionTimestamp records the time a backup was completed.
                   Completion time is recorded even on failed backups. Completion time
@@ -455,6 +541,10 @@ spec:
                 - New
                 - FailedValidation
                 - InProgress
+                - WaitingForPluginOperations
+                - WaitingForPluginOperationsPartiallyFailed
+                - Finalizing
+                - FinalizingPartiallyFailed
                 - Completed
                 - PartiallyFailed
                 - Failed
@@ -513,9 +603,3 @@ spec:
         type: object
     served: true
     storage: true
-status:
-  acceptedNames:
-    kind: ""
-    plural: ""
-  conditions: []
-  storedVersions: []

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

@@ -1,11 +1,9 @@
-
 ---
 apiVersion: apiextensions.k8s.io/v1
 kind: CustomResourceDefinition
 metadata:
   annotations:
-    controller-gen.kubebuilder.io/version: v0.7.0
-  creationTimestamp: null
+    controller-gen.kubebuilder.io/version: v0.12.0
   name: backupstoragelocations.velero.io
 spec:
   group: velero.io
@@ -92,6 +90,7 @@ spec:
                 required:
                 - key
                 type: object
+                x-kubernetes-map-type: atomic
               default:
                 description: Default indicates this location is the default backup
                   storage location.
@@ -173,9 +172,3 @@ spec:
     served: true
     storage: true
     subresources: {}
-status:
-  acceptedNames:
-    kind: ""
-    plural: ""
-  conditions: []
-  storedVersions: []

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

@@ -1,11 +1,9 @@
-
 ---
 apiVersion: apiextensions.k8s.io/v1
 kind: CustomResourceDefinition
 metadata:
   annotations:
-    controller-gen.kubebuilder.io/version: v0.7.0
-  creationTimestamp: null
+    controller-gen.kubebuilder.io/version: v0.12.0
   name: deletebackuprequests.velero.io
 spec:
   group: velero.io
@@ -73,9 +71,3 @@ spec:
     served: true
     storage: true
     subresources: {}
-status:
-  acceptedNames:
-    kind: ""
-    plural: ""
-  conditions: []
-  storedVersions: []

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

@@ -1,11 +1,9 @@
-
 ---
 apiVersion: apiextensions.k8s.io/v1
 kind: CustomResourceDefinition
 metadata:
   annotations:
-    controller-gen.kubebuilder.io/version: v0.7.0
-  creationTimestamp: null
+    controller-gen.kubebuilder.io/version: v0.12.0
   name: downloadrequests.velero.io
 spec:
   group: velero.io
@@ -46,15 +44,18 @@ spec:
                     - BackupLog
                     - BackupContents
                     - BackupVolumeSnapshots
-                    - BackupItemSnapshots
+                    - BackupItemOperations
                     - BackupResourceList
+                    - BackupResults
                     - RestoreLog
                     - RestoreResults
+                    - RestoreResourceList
+                    - RestoreItemOperations
                     - CSIBackupVolumeSnapshots
                     - 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:
@@ -87,9 +88,3 @@ spec:
         type: object
     served: true
     storage: true
-status:
-  acceptedNames:
-    kind: ""
-    plural: ""
-  conditions: []
-  storedVersions: []

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

@@ -1,11 +1,9 @@
-
 ---
 apiVersion: apiextensions.k8s.io/v1
 kind: CustomResourceDefinition
 metadata:
   annotations:
-    controller-gen.kubebuilder.io/version: v0.7.0
-  creationTimestamp: null
+    controller-gen.kubebuilder.io/version: v0.12.0
   name: podvolumebackups.velero.io
 spec:
   group: velero.io
@@ -117,6 +115,7 @@ spec:
                     description: 'UID of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids'
                     type: string
                 type: object
+                x-kubernetes-map-type: atomic
               repoIdentifier:
                 description: RepoIdentifier is the backup repository identifier.
                 type: string
@@ -199,9 +198,3 @@ spec:
     served: true
     storage: true
     subresources: {}
-status:
-  acceptedNames:
-    kind: ""
-    plural: ""
-  conditions: []
-  storedVersions: []

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

@@ -1,11 +1,9 @@
-
 ---
 apiVersion: apiextensions.k8s.io/v1
 kind: CustomResourceDefinition
 metadata:
   annotations:
-    controller-gen.kubebuilder.io/version: v0.7.0
-  creationTimestamp: null
+    controller-gen.kubebuilder.io/version: v0.12.0
   name: podvolumerestores.velero.io
 spec:
   group: velero.io
@@ -110,6 +108,7 @@ spec:
                     description: 'UID of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids'
                     type: string
                 type: object
+                x-kubernetes-map-type: atomic
               repoIdentifier:
                 description: RepoIdentifier is the backup repository identifier.
                 type: string
@@ -184,9 +183,3 @@ spec:
     served: true
     storage: true
     subresources: {}
-status:
-  acceptedNames:
-    kind: ""
-    plural: ""
-  conditions: []
-  storedVersions: []

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

@@ -1,11 +1,9 @@
-
 ---
 apiVersion: apiextensions.k8s.io/v1
 kind: CustomResourceDefinition
 metadata:
   annotations:
-    controller-gen.kubebuilder.io/version: v0.7.0
-  creationTimestamp: null
+    controller-gen.kubebuilder.io/version: v0.12.0
   name: restores.velero.io
 spec:
   group: velero.io
@@ -56,8 +54,8 @@ spec:
                 nullable: true
                 type: array
               existingResourcePolicy:
-                description: ExistingResourcePolicy specifies the restore behaviour
-                  for the kubernetes resource to be restored
+                description: ExistingResourcePolicy specifies the restore behavior
+                  for the Kubernetes resource to be restored
                 nullable: true
                 type: string
               hooks:
@@ -147,6 +145,7 @@ spec:
                                 contains only "value". The requirements are ANDed.
                               type: object
                           type: object
+                          x-kubernetes-map-type: atomic
                         name:
                           description: Name is the name of this hook.
                           type: string
@@ -203,6 +202,7 @@ spec:
                                       to be added to a pod during its restore.
                                     items:
                                       type: object
+                                      x-kubernetes-preserve-unknown-fields: true
                                     type: array
                                     x-kubernetes-preserve-unknown-fields: true
                                   timeout:
@@ -238,6 +238,10 @@ spec:
                   type: string
                 nullable: true
                 type: array
+              itemOperationTimeout:
+                description: ItemOperationTimeout specifies the time used to wait
+                  for RestoreItemAction operations The default value is 1 hour.
+                type: string
               labelSelector:
                 description: LabelSelector is a metav1.LabelSelector to filter with
                   when restoring individual objects from the backup. If empty or nil,
@@ -285,6 +289,7 @@ spec:
                       are ANDed.
                     type: object
                 type: object
+                x-kubernetes-map-type: atomic
               namespaceMapping:
                 additionalProperties:
                   type: string
@@ -346,6 +351,7 @@ spec:
                         are ANDed.
                       type: object
                   type: object
+                  x-kubernetes-map-type: atomic
                 nullable: true
                 type: array
               preserveNodePorts:
@@ -353,9 +359,31 @@ spec:
                   from backup.
                 nullable: true
                 type: boolean
+              resourceModifier:
+                description: ResourceModifier specifies the reference to JSON resource
+                  patches that should be applied to resources before restoration.
+                nullable: true
+                properties:
+                  apiGroup:
+                    description: APIGroup is the group for the resource being referenced.
+                      If APIGroup is not specified, the specified Kind must be in
+                      the core API group. For any other third-party types, APIGroup
+                      is required.
+                    type: string
+                  kind:
+                    description: Kind is the type of resource being referenced
+                    type: string
+                  name:
+                    description: Name is the name of resource being referenced
+                    type: string
+                required:
+                - kind
+                - name
+                type: object
+                x-kubernetes-map-type: atomic
               restorePVs:
                 description: RestorePVs specifies whether to restore all included
-                  PVs from snapshot (via the cloudprovider).
+                  PVs from snapshot
                 nullable: true
                 type: boolean
               restoreStatus:
@@ -412,6 +440,8 @@ spec:
                 - New
                 - FailedValidation
                 - InProgress
+                - WaitingForPluginOperations
+                - WaitingForPluginOperationsPartiallyFailed
                 - Completed
                 - PartiallyFailed
                 - Failed
@@ -432,6 +462,20 @@ spec:
                       due to plugins that return additional related items to restore
                     type: integer
                 type: object
+              restoreItemOperationsAttempted:
+                description: RestoreItemOperationsAttempted is the total number of
+                  attempted async RestoreItemAction operations for this restore.
+                type: integer
+              restoreItemOperationsCompleted:
+                description: RestoreItemOperationsCompleted is the total number of
+                  successfully completed async RestoreItemAction operations for this
+                  restore.
+                type: integer
+              restoreItemOperationsFailed:
+                description: RestoreItemOperationsFailed is the total number of async
+                  RestoreItemAction operations for this restore which ended with an
+                  error.
+                type: integer
               startTimestamp:
                 description: StartTimestamp records the time the restore operation
                   was started. The server's time is used for StartTimestamps
@@ -454,9 +498,3 @@ spec:
         type: object
     served: true
     storage: true
-status:
-  acceptedNames:
-    kind: ""
-    plural: ""
-  conditions: []
-  storedVersions: []

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

@@ -1,11 +1,9 @@
-
 ---
 apiVersion: apiextensions.k8s.io/v1
 kind: CustomResourceDefinition
 metadata:
   annotations:
-    controller-gen.kubebuilder.io/version: v0.7.0
-  creationTimestamp: null
+    controller-gen.kubebuilder.io/version: v0.12.0
   name: schedules.velero.io
 spec:
   group: velero.io
@@ -72,6 +70,11 @@ spec:
                       for CSI VolumeSnapshot status turns to ReadyToUse during creation,
                       before returning error as timeout. The default value is 10 minute.
                     type: string
+                  datamover:
+                    description: DataMover specifies the data mover to be used by
+                      the backup. If DataMover is "" or "velero", the built-in data
+                      mover will be used.
+                    type: string
                   defaultVolumesToFsBackup:
                     description: DefaultVolumesToFsBackup specifies whether pod volume
                       file system backup should be used for all volumes by default.
@@ -84,6 +87,24 @@ spec:
                       entirely in future. Use DefaultVolumesToFsBackup instead."
                     nullable: true
                     type: boolean
+                  excludedClusterScopedResources:
+                    description: ExcludedClusterScopedResources is a slice of cluster-scoped
+                      resource type names to exclude from the backup. If set to "*",
+                      all cluster-scoped resource types are excluded. The default
+                      value is empty.
+                    items:
+                      type: string
+                    nullable: true
+                    type: array
+                  excludedNamespaceScopedResources:
+                    description: ExcludedNamespaceScopedResources is a slice of namespace-scoped
+                      resource type names to exclude from the backup. If set to "*",
+                      all namespace-scoped resource types are excluded. The default
+                      value is empty.
+                    items:
+                      type: string
+                    nullable: true
+                    type: array
                   excludedNamespaces:
                     description: ExcludedNamespaces contains a list of namespaces
                       that are not included in the backup.
@@ -188,6 +209,7 @@ spec:
                                     requirements are ANDed.
                                   type: object
                               type: object
+                              x-kubernetes-map-type: atomic
                             name:
                               description: Name is the name of this hook.
                               type: string
@@ -294,6 +316,24 @@ spec:
                       resources should be included for consideration in the backup.
                     nullable: true
                     type: boolean
+                  includedClusterScopedResources:
+                    description: IncludedClusterScopedResources is a slice of cluster-scoped
+                      resource type names to include in the backup. If set to "*",
+                      all cluster-scoped resource types are included. The default
+                      value is empty, which means only related cluster-scoped resources
+                      are included.
+                    items:
+                      type: string
+                    nullable: true
+                    type: array
+                  includedNamespaceScopedResources:
+                    description: IncludedNamespaceScopedResources is a slice of namespace-scoped
+                      resource type names to include in the backup. The default value
+                      is "*".
+                    items:
+                      type: string
+                    nullable: true
+                    type: array
                   includedNamespaces:
                     description: IncludedNamespaces is a slice of namespace names
                       to include objects from. If empty, all namespaces are included.
@@ -308,6 +348,11 @@ spec:
                       type: string
                     nullable: true
                     type: array
+                  itemOperationTimeout:
+                    description: ItemOperationTimeout specifies the time used to wait
+                      for asynchronous BackupItemAction operations The default value
+                      is 1 hour.
+                    type: string
                   labelSelector:
                     description: LabelSelector is a metav1.LabelSelector to filter
                       with when adding individual objects to the backup. If empty
@@ -355,6 +400,7 @@ spec:
                           "value". The requirements are ANDed.
                         type: object
                     type: object
+                    x-kubernetes-map-type: atomic
                   metadata:
                     properties:
                       labels:
@@ -415,6 +461,7 @@ spec:
                             only "value". The requirements are ANDed.
                           type: object
                       type: object
+                      x-kubernetes-map-type: atomic
                     nullable: true
                     type: array
                   orderedResources:
@@ -427,8 +474,34 @@ spec:
                       simply use "objectname".
                     nullable: true
                     type: object
+                  resourcePolicy:
+                    description: ResourcePolicy specifies the referenced resource
+                      policies that backup should follow
+                    properties:
+                      apiGroup:
+                        description: APIGroup is the group for the resource being
+                          referenced. If APIGroup is not specified, the specified
+                          Kind must be in the core API group. For any other third-party
+                          types, APIGroup is required.
+                        type: string
+                      kind:
+                        description: Kind is the type of resource being referenced
+                        type: string
+                      name:
+                        description: Name is the name of resource being referenced
+                        type: string
+                    required:
+                    - kind
+                    - name
+                    type: object
+                    x-kubernetes-map-type: atomic
+                  snapshotMoveData:
+                    description: SnapshotMoveData specifies whether snapshot data
+                      should be moved
+                    nullable: true
+                    type: boolean
                   snapshotVolumes:
-                    description: SnapshotVolumes specifies whether to take cloud snapshots
+                    description: SnapshotVolumes specifies whether to take snapshots
                       of any PV's referenced in the set of objects included in the
                       Backup.
                     nullable: true
@@ -484,9 +557,3 @@ spec:
     served: true
     storage: true
     subresources: {}
-status:
-  acceptedNames:
-    kind: ""
-    plural: ""
-  conditions: []
-  storedVersions: []

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

@@ -1,11 +1,9 @@
-
 ---
 apiVersion: apiextensions.k8s.io/v1
 kind: CustomResourceDefinition
 metadata:
   annotations:
-    controller-gen.kubebuilder.io/version: v0.7.0
-  creationTimestamp: null
+    controller-gen.kubebuilder.io/version: v0.12.0
   name: serverstatusrequests.velero.io
 spec:
   group: velero.io
@@ -77,9 +75,3 @@ spec:
         type: object
     served: true
     storage: true
-status:
-  acceptedNames:
-    kind: ""
-    plural: ""
-  conditions: []
-  storedVersions: []

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

@@ -1,11 +1,9 @@
-
 ---
 apiVersion: apiextensions.k8s.io/v1
 kind: CustomResourceDefinition
 metadata:
   annotations:
-    controller-gen.kubebuilder.io/version: v0.7.0
-  creationTimestamp: null
+    controller-gen.kubebuilder.io/version: v0.12.0
   name: volumesnapshotlocations.velero.io
 spec:
   group: velero.io
@@ -63,6 +61,7 @@ spec:
                 required:
                 - key
                 type: object
+                x-kubernetes-map-type: atomic
               provider:
                 description: Provider is the provider of the volume storage.
                 type: string
@@ -84,9 +83,3 @@ spec:
         type: object
     served: true
     storage: true
-status:
-  acceptedNames:
-    kind: ""
-    plural: ""
-  conditions: []
-  storedVersions: []

config/crd/v2alpha1/bases/velero.io_datadownloads.yaml

@@ -0,0 +1,176 @@
+---
+apiVersion: apiextensions.k8s.io/v1
+kind: CustomResourceDefinition
+metadata:
+  annotations:
+    controller-gen.kubebuilder.io/version: v0.12.0
+  name: datadownloads.velero.io
+spec:
+  group: velero.io
+  names:
+    kind: DataDownload
+    listKind: DataDownloadList
+    plural: datadownloads
+    singular: datadownload
+  scope: Namespaced
+  versions:
+  - additionalPrinterColumns:
+    - description: DataDownload status such as New/InProgress
+      jsonPath: .status.phase
+      name: Status
+      type: string
+    - description: Time duration since this DataDownload was started
+      jsonPath: .status.startTimestamp
+      name: Started
+      type: date
+    - description: Completed bytes
+      format: int64
+      jsonPath: .status.progress.bytesDone
+      name: Bytes Done
+      type: integer
+    - description: Total bytes
+      format: int64
+      jsonPath: .status.progress.totalBytes
+      name: Total Bytes
+      type: integer
+    - description: Name of the Backup Storage Location where the backup data is stored
+      jsonPath: .spec.backupStorageLocation
+      name: Storage Location
+      type: string
+    - description: Time duration since this DataDownload was created
+      jsonPath: .metadata.creationTimestamp
+      name: Age
+      type: date
+    - description: Name of the node where the DataDownload is processed
+      jsonPath: .status.node
+      name: Node
+      type: string
+    name: v2alpha1
+    schema:
+      openAPIV3Schema:
+        properties:
+          apiVersion:
+            description: 'APIVersion defines the versioned schema of this representation
+              of an object. Servers should convert recognized schemas to the latest
+              internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources'
+            type: string
+          kind:
+            description: 'Kind is a string value representing the REST resource this
+              object represents. Servers may infer this from the endpoint the client
+              submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds'
+            type: string
+          metadata:
+            type: object
+          spec:
+            description: DataDownloadSpec is the specification for a DataDownload.
+            properties:
+              backupStorageLocation:
+                description: BackupStorageLocation is the name of the backup storage
+                  location where the backup repository is stored.
+                type: string
+              cancel:
+                description: Cancel indicates request to cancel the ongoing DataDownload.
+                  It can be set when the DataDownload is in InProgress phase
+                type: boolean
+              dataMoverConfig:
+                additionalProperties:
+                  type: string
+                description: DataMoverConfig is for data-mover-specific configuration
+                  fields.
+                type: object
+              datamover:
+                description: DataMover specifies the data mover to be used by the
+                  backup. If DataMover is "" or "velero", the built-in data mover
+                  will be used.
+                type: string
+              operationTimeout:
+                description: OperationTimeout specifies the time used to wait internal
+                  operations, before returning error as timeout.
+                type: string
+              snapshotID:
+                description: SnapshotID is the ID of the Velero backup snapshot to
+                  be restored from.
+                type: string
+              sourceNamespace:
+                description: SourceNamespace is the original namespace where the volume
+                  is backed up from. It may be different from SourcePVC's namespace
+                  if namespace is remapped during restore.
+                type: string
+              targetVolume:
+                description: TargetVolume is the information of the target PVC and
+                  PV.
+                properties:
+                  namespace:
+                    description: Namespace is the target namespace
+                    type: string
+                  pv:
+                    description: PV is the name of the target PV that is created by
+                      Velero restore
+                    type: string
+                  pvc:
+                    description: PVC is the name of the target PVC that is created
+                      by Velero restore
+                    type: string
+                required:
+                - namespace
+                - pv
+                - pvc
+                type: object
+            required:
+            - backupStorageLocation
+            - operationTimeout
+            - snapshotID
+            - sourceNamespace
+            - targetVolume
+            type: object
+          status:
+            description: DataDownloadStatus is the current status of a DataDownload.
+            properties:
+              completionTimestamp:
+                description: CompletionTimestamp records the time a restore was completed.
+                  Completion time is recorded even on failed restores. The server's
+                  time is used for CompletionTimestamps
+                format: date-time
+                nullable: true
+                type: string
+              message:
+                description: Message is a message about the DataDownload's status.
+                type: string
+              node:
+                description: Node is name of the node where the DataDownload is processed.
+                type: string
+              phase:
+                description: Phase is the current state of the DataDownload.
+                enum:
+                - New
+                - Accepted
+                - Prepared
+                - InProgress
+                - Canceling
+                - Canceled
+                - Completed
+                - Failed
+                type: string
+              progress:
+                description: Progress holds the total number of bytes of the snapshot
+                  and the current number of restored bytes. This can be used to display
+                  progress information about the restore operation.
+                properties:
+                  bytesDone:
+                    format: int64
+                    type: integer
+                  totalBytes:
+                    format: int64
+                    type: integer
+                type: object
+              startTimestamp:
+                description: StartTimestamp records the time a restore was started.
+                  The server's time is used for StartTimestamps
+                format: date-time
+                nullable: true
+                type: string
+            type: object
+        type: object
+    served: true
+    storage: true
+    subresources: {}

config/crd/v2alpha1/bases/velero.io_datauploads.yaml

@@ -0,0 +1,200 @@
+---
+apiVersion: apiextensions.k8s.io/v1
+kind: CustomResourceDefinition
+metadata:
+  annotations:
+    controller-gen.kubebuilder.io/version: v0.12.0
+  name: datauploads.velero.io
+spec:
+  group: velero.io
+  names:
+    kind: DataUpload
+    listKind: DataUploadList
+    plural: datauploads
+    singular: dataupload
+  scope: Namespaced
+  versions:
+  - additionalPrinterColumns:
+    - description: DataUpload status such as New/InProgress
+      jsonPath: .status.phase
+      name: Status
+      type: string
+    - description: Time duration since this DataUpload was started
+      jsonPath: .status.startTimestamp
+      name: Started
+      type: date
+    - description: Completed bytes
+      format: int64
+      jsonPath: .status.progress.bytesDone
+      name: Bytes Done
+      type: integer
+    - description: Total bytes
+      format: int64
+      jsonPath: .status.progress.totalBytes
+      name: Total Bytes
+      type: integer
+    - description: Name of the Backup Storage Location where this backup should be
+        stored
+      jsonPath: .spec.backupStorageLocation
+      name: Storage Location
+      type: string
+    - description: Time duration since this DataUpload was created
+      jsonPath: .metadata.creationTimestamp
+      name: Age
+      type: date
+    - description: Name of the node where the DataUpload is processed
+      jsonPath: .status.node
+      name: Node
+      type: string
+    name: v2alpha1
+    schema:
+      openAPIV3Schema:
+        properties:
+          apiVersion:
+            description: 'APIVersion defines the versioned schema of this representation
+              of an object. Servers should convert recognized schemas to the latest
+              internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources'
+            type: string
+          kind:
+            description: 'Kind is a string value representing the REST resource this
+              object represents. Servers may infer this from the endpoint the client
+              submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds'
+            type: string
+          metadata:
+            type: object
+          spec:
+            description: DataUploadSpec is the specification for a DataUpload.
+            properties:
+              backupStorageLocation:
+                description: BackupStorageLocation is the name of the backup storage
+                  location where the backup repository is stored.
+                type: string
+              cancel:
+                description: Cancel indicates request to cancel the ongoing DataUpload.
+                  It can be set when the DataUpload is in InProgress phase
+                type: boolean
+              csiSnapshot:
+                description: If SnapshotType is CSI, CSISnapshot provides the information
+                  of the CSI snapshot.
+                nullable: true
+                properties:
+                  snapshotClass:
+                    description: SnapshotClass is the name of the snapshot class that
+                      the volume snapshot is created with
+                    type: string
+                  storageClass:
+                    description: StorageClass is the name of the storage class of
+                      the PVC that the volume snapshot is created from
+                    type: string
+                  volumeSnapshot:
+                    description: VolumeSnapshot is the name of the volume snapshot
+                      to be backed up
+                    type: string
+                required:
+                - storageClass
+                - volumeSnapshot
+                type: object
+              dataMoverConfig:
+                additionalProperties:
+                  type: string
+                description: DataMoverConfig is for data-mover-specific configuration
+                  fields.
+                nullable: true
+                type: object
+              datamover:
+                description: DataMover specifies the data mover to be used by the
+                  backup. If DataMover is "" or "velero", the built-in data mover
+                  will be used.
+                type: string
+              operationTimeout:
+                description: OperationTimeout specifies the time used to wait internal
+                  operations, before returning error as timeout.
+                type: string
+              snapshotType:
+                description: SnapshotType is the type of the snapshot to be backed
+                  up.
+                type: string
+              sourceNamespace:
+                description: SourceNamespace is the original namespace where the volume
+                  is backed up from. It is the same namespace for SourcePVC and CSI
+                  namespaced objects.
+                type: string
+              sourcePVC:
+                description: SourcePVC is the name of the PVC which the snapshot is
+                  taken for.
+                type: string
+            required:
+            - backupStorageLocation
+            - operationTimeout
+            - snapshotType
+            - sourceNamespace
+            - sourcePVC
+            type: object
+          status:
+            description: DataUploadStatus is the current status of a DataUpload.
+            properties:
+              completionTimestamp:
+                description: CompletionTimestamp records the time a backup was completed.
+                  Completion time is recorded even on failed backups. Completion time
+                  is recorded before uploading the backup object. The server's time
+                  is used for CompletionTimestamps
+                format: date-time
+                nullable: true
+                type: string
+              dataMoverResult:
+                additionalProperties:
+                  type: string
+                description: DataMoverResult stores data-mover-specific information
+                  as a result of the DataUpload.
+                nullable: true
+                type: object
+              message:
+                description: Message is a message about the DataUpload's status.
+                type: string
+              node:
+                description: Node is name of the node where the DataUpload is processed.
+                type: string
+              path:
+                description: Path is the full path of the snapshot volume being backed
+                  up.
+                type: string
+              phase:
+                description: Phase is the current state of the DataUpload.
+                enum:
+                - New
+                - Accepted
+                - Prepared
+                - InProgress
+                - Canceling
+                - Canceled
+                - Completed
+                - Failed
+                type: string
+              progress:
+                description: Progress holds the total number of bytes of the volume
+                  and the current number of backed up bytes. This can be used to display
+                  progress information about the backup operation.
+                properties:
+                  bytesDone:
+                    format: int64
+                    type: integer
+                  totalBytes:
+                    format: int64
+                    type: integer
+                type: object
+              snapshotID:
+                description: SnapshotID is the identifier for the snapshot in the
+                  backup repository.
+                type: string
+              startTimestamp:
+                description: StartTimestamp records the time a backup was started.
+                  Separate from CreationTimestamp, since that value changes on restores.
+                  The server's time is used for StartTimestamps
+                format: date-time
+                nullable: true
+                type: string
+            type: object
+        type: object
+    served: true
+    storage: true
+    subresources: {}

config/crd/v2alpha1/crds/doc.go

@@ -0,0 +1,4 @@
+// Package crds embeds the controller-tools generated CRD manifests
+package crds
+
+//go:generate go run ../../../../hack/crd-gen/v1/main.go

config/rbac/role.yaml

@@ -1,9 +1,7 @@
-
 ---
 apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRole
 metadata:
-  creationTimestamp: null
   name: velero-perms
 rules:
 - apiGroups:
@@ -51,6 +49,19 @@ rules:
   verbs:
   - create
   - delete
+  - get
+  - list
+  - patch
+  - update
+  - watch
+- apiGroups:
+  - velero.io
+  resources:
+  - backups/status
+  verbs:
+  - get
+  - patch
+  - update
 - apiGroups:
   - velero.io
   resources:
@@ -71,6 +82,46 @@ rules:
   - get
   - patch
   - update
+- apiGroups:
+  - velero.io
+  resources:
+  - datadownloads
+  verbs:
+  - create
+  - delete
+  - get
+  - list
+  - patch
+  - update
+  - watch
+- apiGroups:
+  - velero.io
+  resources:
+  - datadownloads/status
+  verbs:
+  - get
+  - patch
+  - update
+- apiGroups:
+  - velero.io
+  resources:
+  - datauploads
+  verbs:
+  - create
+  - delete
+  - get
+  - list
+  - patch
+  - update
+  - watch
+- apiGroups:
+  - velero.io
+  resources:
+  - datauploads/status
+  verbs:
+  - get
+  - patch
+  - update
 - apiGroups:
   - velero.io
   resources:
@@ -151,6 +202,26 @@ rules:
   - get
   - patch
   - update
+- apiGroups:
+  - velero.io
+  resources:
+  - restores
+  verbs:
+  - create
+  - delete
+  - get
+  - list
+  - patch
+  - update
+  - watch
+- apiGroups:
+  - velero.io
+  resources:
+  - restores/status
+  verbs:
+  - get
+  - patch
+  - update
 - apiGroups:
   - velero.io
   resources:

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/CLI/PoC/base/deployment.yaml

@@ -57,7 +57,7 @@ spec:
         - emptyDir: {}
           name: scratch
 ---
-apiVersion: rbac.authorization.k8s.io/v1beta1
+apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRoleBinding
 metadata:
   labels:

design/CLI/PoC/overlays/plugins/node-agent.yaml

@@ -49,6 +49,9 @@ spec:
             - mountPath: /host_pods
               mountPropagation: HostToContainer
               name: host-pods
+            - mountPath: /var/lib/kubelet/plugins
+              mountPropagation: HostToContainer
+              name: host-plugins
             - mountPath: /scratch
               name: scratch
             - mountPath: /credentials
@@ -60,6 +63,9 @@ spec:
         - hostPath:
             path: /var/lib/kubelet/pods
           name: host-pods
+        - hostPath:
+            path: /var/lib/kubelet/plugins
+          name: host-plugins
         - emptyDir: {}
           name: scratch
         - name: cloud-credentials

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/biav2-design.md

@@ -0,0 +1,103 @@
+# Design for BackupItemAction v2 API
+
+## Abstract
+This design includes the changes to the BackupItemAction (BIA) api design as required by the [Item Action Progress Monitoring](general-progress-monitoring.md) feature.
+The BIA v2 interface will have two new methods, and the Execute() return signature will be modified.
+If there are any additional BIA API changes that are needed in the same Velero release cycle as this change, those can be added here as well.
+
+## Background
+This API change is needed to facilitate long-running plugin actions that may not be complete when the Execute() method returns.
+It is an optional feature, so plugins which don't need this feature can simply return an empty operation ID and the new methods can be no-ops.
+This will allow long-running plugin actions to continue in the background while Velero moves on to the next plugin, the next item, etc.
+
+## Goals
+- Allow for BIA Execute() to optionally initiate a long-running operation and report on operation status.
+
+## Non Goals
+- Allowing velero control over when the long-running operation begins.
+
+
+## High-Level Design
+As per the [Plugin Versioning](plugin-versioning.md) design, a new BIAv2 plugin `.proto` file will be created to define the GRPC interface.
+v2 go files will also be created in `plugin/clientmgmt/backupitemaction` and `plugin/framework/backupitemaction`, and a new PluginKind will be created.
+The velero Backup process will be modified to reference v2 plugins instead of v1 plugins.
+An adapter will be created so that any existing BIA v1 plugin can be executed as a v2 plugin when executing a backup.
+
+## Detailed Design
+
+### proto changes (compiled into golang by protoc)
+
+The v2 BackupItemAction.proto will be like the current v1 version with the following changes:
+ExecuteResponse gets a new field:
+```
+message ExecuteResponse {
+    bytes item = 1;
+    repeated generated.ResourceIdentifier additionalItems = 2;
+    string operationID = 3;
+    repeated generated.ResourceIdentifier itemsToUpdate = 4;
+}
+```
+The BackupItemAction service gets two new rpc methods:
+```
+service BackupItemAction {
+    rpc AppliesTo(BackupItemActionAppliesToRequest) returns (BackupItemActionAppliesToResponse);
+    rpc Execute(ExecuteRequest) returns (ExecuteResponse);
+    rpc Progress(BackupItemActionProgressRequest) returns (BackupItemActionProgressResponse);
+    rpc Cancel(BackupItemActionCancelRequest) returns (google.protobuf.Empty);
+}
+```
+To support these new rpc methods, we define new request/response message types:
+```
+message BackupItemActionProgressRequest {
+    string plugin = 1;
+    string operationID = 2;
+    bytes backup = 3;
+}
+
+message BackupItemActionProgressResponse {
+    generated.OperationProgress progress = 1;
+}
+
+message BackupItemActionCancelRequest {
+    string plugin = 1;
+    string operationID = 2;
+    bytes backup = 3;
+}
+
+```
+One new shared message type will be added, as this will also be needed for v2 RestoreItemAction and VolmeSnapshotter:
+```
+message OperationProgress {
+    bool completed = 1;
+    string err = 2;
+    int64 nCompleted = 3;
+    int64 nTotal = 4;
+    string operationUnits = 5;
+    string description = 6;
+    google.protobuf.Timestamp started = 7;
+    google.protobuf.Timestamp updated = 8;
+}
+```
+
+In addition to the two new rpc methods added to the BackupItemAction interface, there is also a new `Name()` method. This one is only actually used internally by Velero to get the name that the plugin was registered with, but it still must be defined in a plugin which implements BackupItemActionV2 in order to implement the interface. It doesn't really matter what it returns, though, as this particular method is not delegated to the plugin via RPC calls. The new (and modified) interface methods for `BackupItemAction` are as follows:
+```
+type BackupItemAction interface {
+...
+	Name() string
+...
+	Execute(item runtime.Unstructured, backup *api.Backup) (runtime.Unstructured, []velero.ResourceIdentifier, string, []velero.ResourceIdentifier, error)
+	Progress(operationID string, backup *api.Backup) (velero.OperationProgress, error)
+	Cancel(operationID string, backup *api.Backup) error
+...
+}
+```
+
+A new PluginKind, `BackupItemActionV2`, will be created, and the backup process will be modified to use this plugin kind.
+See [Plugin Versioning](plugin-versioning.md) for more details on implementation plans, including v1 adapters, etc.
+
+
+## Compatibility
+The included v1 adapter will allow any existing BackupItemAction plugin to work as expected, with an empty operation ID returned from Execute() and no-op Progress() and Cancel() methods.
+
+## Implementation
+This will be implemented during the Velero 1.11 development cycle.

design/Implemented/cluster-scope-resource-filter.md

@@ -0,0 +1,402 @@
+# Proposal to add resource filters for backup can distinguish whether resource is cluster-scoped or namespace-scoped.
+
+- [Proposal to add resource filters for backup can distinguish whether resource is cluster-scoped or namespace-scoped.](#proposal-to-add-resource-filters-for-backup-can-distinguish-whether-resource-is-cluster-scoped-or-namespace-scoped)
+	- [Abstract](#abstract)
+	- [Background](#background)
+	- [Goals](#goals)
+	- [Non Goals](#non-goals)
+	- [High-Level Design](#high-level-design)
+		- [Parameters Rules](#parameters-rules)
+		- [Using scenarios:](#using-scenarios)
+			- [no namespace-scoped resources + some cluster-scoped resources](#no-namespace-scoped-resources--some-cluster-scoped-resources)
+			- [no namespace-scoped resources + all cluster-scoped resources](#no-namespace-scoped-resources--all-cluster-scoped-resources)
+			- [some namespace-scoped resources + no cluster-scoped resources](#some-namespace-scoped-resources--no-cluster-scoped-resources)
+				- [scenario 1](#scenario-1)
+				- [scenario 2](#scenario-2)
+				- [scenario 3](#scenario-3)
+				- [scenario 4](#scenario-4)
+			- [some namespace-scoped resources + only related cluster-scoped resources](#some-namespace-scoped-resources--only-related-cluster-scoped-resources)
+				- [scenario 1](#scenario-1-1)
+				- [scenario 2](#scenario-2-1)
+				- [scenario 3](#scenario-3-1)
+			- [some namespace-scoped resources + some additional cluster-scoped resources](#some-namespace-scoped-resources--some-additional-cluster-scoped-resources)
+				- [scenario 1](#scenario-1-2)
+				- [scenario 2](#scenario-2-2)
+				- [scenario 3](#scenario-3-2)
+				- [scenario 4](#scenario-4-1)
+			- [some namespace-scoped resources + all cluster-scoped resources](#some-namespace-scoped-resources--all-cluster-scoped-resources)
+				- [scenario 1](#scenario-1-3)
+				- [scenario 2](#scenario-2-3)
+				- [scenario 3](#scenario-3-3)
+			- [all namespace-scoped resources + no cluster-scoped resources](#all-namespace-scoped-resources--no-cluster-scoped-resources)
+			- [all namespace-scoped resources + some additional cluster-scoped resources](#all-namespace-scoped-resources--some-additional-cluster-scoped-resources)
+			- [all namespace-scoped resources + all cluster-scoped resources](#all-namespace-scoped-resources--all-cluster-scoped-resources)
+			- [describe command change](#describe-command-change)
+	- [Detailed Design](#detailed-design)
+	- [Alternatives Considered](#alternatives-considered)
+	- [Security Considerations](#security-considerations)
+	- [Compatibility](#compatibility)
+	- [Implementation](#implementation)
+	- [Open Issues](#open-issues)
+
+## Abstract
+The current filter (IncludedResources/ExcludedResources + IncludeClusterResources flag) is not enough for some special cases, e.g. all namespace-scoped resources + some kind of cluster-scoped resource and all namespace-scoped resources + cluster-scoped resource excludes.
+Propose to add a new group of resource filtering parameters, which can distinguish cluster-scoped and namespace-scoped resources.
+
+## Background
+There are two sets of resource filters for Velero: `IncludedNamespaces/ExcludedNamespaces` and `IncludedResources/ExcludedResources`. 
+`IncludedResources` means only including the resource types specified in the parameter. Both cluster-scoped and namespace-scoped resources are handled in this parameter by now.
+The k8s resources are separated into cluster-scoped and namespace-scoped.
+As a result, it's hard to include all resources in one group and only including specified resource in the other group.
+
+## Goals
+- Make Velero can support more complicated namespace-scoped and cluster-scoped resources filtering scenarios in backup.
+
+## Non Goals
+- Enrich the resource filtering rules, for example, advanced PV filtering and filtering by resource names.
+
+
+## High-Level Design
+Four new parameters are added into command `velero backup create`: `--include-cluster-scoped-resources`, `--exclude-cluster-scoped-resources`, `--include-namespace-scoped-resources` and `--exclude-namespace-scoped-resources`. 
+`--include-cluster-scoped-resources` and `--exclude-cluster-scoped-resources` are used to filter cluster-scoped resources included or excluded in backup per resource type.
+`--include-namespace-scoped-resources` and `--exclude-namespace-scoped-resources` are used to filter namespace-scoped resources included or excluded in backup per resource type.
+Restore and other code pieces also use resource filtering will be handled in future releases.
+
+### Parameters Rules
+
+* `--include-cluster-scoped-resources`, `--include-namespace-scoped-resources`, `--exclude-cluster-scoped-resources` and `--exclude-namespace-scoped-resources` valid value include `*` and comma separated string. Each element of the CSV string should a k8s resource name. The format should be `resource.group`, such as `storageclasses.storage.k8s.io.`.
+
+* `--include-cluster-scoped-resources`, `--include-namespace-scoped-resources`, `--exclude-cluster-scoped-resources` and `--exclude-namespace-scoped-resources` parameters are mutual exclusive with `--include-cluster-resources`, `--include-resources` and `--exclude-resources` parameters. If both sets of parameters are provisioned, validation failure should be returned.
+
+* `--include-cluster-scoped-resources` and `--exclude-cluster-scoped-resources` should only contain cluster-scoped resource type names. If namespace-scoped resource type names are included, they are ignored.
+
+* If there are conflicts between `--include-cluster-scoped-resources` and `--exclude-cluster-scoped-resources` specified resources type lists, `--exclude-cluster-scoped-resources` parameter has higher priority.
+
+* `--include-namespace-scoped-resources` and `--exclude-namespace-scoped-resources` should only contain namespace-scoped resource type names. If cluster-scoped resource type names are included, they are ignored.
+
+* If there are conflicts between `--include-namespace-scoped-resources` and `--exclude-namespace-scoped-resources` specified resources type lists, `--exclude-namespace-scoped-resources` parameter has higher priority.
+
+* If  `--include-namespace-scoped-resources` is not present, it means all namespace-scoped resources are included per resource type.
+
+* If both `--include-cluster-scoped-resources` and `--exclude-cluster-scoped-resources` are not present, it means no additional cluster-scoped resource is included per resource type, just as the existing `--include-cluster-resources` parameter not setting value. Cluster-scoped resources are related to the namespace-scoped resources, which means those are returned in the namespace-scoped resources' BackupItemAction's result AdditionalItems array, are still included in backup by default. Taking backing up PVC scenario as an example, PVC is namespace-scoped, PV is cluster-scoped. PVC's BIA will include PVC related PV into backup too.
+
+### Using scenarios:
+Please notice, if the scenario give the example of using old filtering parameters (`--include-cluster-resources`, `--include-resources` and `--exclude-resources`), that means the old parameters also work for this case. If old parameters example is not given, that means they don't work for this scenario, only new parameters (`--include-cluster-scoped-resources`, `--include-namespace-scoped-resources`, `--exclude-cluster-scoped-resources` and `--exclude-namespace-scoped-resources`) work.
+
+#### no namespace-scoped resources + some cluster-scoped resources
+The following command means backup no namespace-scoped resources and some cluster-scoped resources.
+
+``` bash
+velero backup create <backup-name>
+	--exclude-namespace-scoped-resources=*
+	--include-cluster-scoped-resources=storageclass
+```
+
+#### no namespace-scoped resources + all cluster-scoped resources
+The following command means backup no namespace-scoped resources and all cluster-scoped resources.
+
+``` bash
+velero backup create <backup-name>
+	--exclude-namespace-scoped-resources=*
+	--include-cluster-scoped-resources=*
+```
+
+#### some namespace-scoped resources + no cluster-scoped resources
+##### scenario 1
+The following commands mean backup all resources in namespaces default and kube-system, and no cluster-scoped resources.
+
+Example of new parameters:
+``` bash
+velero backup create <backup-name>
+	--include-namespaces=default,kube-system
+	--exclude-cluster-scoped-resources=*
+```
+
+Example of old parameters:
+``` bash
+velero backup create <backup-name>
+	--include-namespaces=default,kube-system
+	--include-cluster-resources=false
+```
+##### scenario 2
+The following commands mean backup PVC, Deployment, Service, Endpoint, Pod and ReplicaSet resources in all namespaces, and no cluster-scoped resources. Although PVC's related PV should be included, due to no cluster-scoped resources are included, so they are ruled out too.
+
+Example of new parameters:
+``` bash
+velero backup create <backup-name>
+	--include-namespace-scoped-resources=persistentvolumeclaim,deployment,service,endpoint,pod,replicaset
+	--exclude-cluster-scope-resources=*
+```
+
+Example of old parameters:
+``` bash
+velero backup create <backup-name>
+	--include-resources=persistentvolumeclaim,deployment,service,endpoint,pod,replicaset
+	--include-cluster-resources=false
+```
+##### scenario 3
+The following commands mean backup PVC, Deployment, Service, Endpoint, Pod and ReplicaSet resources in namespace default and kube-system, and no cluster-scoped resources. Although PVC's related PV should be included, due to no cluster-scoped resources are included, so they are ruled out too.
+
+Example of new parameters:
+``` bash
+velero backup create <backup-name>
+	--include-namespaces=default,kube-system
+	--include-namespace-scoped-resources=persistentvolumeclaim,deployment,service,endpoint,pod,replicaset
+	--exclude-cluster-scope-resources=*
+```
+
+Example of old parameters:
+``` bash
+velero backup create <backup-name>
+	--include-namespaces=default,kube-system
+	--include-resources=persistentvolumeclaim,deployment,service,endpoint,pod,replicaset
+	--include-cluster-resources=false
+```
+##### scenario 4
+The following commands mean backup all resources except Ingress type resources in all namespaces, and no cluster-scoped resources.
+
+Example of new parameters:
+``` bash
+velero backup create <backup-name>
+	--exclude-namespace-scoped-resources=ingress
+	--exclude-cluster-scoped-resources=*
+```
+
+Example of old parameters:
+``` bash
+velero backup create <backup-name>
+	--exclude-resources=ingress
+	--include-cluster-resources=false
+```
+
+#### some namespace-scoped resources + only related cluster-scoped resources
+##### scenario 1
+This means backup all resources in namespaces default and kube-system, and related cluster-scoped resources.
+``` bash
+velero backup create <backup-name>
+	--include-namespaces=default,kube-system
+```
+
+##### scenario 2
+This means backup pods and configmaps in namespaces default and kube-system, and related cluster-scoped resources.
+``` bash
+velero backup create <backup-name>
+	--include-namespaces=default,kube-system
+	--include-namespace-scoped-resources=pods,configmaps
+```
+
+##### scenario 3
+This means backup all resources except Ingress type resources in all namespaces, and related cluster-scoped resources.
+
+Example of new parameters:
+``` bash
+velero backup create <backup-name>
+	--exclude-namespace-scoped-resources=ingress
+```
+
+Example of old parameters:
+``` bash
+velero backup create <backup-name>
+	--exclude-resources=ingress
+```
+
+#### some namespace-scoped resources + some additional cluster-scoped resources
+##### scenario 1
+This means backup all resources in namespace in default, kube-system, and related cluster-scoped resources, plus all StorageClass resources.
+``` bash
+velero backup create <backup-name>
+	--include-namespaces=default,kube-system
+	--include-cluster-scoped-resources=storageclass
+```
+
+##### scenario 2
+This means backup PVC, Deployment, Service, Endpoint, Pod and ReplicaSet resources in all namespaces, and related cluster-scoped resources, plus all StorageClass resources, and PVC related PV.
+``` bash
+velero backup create <backup-name>
+	--include-namespace-scoped-resources=persistentvolumeclaim,deployment,service,endpoint,pod,replicaset
+	--include-cluster-scoped-resources=storageclass
+```
+
+##### scenario 3
+This means backup PVC, Deployment, Service, Endpoint, Pod and ReplicaSet resources in default and kube-system namespaces, and related cluster-scoped resources, plus all StorageClass resources, and PVC related PV.
+``` bash
+velero backup create <backup-name>
+	--include-namespace-scoped-resources=persistentvolumeclaim,deployment,service,endpoint,pod,replicaset
+	--include-namespaces=default,kube-system
+	--include-cluster-scoped-resources=storageclass
+```
+
+##### scenario 4
+This means backup PVC, Deployment, Service, Endpoint, Pod and ReplicaSet resources in default and kube-system namespaces, and related cluster-scoped resources, plus all cluster-scoped resources except StorageClass type resources.
+``` bash
+velero backup create <backup-name>
+	--include-namespace-scoped-resources=persistentvolumeclaim,deployment,service,endpoint,pod,replicaset
+	--include-namespaces=default,kube-system
+	--exclude-cluster-scoped-resources=storageclass
+```
+
+#### some namespace-scoped resources + all cluster-scoped resources
+##### scenario 1
+The following commands mean backup all resources in namespace in default, kube-system, and all cluster-scoped resources.
+
+Example of new parameters:
+``` bash
+velero backup create <backup-name>
+	--include-namespaces=default,kube-system
+	--include-cluster-scoped-resources=*
+```
+
+Example of old parameters:
+``` bash
+velero backup create <backup-name>
+	--include-namespaces=default,kube-system
+	--include-cluster-resources=true
+```
+
+##### scenario 2
+This means backup Deployment, Service, Endpoint, Pod and ReplicaSet resources in all namespaces, and all cluster-scoped resources.
+``` bash
+velero backup create <backup-name>
+	--include-namespace-scoped-resources=deployment,service,endpoint,pod,replicaset
+	--include-cluster-scoped-resources=*
+```
+
+##### scenario 3
+This means backup Deployment, Service, Endpoint, Pod and ReplicaSet resources in default and kube-system namespaces, and all cluster-scoped resources.
+``` bash
+velero backup create <backup-name>
+	--include-namespaces=default,kube-system
+	--include-namespace-scoped-resources=deployment,service,endpoint,pod,replicaset
+	--include-cluster-scoped-resources=*
+```
+
+#### all namespace-scoped resources + no cluster-scoped resources
+The following commands all mean backup all namespace-scoped resources and no cluster-scoped resources.
+
+Example of new parameters:
+``` bash
+velero backup create <backup-name>
+	--exclude-cluster-scoped-resources=*
+```
+
+Example of old parameters:
+``` bash
+velero backup create <backup-name>
+	--include-cluster-resources=false
+```
+
+#### all namespace-scoped resources + some additional cluster-scoped resources
+This command means backup all namespace-scoped resources, and related cluster-scoped resources, plus all PersistentVolume resources.
+``` bash
+velero backup create <backup-name>
+	--include-namespaces=*
+	--include-cluster-scoped-resources=persistentvolume
+```
+
+#### all namespace-scoped resources + all cluster-scoped resources
+The following commands have the same meaning: backup all namespace-scoped resources, and all cluster-scoped resources.
+``` bash
+velero backup create <backup-name>
+	--include-cluster-scoped-resources=*
+```
+
+``` bash
+velero backup create <backup-name>
+	--include-cluster-resources=true
+```
+
+#### describe command change
+In `velero backup describe` command, the four new parameters should be outputted too.
+``` bash
+ velero backup describe <backup-name>
+......
+
+Namespaces:
+  Included:  ns2
+  Excluded:  <none>
+
+Resources:
+  Included cluster-scoped:    StorageClass,PersistentVolume
+  Excluded cluster-scoped:    <none>
+  Included namespace-scoped:  default
+  Excluded namespace-scoped:  <none>
+......
+```
+
+**Note:** `velero restore` command doesn't support those four new parameter in Velero v1.11, but `velero schedule` supports the four new parameters through backup specification.
+
+## Detailed Design
+With adding `IncludedNamespaceScopedResources`, `ExcludedNamespaceScopedResources`, `IncludedClusterScopedResources` and `ExcludedClusterScopedResources`, the `BackupSpec` looks like:
+``` go
+type BackupSpec struct {
+    ......
+	// IncludedResources is a slice of resource names to include
+	// in the backup. If empty, all resources are included.
+	// +optional
+	// +nullable
+	IncludedResources []string `json:"includedResources,omitempty"`
+
+	// ExcludedResources is a slice of resource names that are not
+	// included in the backup.
+	// +optional
+	// +nullable
+	ExcludedResources []string `json:"excludedResources,omitempty"`
+
+	// IncludeClusterResources specifies whether cluster-scoped resources
+	// should be included for consideration in the backup.
+	// +optional
+	// +nullable
+	IncludeClusterResources *bool `json:"includeClusterResources,omitempty"`
+
+	// IncludedClusterScopedResources is a slice of cluster-scoped
+	// resource type names to include in the backup.
+	// If set to "*", all cluster scope resource types are included.
+	// The default value is empty, which means only related cluster 
+	// scope resources are included.
+	// +optional
+	// +nullable
+	IncludedClusterScopedResources []string `json:"includedClusterScopedResources,omitempty"`
+
+	// ExcludedClusterScopedResources is a slice of cluster-scoped 
+	// resource type names to exclude from the backup.
+	// If set to "*", all cluster scope resource types are excluded.
+	// +optional
+	// +nullable
+	ExcludedClusterScopedResources []string `json:"excludedClusterScopedResources,omitempty"`
+
+	// IncludedNamespaceScopedResources is a slice of namespace-scoped
+	// resource type names to include in the backup.
+	// The default value is "*".
+	// +optional
+	// +nullable
+	IncludedNamespaceScopedResources []string `json:"includedNamespaceScopedResources,omitempty"`
+
+	// ExcludedNamespaceScopedResources is a slice of namespace-scoped
+	// resource type names to exclude from the backup.
+	// If set to "*", all namespace scope resource types are excluded.
+	// +optional
+	// +nullable
+	ExcludedNamespaceScopedResources []string `json:"excludedNamespaceScopedResources,omitempty"`
+    ......
+}
+```
+
+## Alternatives Considered
+Proposal from Jibu Data [Issue 5120](https://github.com/vmware-tanzu/velero/issues/5120#issue-1304534563)
+
+## Security Considerations
+No security impact.
+
+## Compatibility
+The four new parameters cannot be mixed with existing resource filter parameters: `IncludedResources`, `ExcludedResources` and `IncludeClusterResources`.
+If the new parameters and old parameters both appears in command line, or are specified in backup spec, the command line and the backup should fail.
+
+## Implementation
+This change should be included into Velero v1.11.
+New parameters will coexist with `IncludedResources`, `ExcludedResources` and `IncludeClusterResources`.
+Plan to deprecate `IncludedResources`, `ExcludedResources` and `IncludeClusterResources` in future releases, but also open to the community's feedback.
+
+## Open Issues
+`LabelSelector/OrLabelSelectors` apply to namespace-scoped resources.
+It may be reasonable to make them also working on cluster-scoped resources.
+An issue is created to trace this topic [resource label selector not work for cluster-scoped resources](https://github.com/vmware-tanzu/velero/issues/5787)

design/Implemented/csi-snapshots.md

@@ -304,8 +304,8 @@ Without these objects, the provider-level snapshots cannot be located in order t
 
 
 [1]: https://kubernetes.io/blog/2018/10/09/introducing-volume-snapshot-alpha-for-kubernetes/
-[2]: https://github.com/kubernetes-csi/external-snapshotter/blob/master/pkg/apis/volumesnapshot/v1alpha1/types.go#L41
-[3]: https://github.com/kubernetes-csi/external-snapshotter/blob/master/pkg/apis/volumesnapshot/v1alpha1/types.go#L161
+[2]: https://github.com/kubernetes-csi/external-snapshotter/blob/master/client/apis/volumesnapshot/v1/types.go#L42
+[3]: https://github.com/kubernetes-csi/external-snapshotter/blob/master/client/apis/volumesnapshot/v1/types.go#L262
 [4]: https://github.com/heptio/velero/blob/main/pkg/volume/snapshot.go#L21
 [5]: https://github.com/heptio/velero/blob/main/pkg/apis/velero/v1/pod_volume_backup.go#L88
 [6]: https://github.com/heptio/velero-csi-plugin/

design/Implemented/delete-item-action.md

@@ -175,7 +175,7 @@ If there are one or more, download the backup tarball from backup storage, untar
 
 ## Alternatives Considered
 
-Another proposal for higher level `DeleteItemActions` was initially included, which would require implementors to individually download the backup tarball themselves.
+Another proposal for higher level `DeleteItemActions` was initially included, which would require implementers to individually download the backup tarball themselves.
 While this may be useful long term, it is not a good fit for the current goals as each plugin would be re-implementing a lot of boilerplate.
 See the deletion-plugins.md file for this alternative proposal in more detail.
 

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

@@ -0,0 +1,579 @@
+# Plugin Progress Monitoring
+
+This is intended as a replacement for the previously-approved Upload Progress Monitoring design
+([Upload Progress Monitoring](upload-progress.md)) in order to expand the supported use cases beyond
+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 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 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
+about the ultimate destination of backup data independent of the storage system they're using.
+
+We would also like any internal or third party Backup or Restore Item Action to have the option of
+making use of this same ability to run some external process without blocking the current backup or
+restore operation. Beyond Volume Snapshotters, this is also needed for data mover operations on both
+backup and restore, and potentially useful for other third party operations -- for example
+in-cluster registry image backup or restore could make use of this feature in a third party plugin).
+
+### Glossary
+- <b>BIA</b>: BackupItemAction
+- <b>RIA</b>: RestoreItemAction
+
+## Examples
+- AWS - AWS snapshots return quickly, but are then uploaded in the background and cannot be used until EBS moves
+the data into S3 internally.
+
+- vSphere - The vSphere plugin takes a local snapshot and then the vSphere plugin uploads the data to S3.  The local
+snapshot is usable before the upload completes.
+
+- Restic - Does not go through the volume snapshot path.  Restic backups will block Velero progress
+until completed. However, with the more generalized approach in the revised design, restic/kopia
+backup and restore *could* make use of this framework if their actions are refactored as
+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.
+    - Workflow
+        - User takes velero backup of PVC A
+        - BIA plugin applies to PVCs with compatible storage driver
+        - BIA plugin triggers data mover
+	  - Most common use case would be for the plugin action to create a new CR which would
+            trigger an external controller action
+	  - Another possible use case would be for the plugin to run its own async action in a
+            goroutine, although this would be less resilient to plugin container restarts.
+        - BIA plugin returns
+        - Velero backup process continues
+        - Main velero backup process monitors running BIA threads via gRPC to determine if process is done and healthy
+
+
+## Primary changes from the original Upload Progress Monitoring design
+
+The most fundamental change here is that rather than proposing a new special-purpose
+SnapshotItemAction, the existing BackupItemAction plugin will be modified to accommodate an optional
+snapshot (or other item operation) ID return. The primary reasons for this change are as follows:
+
+1. The intended scope has moved beyond snapshot processing, so it makes sense to support
+asynchronous operations in other backup or restore item actions.
+
+2. We expect to have plugin API versioning implemented in Velero 1.10, making it feasible to
+implement changes in the existing plugin APIs now.
+
+3. We will need this feature on both backup and restore, meaning that if we took the "new plugin
+type" approach, we'd need two new plugin types.
+
+4. Other than the snapshot/operation ID return, the rest of the plugin processing is identical to
+Backup/RestoreItemActions. With separate plugin types, we'd have to repeat all of that logic
+(including dealing with additional items, etc.) twice.
+
+The other major change is that we will be applying this to both backups and restores, although the
+Volume Snapshotter use case only needs this on backup. This means that everything we're doing around
+backup phase and workflow will also need to be done for restore.
+
+Then there are various minor changes around terminology to make things more generic. Instead of
+"snapshotID", we'll have "operationID" (which for volume snapshotters will be a snapshot
+ID).
+
+## Goals
+
+- Enable monitoring of backup/restore item action operations that continue after snapshotting and other operations have completed
+- Keep non-usable backups and restores (upload/persistence has not finished, etc.) from appearing as completed
+- Make use of plugin API versioning functionality to manage changes to Backup/RestoreItemAction interfaces
+- Enable vendors to plug their own data movers into velero using BIA/RIA plugins
+
+## Non-goals
+- Today, Velero is unable to recover from an in progress backup when the velero server crashes (pod is deleted). This has an impact on running asynchronous processes, but it’s not something we intend to solve in this design.
+
+## Models
+
+### Internal configuration and management
+In this model, movement of the snapshot to stable storage is under the control of the snapshot
+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
+In this model, the snapshot is moved to external storage under the control of Velero.  This
+enables Velero to move data between storage systems.  This also allows backup partners to use
+Velero to snapshot data and then move the data into their backup repository.
+
+## Backup and Restore phases
+
+Velero currently has backup/restore phases "InProgress" and "Completed".  A backup moves to the
+Completed phase when all of the volume snapshots have completed and the Kubernetes metadata has been
+written into the object store.  However, the actual data movement may be happening in the background
+after the backup has been marked "Completed".  The backup is not actually a stable backup until the
+data has been persisted properly.  In some cases (e.g. AWS) the backup cannot be restored from until
+the snapshots have been persisted.
+
+Once the snapshots have been taken, however, it is possible for additional backups or restores (as
+long as they don't use not-yet-completed backups) to be made without interference.  Waiting until
+all data has been moved before starting the next backup will slow the progress of the system without
+adding any actual benefit to the user.
+
+New backup/restore phases, "WaitingForPluginOperations" and
+"WaitingForPluginOperationsPartiallyFailed" will be introduced.  When a backup or restore has
+entered one of these phases, Velero is free to start another backup/restore.  The backup/restore
+will remain in the "WaitingForPluginOperations" phase until all BIA/RIA operations have completed
+(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 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"
+and "FinalizingPartiallyFailed", which will handle any steps required after plugin operations have
+all completed. Initially, this will just include adding any required resources to the backup that
+might have changed during asynchronous operation execution, although eventually other cleanup
+actions could be added to this phase.
+
+### State progression
+
+![image](AsyncActionFSM.png)
+### New
+When a backup/restore request is initially created, it is in the "New" phase.  
+
+The next state is either "InProgress" or "FailedValidation"
+
+### FailedValidation
+If the backup/restore request is incorrectly formed, it goes to the "FailedValidation" phase and
+terminates
+
+### InProgress
+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
+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
+allow for data movement to be handled in the "WaitingForPluginOperations" phase,
+
+The next phase would be "WaitingForPluginOperations" for backups or restores which have unfinished
+asynchronous plugin operations and no errors so far, "WaitingForPluginOperationsPartiallyFailed" for
+backups or restores which have unfinished asynchronous plugin operations at least one error,
+"Completed" for restores with no unfinished asynchronous plugin operations and no errors,
+"PartiallyFailed" for restores with no unfinished asynchronous plugin operations and at least one
+error, "Finalizing" for backups with no unfinished asynchronous plugin operations and no errors,
+"FinalizingPartiallyFailed" for backups with no unfinished asynchronous plugin operations and at
+least one error, or "PartiallyFailed".  Backups/restores which would have a final phase of
+"Completed" or "PartiallyFailed" may move to the "WaitingForPluginOperations" or
+"WaitingForPluginOperationsPartiallyFailed" state.  A backup/restore which will be marked "Failed"
+will go directly to the "Failed" phase.  Uploads may continue in the background for snapshots that
+were taken by a "Failed" backup/restore, but no progress will not be monitored or updated. If there
+are any operations in progress when a backup is moved to the "Failed" phase (although with the
+current workflow, that shouldn't happen), Cancel() should be called on these operations. When a
+"Failed" backup is deleted, all snapshots will be deleted and at that point any uploads still in
+progress should be aborted.
+
+### WaitingForPluginOperations (new)
+The "WaitingForPluginOperations" phase signifies that the main part of the backup/restore, including
+snapshotting has completed successfully and uploading and any other asynchronous BIA/RIA plugin
+operations are continuing.  In the event of an error during this phase, the phase will change to
+WaitingForPluginOperationsPartiallyFailed.  On success, the phase changes to
+"Finalizing" for backups and "Completed" for restores.  Backups cannot be
+restored from when they are in the WaitingForPluginOperations state.
+
+### WaitingForPluginOperationsPartiallyFailed (new)
+The "WaitingForPluginOperationsPartiallyFailed" phase signifies that the main part of the
+backup/restore, including snapshotting has completed, but there were partial failures either during
+the main part or during any async operations, including snapshot uploads.  Backups cannot be
+restored from when they are in the WaitingForPluginOperationsPartiallyFailed state.
+
+### Finalizing (new)
+The "Finalizing" phase signifies that asynchronous backup operations have all completed successfully
+and Velero is currently backing up any resources indicated by asynchronous plugins as items to back
+up after operations complete. Once this is done, the phase changes to Completed.  Backups cannot be
+restored from when they are in the Finalizing state.
+
+### FinalizingPartiallyFailed (new)
+
+The "FinalizingPartiallyFailed" phase signifies that, for a backup which had errors during initial
+processing or asynchronous plugin operation, asynchronous backup operations have all completed and
+Velero is currently backing up any resources indicated by asynchronous plugins as items to back up
+after operations complete. Once this is done, the phase changes to PartiallyFailed.  Backups cannot
+be restored from when they are in the FinalizingPartiallyFailed state.
+
+### Failed
+When a backup/restore has had fatal errors it is marked as "Failed" Backups in this state cannot be
+restored from.
+
+### Completed
+The "Completed" phase signifies that the backup/restore has completed, all data has been transferred
+to stable storage (or restored to the cluster) and any backup in this state is ready to be used in a
+restore.  When the Completed phase has been reached for a backup it is safe to remove any of the
+items that were backed up.
+
+### PartiallyFailed
+The "PartiallyFailed" phase signifies that the backup/restore has completed and at least part of the
+backup/restore is usable.  Restoration from a PartiallyFailed backup will not result in a complete
+restoration but pieces may be available.
+
+## Workflow
+
+When a Backup or Restore Action is executed, any BackupItemAction, RestoreItemAction, or
+VolumeSnapshot plugins will return operation IDs (snapshot IDs or other plugin-specific
+identifiers).  The plugin should be able to provide status on the progress for the snapshot and
+handle cancellation of the operation/upload if the snapshot is deleted.  If the plugin is restarted,
+the operation ID should remain valid.
+
+When all snapshots have been taken and Kubernetes resources have been persisted to the ObjectStorePlugin
+the backup will either have fatal errors or will be at least partially usable.
+
+If the backup/restore has fatal errors it will move to the "Failed" state and finish. If a
+backup/restore fails, the upload or other operation will not be cancelled but it will not be
+monitored either.  For backups in any phase, all snapshots will be deleted when the backup is
+deleted.  Plugins will cancel any data movement or other operations and remove snapshots and other
+associated resources when the VolumeSnapshotter DeleteSnapshot method or DeleteItemAction Execute
+method is called.
+
+Velero will poll the plugins for status on the operations when the backup/restore exits the
+"InProgress" phase and has no fatal errors.
+
+If any operations are not complete, the backup/restore will move to either WaitingForPluginOperations
+or WaitingForPluginOperationsPartiallyFailed or Failed.
+
+Post-snapshot and other operations may take a long time and Velero and its plugins may be restarted
+during this time.  Once a backup/restore has moved into the WaitingForPluginOperations or
+WaitingForPluginOperationsPartiallyFailed phase, another backup/restore may be started.
+
+While in the WaitingForPluginOperations or WaitingForPluginOperationsPartiallyFailed phase, the
+snapshots and item actions will be periodically polled.  When all of the snapshots and item actions
+have reported success, restores will move directly to the Completed or PartiallyFailed phase, and
+backups will move to the Finalizing or FinalizingPartiallyFailed phase, depending on whether the
+backup/restore was in the WaitingForPluginOperations or WaitingForPluginOperationsPartiallyFailed
+phase.
+
+While in the Finalizing or FinalizingPartiallyFailed phase, Velero will update the backup with any
+resources indicated by plugins that they must be added to the backup after operations are completed,
+and then the backup will move to the Completed or PartiallyFailed phase, depending on whether there
+are any backup errors.
+
+The Backup resources will be written to object storage at the time the backup leaves the InProgress
+phase, but it will not be synced to other clusters (or usable for restores in the current cluster)
+until the backup has entered a final phase: Completed, Failed or PartiallyFailed. During the
+Finalizing phases, a the backup resources will be updated with any required resources related to
+asynchronous plugins.
+
+## Reconciliation of InProgress backups
+
+InProgress backups will not have a `velero-backup.json` present in the object store.  During
+reconciliation, backups which do not have a `velero-backup.json` object in the object store will be
+ignored.
+
+## Plugin API changes
+
+### OperationProgress struct
+
+    type OperationProgress struct {
+        Completed bool                          // True when the operation has completed, either successfully or with a failure
+        Err string                              // Set when the operation has failed
+        NCompleted, NTotal int64                // Quantity completed so far and the total quantity associated with the operation in operationUnits
+                                                // For data mover and volume snapshotter use cases, this would be in bytes
+                                                // On successful completion, completed and total should be the same.
+        OperationUnits string                   // Units represented by completed and total -- for data mover and item
+	                                        // snapshotters, this will usually be bytes.
+        Description string                      // Optional description of operation progress
+        Started, Updated time.Time              // When the upload was started and when the last update was seen.  Not all
+                                                // systems retain when the upload was begun, return Time 0 (time.Unix(0, 0))
+                                                // if unknown.
+    }
+
+### VolumeSnapshotter changes
+
+Two new methods will be added to the VolumeSnapshotter interface:
+
+    Progress(snapshotID string) (OperationProgress, error)
+    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 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 plugin changes
+
+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
+operationID in addition to the modified item.
+
+Velero can attempt to cancel an operation by calling the Cancel API call on the BIA/RIA. The plugin
+can then take any appropriate action as needed. Cancel will be called for unfinished operations on
+backup deletion, and possibly reaching timeout. Cancel is not intended to be used to delete/remove
+the results of completed actions and will have no effect on a completed action. Cancel has no return
+value apart from the standard Error return, but this should only be used for unexpected
+failures. Under normal operations, Cancel will simply return a nil error (and nothing else), whether
+or not the plugin is able to cancel the operation.
+
+_AsyncOperationsNotSupportedError_ should only be returned (by Progress) if the
+Backup/RestoreItemAction plugin should not be handling the item.  If the Backup/RestoreItemAction
+plugin should handle the item but, for example, the item/snapshot ID cannot be found to report
+progress, Progress will return an InvalidOperationIDError error rather than a populated
+OperationProgress struct. If the item action does not start an asynchronous operation, then
+operationID will be empty.
+
+Three new methods will be added to the BackupItemAction interface, and the Execute() return signature
+will be modified:
+
+	// Name returns the name of this BIA. Plugins which implement this interface must defined Name,
+	// but its content is unimportant, as it won't actually be called via RPC. Velero's plugin infrastructure
+	// will implement this directly rather than delegating to the RPC plugin in order to return the name
+	// that the plugin was registered under. The plugins must implement the method to complete the interface.
+	Name() string
+	// Execute allows the BackupItemAction to perform arbitrary logic with the item being backed up,
+	// including mutating the item itself prior to backup. The item (unmodified or modified)
+	// should be returned, along with an optional slice of ResourceIdentifiers specifying
+	// additional related items that should be backed up now, an optional operationID for actions which
+	// 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
+	// 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)
+    	
+    	// Progress  
+	Progress(operationID string, backup *api.Backup) (velero.OperationProgress, error)
+    	// Cancel  
+	Cancel(operationID string, backup *api.Backup) error
+
+Three new methods will be added to the RestoreItemAction interface, and the
+RestoreItemActionExecuteOutput struct will be modified:
+
+	// Name returns the name of this RIA. Plugins which implement this interface must defined Name,
+	// but its content is unimportant, as it won't actually be called via RPC. Velero's plugin infrastructure
+	// will implement this directly rather than delegating to the RPC plugin in order to return the name
+	// that the plugin was registered under. The plugins must implement the method to complete the interface.
+	Name() string
+	// Execute allows the ItemAction to perform arbitrary logic with the item being restored,
+	// including mutating the item itself prior to restore. The item (unmodified or modified)
+	// should be returned, an optional OperationID, along with an optional slice of ResourceIdentifiers
+	// specifying additional related items that should be restored, a warning (which will be
+	// logged but will not prevent the item from being restored) or error (which will be logged
+	// and will prevent the item from being restored) if applicable. If OperationID is specified
+    	// then velero will wait for this operation to complete before the restore is marked Completed.
+	Execute(input *RestoreItemActionExecuteInput) (*RestoreItemActionExecuteOutput, error)
+
+    	
+    	// Progress  
+	Progress(operationID string, restore *api.Restore) (velero.OperationProgress, error)
+
+        // Cancel  
+	Cancel(operationID string, restore *api.Restore) error
+    
+    // RestoreItemActionExecuteOutput contains the output variables for the ItemAction's Execution function.
+    type RestoreItemActionExecuteOutput struct {
+        // UpdatedItem is the item being restored mutated by ItemAction.
+        UpdatedItem runtime.Unstructured
+
+        // AdditionalItems is a list of additional related items that should
+        // be restored.
+        AdditionalItems []ResourceIdentifier
+
+        // SkipRestore tells velero to stop executing further actions
+        // on this item, and skip the restore step. When this field's
+        // value is true, AdditionalItems will be ignored.
+        SkipRestore bool
+
+        // OperationID is an identifier which indicates an ongoing asynchronous action which Velero will
+        // continue to monitor after restoring this item. If left blank, then there is no ongoing operation
+        OperationID string
+    }
+
+## Changes in Velero backup format
+
+No changes to the existing format are introduced by this change.  As part of the backup workflow changes, a
+`<backup-name>-itemoperations.json.gz` file will be added that contains the items and operation IDs
+(snapshotIDs) returned by VolumeSnapshotter and BackupItemAction plugins.  Also, the creation of the
+`velero-backup.json` object will not occur until the backup moves to one of the terminal phases
+(_Completed_, _PartiallyFailed_, or _Failed_).  Reconciliation should ignore backups that do not
+have a `velero-backup.json` object.
+
+The Backup/RestoreItemAction plugin identifier as well as the ItemID and OperationID will be stored
+in the `<backup-name>-itemoperations.json.gz`.  When checking for progress, this info will be used
+to select the appropriate Backup/RestoreItemAction plugin to query for progress. Here's an example
+of what a record for a datamover plugin might look like:
+```
+    {
+        "spec": {
+            "backupName": "backup-1",
+            "backupUID": "f8c72709-0f73-46e1-a071-116bc4a76b07",
+            "backupItemAction": "velero.io/volumesnapshotcontent-backup",
+            "resourceIdentifier": {
+	        "Group": "snapshot.storage.k8s.io",
+                "Resource": "VolumeSnapshotContent",
+                "Namespace": "my-app",
+                "Name": "my-volume-vsc"
+            },
+            "operationID": "<DataMoverBackup objectReference>",
+            "itemsToUpdate": [
+	      {
+	        "Group": "velero.io",
+                "Resource": "VolumeSnapshotBackup",
+                "Namespace": "my-app",
+                "Name": "vsb-1"
+              }
+	    ]
+	},
+        "status": {
+            "operationPhase": "Completed",
+            "error": "",
+            "nCompleted": 12345,
+            "nTotal": 12345,
+            "operationUnits": "byte",
+            "description": "",
+            "Created": "2022-12-14T12:00:00Z",
+            "Started": "2022-12-14T12:01:00Z",
+            "Updated": "2022-12-14T12:11:02Z"
+        },
+    }
+```
+
+The cluster that is creating the backup will have the Backup resource present and will be able to
+manage the backup before the backup completes.
+
+If the Backup resource is removed (e.g. Velero is uninstalled) before a backup completes and writes
+its `velero-backup.json` object, the other objects in the object store for the backup will be
+effectively orphaned.  This can currently happen but the current window is much smaller.
+
+### `<backup-name>-itemoperations.json.gz`
+The itemoperations file is similar to the existing `<backup-name>-itemsnapshots.json.gz`  Each snapshot taken via
+BackupItemAction will have a JSON record in the file.  Exact format TBD.
+
+This file will be uploaded to object storage at the end of processing all of the items in the
+backup, before the phase moves away from `InProgress`.
+
+## Changes to Velero restores
+
+A `<restore-name>-itemoperations.json.gz` file will be added that contains the items and operation
+IDs returned by RestoreItemActions. The format will be the same as the
+`<backup-name>-itemoperations.json.gz` generated for backups.
+
+This file will be uploaded to object storage at the end of processing all of the items in the
+restore, before the phase moves away from `InProgress`.
+
+## CSI snapshots
+
+For systems such as EBS, a snapshot is not available until the storage system has transferred the
+snapshot to stable storage.  CSI snapshots expose the _readyToUse_ state that, in the case of EBS,
+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 plugin
+
+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
+
+The backup workflow remains the same until we get to the point where the `velero-backup.json` object
+is written.  At this point, Velero will
+run across all of the VolumeSnapshotter/BackupItemAction operations and call the _Progress_ method
+on each of them.
+
+If all backup item operations have finished (either successfully or failed), the backup will move to
+one of the finalize phases.
+
+If any of the snapshots or backup items are still being processed, the phase of the backup will be
+set to the appropriate phase (_WaitingForPluginOperations_ or
+_WaitingForPluginOperationsPartiallyFailed_), and the async backup operations controller will
+reconcile periodically and call Progress on any unfinished operations. In the event of any of the
+progress checks return an error, the phase will move to _WaitingForPluginOperationsPartiallyFailed_.
+
+Once all operations have completed, the backup will be moved to one of the finalize phases, and the
+backup finalizer controller will update the the `velero-backup.json`in the object store with any
+resources necessary after asynchronous operations are complete and the backup will move to the
+appropriate terminal phase.
+
+
+## Restore workflow changes
+
+The restore workflow remains the same until velero would currently move the backup into one of the
+terminal states. At this point, Velero will run across all of the RestoreItemAction operations and
+call the _Progress_ method on each of them.
+
+If all restore item operations have finished (either successfully or failed), the restore will be
+completed and the restore will move to the appropriate terminal phase and the restore will be
+complete.
+
+If any of the restore items are still being processed, the phase of the restore will be set to the
+appropriate phase (_WaitingForPluginOperations_ or _WaitingForPluginOperationsPartiallyFailed_), and
+the async restore operations controller will reconcile periodically and call Progress on any
+unfinished operations. In the event of any of the progress checks return an error, the phase will
+move to _WaitingForPluginOperationsPartiallyFailed_. Once all of the operations have completed, the
+restore will be moved to the appropriate terminal phase.
+
+## Restart workflow
+
+On restart, the Velero server will scan all Backup/Restore resources.  Any Backup/Restore resources
+which are in the _InProgress_ phase will be moved to the _Failed_ phase.  Any Backup/Restore
+resources in the _WaitingForPluginOperations_ or _WaitingForPluginOperationsPartiallyFailed_ phase
+will be treated as if they have been requeued and progress checked and the backup/restore will be
+requeued or moved to a terminal phase as appropriate.
+
+## Notes on already-merged code which may need updating
+
+Since this design is modifying a previously-approved design, there is some preparation work based on
+the earlier upload progress monitoring design that may need modification as a result of these
+updates. Here is a list of some of these items:
+
+1. Consts for the "Uploading" and "UploadingPartiallyFailed" phases have already been defined. These
+   will need to be removed when the "WaitingForPluginOperations" and
+   "WaitingForPluginOperationsPartiallyFailed" phases are defined.
+   - https://github.com/vmware-tanzu/velero/pull/3805
+1. Remove the ItemSnapshotter plugin APIs (and related code) since the revised design will reuse
+   VolumeSnapshotter and BackupItemAction plugins.
+   - https://github.com/vmware-tanzu/velero/pull/4077
+   - https://github.com/vmware-tanzu/velero/pull/4417
+1. UploadProgressFeatureFlag shouldn't be needed anymore. The current design won't really need a
+   feature flag here -- the new features will be added to V2 of the VolumeSnapshotter,
+   BackupItemAction, and RestoreItemAction plugins, and it will only be used if there are plugins which
+   return operation IDs.
+   - https://github.com/vmware-tanzu/velero/pull/4416
+1. Adds <backup-name>-itemsnapshots.gz file to backup (when provided) -- this is still part of the
+   revised design, so it should stay.
+   - https://github.com/vmware-tanzu/velero/pull/4429
+1. Upload Progress Monitoring and Item Snapshotter basic support: This PR is not yet merged, so
+   nothing will need to be reverted. While the implementation here will be useful in informing the
+   implementation of the new design, several things have changed in the design proposal since the PR
+   was written.
+   - https://github.com/vmware-tanzu/velero/pull/4467
+
+# Implementation tasks
+
+VolumeSnapshotter new plugin APIs  
+BackupItemAction new plugin APIs  
+RestoreItemAction new plugin APIs  
+New backup phases  
+New restore phases  
+Defer uploading `velero-backup.json`  
+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 plugin BackupItemAction Progress implementation  
+vSphere plugin BackupItemAction Progress implementation (vSphere plugin team)  
+
+
+# Open Questions
+
+1. Do we need a Cancel operation for VolumeSnapshotter?
+   - From feedback, I'm thinking we probably don't need it. The only real purpose of Cancel
+     here is to tell the plugin that Velero won't be waiting anymore, so if there are any
+     required custom cancellation actions, now would be a good time to perform them. For snapshot
+     uploads that are already in proress, there's not really anything else to cancel.
+2. Should we actually write the backup *before* moving to the WaitingForPluginOperations or
+   WaitingForPluginOperationsPartiallyFailed phase rather than waiting until all operations
+   have completed? The operations in question won't affect what gets written to object storage
+   for the backup, and since we've already written the list of operations we're waiting for to
+   object storage, writing the backup now would make the process resilient to Velero restart if
+   it happens during WaitingForPluginOperations or WaitingForPluginOperationsPartiallyFailed
+

design/Implemented/handle-backup-of-volumes-by-resources-filters.md

@@ -0,0 +1,324 @@
+# Handle backup of volumes by resources filters
+ 
+## Abstract
+Currently, Velero doesn't have one flexible way to handle volumes.
+ 
+If users want to skip the backup of volumes or only backup some volumes in different namespaces in batch, currently they need to use the opt-in and opt-out approach one by one, or use label-selector but if it has big different labels on each different related pod, which is cumbersome when they have lots of volumes to handle with. it would be convenient if Velero could provide policies to handle the backup of volumes just by `some specific volumes conditions`.
+ 
+## Background
+As of Today, Velero has lots of filters to handle (backup or skip backup) resources including resources filters like `IncludedNamespaces, ExcludedNamespaces`, label selectors like `LabelSelector, OrLabelSelectors`, annotation like `backup.velero.io/must-include-additional-items` etc. But it's not enough flexible to handle volumes, we need one generic way to handle volumes.
+ 
+## Goals
+- Introducing flexible policies to handle volumes, and do not patch any labels or annotations to the pods or volumes.
+ 
+## Non-Goals
+- We only handle volumes for backup and do not support restore.
+- Currently, only handles volumes, and does not support other resources.
+- Only environment-unrelated and platform-independent general volumes attributes are supported, do not support volumes attributes related to a specific environment.
+ 
+## Use-cases/Scenarios
+### Skip backup volumes by some attributes
+Users want to skip PV with the requirements:
+- option to skip all PV data
+- option to skip specified PV type (RBD, NFS)
+- option to skip specified PV size
+- option to skip specified storage-class
+ 
+## High-Level Design
+First, Velero will provide the user with one YAML file template and all supported volume policies will be in.
+
+Second, writing your own configuration file by imitating the YAML template, it could be partial volume policies from the template.
+
+Third, create one configmap from your own configuration file, and the configmap should be in Velero install namespace.
+
+Fourth, create a backup with the command `velero backup create --resource-policies-configmap $policiesConfigmap`, which will reference the current backup to your volume policies. At the same time, Velero will validate all volume policies user imported, the backup will fail if the volume policies are not supported or some items could not be parsed.
+
+Fifth, the current backup CR will record the reference of volume policies configmap.
+
+Sixth, Velero first filters volumes by other current supported filters, at last, it will apply the volume policies to the filtered volumes to get the final matched volume to handle.
+ 
+## Detailed Design
+The volume resources policies should contain a list of policies which is the combination of conditions and related `action`, when target volumes meet the conditions, the related `action` will take effection.
+
+Below is the API Design for the user configuration:
+
+### API Design
+```go
+type VolumeActionType string
+
+const Skip VolumeActionType = "skip"
+
+// Action defined as one action for a specific way of backup
+type Action struct {
+	// Type defined specific type of action, it could be 'file-system-backup', 'volume-snapshot', or 'skip' currently
+	Type VolumeActionType `yaml:"type"`
+	// Parameters defined map of parameters when executing a specific action
+	// +optional
+	// +nullable
+	Parameters map[string]interface{} `yaml:"parameters,omitempty"`
+}
+
+// VolumePolicy defined policy to conditions to match Volumes and related action to handle matched Volumes
+type VolumePolicy struct {
+	// Conditions defined list of conditions to match Volumes
+	Conditions map[string]interface{} `yaml:"conditions"`
+	Action     Action                 `yaml:"action"`
+}
+
+// ResourcePolicies currently defined slice of volume policies to handle backup
+type ResourcePolicies struct {
+  Version        string         `yaml:"version"`
+	VolumePolicies []VolumePolicy `yaml:"volumePolicies"`
+	// we may support other resource policies in the future, and they could be added separately
+  	// OtherResourcePolicies: []OtherResourcePolicy
+}
+```
+
+The policies YAML config file would look like this:
+```yaml
+version: v1
+volumePolicies:
+# it's a list and if the input item matches the first policy, the latters will be ignored
+# each policy consists of a list of conditions and an action
+
+# each key in the object is one condition, and one policy will apply to resources that meet ALL conditions
+- conditions:
+    # capacity condition matches the volumes whose capacity falls into the range
+    capacity: "0,100Gi"
+    csi:
+      driver: aws.ebs.csi.driver
+      fsType: ext4
+    storageClass:
+    - gp2
+    - ebs-sc
+  action:
+    type: volume-snapshot
+    parameters:
+      # optional parameters which are custom-defined parameters when doing an action
+      volume-snapshot-timeout: "6h"
+- conditions:
+    capacity: "0,100Gi"
+    storageClass:
+    - gp2
+    - ebs-sc
+  action:
+    type: file-system-backup
+- conditions:
+    nfs:
+      server: 192.168.200.90
+  action:
+    # type of file-system-backup could be defined a second time
+    type: file-system-backup
+- conditions:
+    nfs: {}
+  action:
+    type: skip
+- conditions:
+    csi:
+      driver: aws.efs.csi.driver
+  action:
+    type: skip
+```
+ 
+### Filter rules
+#### VolumePolicies
+The whole resource policies consist of groups of volume policies.
+
+For one specific volume policy which is a combination of one action and serval conditions. which means one action and serval conditions are the smallest unit of volume policy.
+
+Volume policies are a list and if the target volumes match the first policy, the latter will be ignored, which would reduce the complexity of matching volumes especially when there are multiple complex volumes policies.
+
+#### Action
+`Action` defined one action for a specific way of backup:
+  - if choosing `Kopia` or `Restic`, the action value would be `file-system-backup`.
+  - if choosing volume snapshot, the action value would be `volume-snapshot`.
+  - if choosing skip backup of volume, the action value would be `skip`, and it will skip backup of volume no matter is `file-system-backup` or `volume-snapshot`.
+
+The policies could be extended for later other ways of backup, which means it may have some other `Action` value that will be assigned in the future.
+
+Both `file-system-backup` `volume-snapshot`, and `skip` could be partially or fully configured in the YAML file. And configuration could take effect only for the related action.
+
+#### Conditions
+The conditions are serials of volume attributes, the matched Volumes should meet all the volume attributes in one conditions configuration.
+
+##### Supported conditions
+In Velero 1.11, we want to support the volume attributes listed below:
+- capacity: matching volumes have the capacity that falls within this `capacity` range.
+- storageClass: matching volumes those with specified `storageClass`, such as `gp2`, `ebs-sc` in eks.
+- matching volumes that used specified volume sources.
+##### Parameters
+Parameters are optional for one specific action. For example, it could be `csi-snapshot-timeout: 6h` for CSI snapshot.
+
+#### Special rule definitions:
+- One single condition in `Conditions` with a specific key and empty value, which means the value matches any value. For example, if the `conditions.nfs` is `{}`, it means if `NFS` is used as `persistentVolumeSource` in Persistent Volume will be skipped no matter what the NFS server or NFS Path is.
+ 
+- The size of each single filter value should limit to 256 bytes in case of an unfriendly long variable assignment.
+ 
+- For capacity for PV or size for Volume, the value should include the lower value and upper value concatenated by commas. And it has several combinations below:
+  - "0,5Gi" or "0Gi,5Gi" which means capacity or size matches from 0 to 5Gi, including value 0 and value 5Gi
+  - ",5Gi" which is equal to "0,5Gi"
+  - "5Gi," which means capacity or size matches larger than 5Gi, including value 5Gi
+  - "5Gi" which is not supported and will be failed in validating configuration.
+ 
+### Configmap Reference
+Currently, resources policies are defined in `BackupSpec` struct, it will be more and more bloated with adding more and more filters which makes the size of `Backup` CR bigger and bigger, so we want to store the resources policies in configmap, and `Backup` CRD reference to current configmap.
+
+the `configmap` user created would be like this:
+```yaml
+apiVersion: v1
+data:
+ policies.yaml:
+  ----
+  version: v1
+  volumePolicies:
+  - conditions:
+      capacity: "0,100Gi"
+      csi:
+        driver: aws.ebs.csi.driver
+        fsType: ext4
+      storageClass:
+      - gp2
+      - ebs-sc
+    action:
+      type: volume-snapshot
+      parameters:
+        volume-snapshot-timeout: "6h"
+kind: ConfigMap
+metadata:
+ creationTimestamp: "2023-01-16T14:08:12Z"
+ name: backup01
+ namespace: velero
+ resourceVersion: "17891025"
+ uid: b73e7f76-fc9e-4e72-8e2e-79db717fe9f1
+```
+
+A new variable `resourcePolices` would be added into `BackupSpec`, it's value is assigned with the current resources policy configmap
+```yaml
+apiVersion: velero.io/v1
+kind: Backup
+metadata:
+  name: backup-1
+  spec:
+    resourcePolices:
+      refType: Configmap
+      ref: backup01
+    ...
+```
+The configmap only stores those assigned values, not the whole resources policies.
+ 
+The name of the configmap is `$BackupName`, and it's in Velero install namespace.
+ 
+#### Resource policies configmap related
+The life cycle of resource policies configmap is managed by the user instead of Velero, which could make it more flexible and easy to maintain.
+- The resource policies configmap will remain in the cluster until the user deletes it.
+- Unlike backup, the resource policies configmap will not sync to the new cluster. So if the user wants to use one resource policies that do not sync to the new cluster, the backup will fail with resource policies not found.
+- One resource policies configmap could be used by multiple backups.
+- If the backup referenced resource policies configmap is been deleted, it won't affect the already existing backups, but if the user wants to reference the deleted configmap to create one new backup, it will fail with resource policies not found.
+
+#### Versioning
+We want to introduce the version field in the YAML data to contain break changes. Therefore, we won't follow a semver paradigm, for example in v1.11 the data look like this:
+```yaml
+version: v1
+volumePolicies:
+  ....
+```
+Hypothetically, in v1.12 we add new fields like clusterResourcePolicies, the version will remain as v1 b/c this change is backward compatible:
+```yaml
+version: v1
+volumePolicies:
+  ....
+clusterResourcePolicies:
+  ....
+```
+Suppose in v1.13, we have to introduce a break change, at this time we will bump up the version:
+```yaml
+version: v2
+# This is just an example, we should try to avoid break change
+volume-policies: 
+  ....
+```
+We only support one version in Velero, so it won't be recognized if backup using a former version of YAML data.
+
+#### Multiple versions supporting
+To manage the effort for maintenance, we will only support one version of the data in Velero. Suppose that there is one break change for the YAML data in Velero v1.13, we should bump up the config version to v2, and v2 is only supported in v1.13. For the existing data with version: v1, it should migrate them when the Velero startup, this won't hurt the existing backup schedule CR as it only references the configmap. To make the migration easier, the configmap for such resource filter policies should be labeled manually before Velero startup like this, Velero will migrate the labeled configmap.
+
+We only support migrating from the previous version to the current version in case of complexity in data format conversion, which users could regenerate configmap in the new YAML data version, and it is easier to do version control.
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  labels:
+# This label can be optional but if this is not set, the backup will fail after the breaking change and the user will need to update the data manually 
+    velero.io/resource-filter-policies: "true"
+  name: example
+  namespace: velero
+data:
+  .....
+```
+### Display of resources policies
+As the resource policies configmap is referenced by backup CR, the policies in configmap are not so intuitive, so we need to integrate policies in configmap to the output of the command `velero backup describe`, and make it more readable.
+ 
+## Compatibility
+Currently, we have these resources filters:
+- IncludedNamespaces
+- ExcludedNamespaces
+- IncludedResources
+- ExcludedResources
+- LabelSelector
+- OrLabelSelectors
+- IncludeClusterResources
+- UseVolumeSnapshots
+- velero.io/exclude-from-backup=true
+- backup.velero.io/backup-volumes-excludes
+- backup.velero.io/backup-volumes
+- backup.velero.io/must-include-additional-items
+ 
+So it should be careful with the combination of volumes resources policies and the above resources filters.
+- When volume resource policies conflict with the above resource filters, we should respect the above resource filters. For example, if the user used the opt-out approach to `backup.velero.io/backup-volumes-excludes` annotation on the pod and also defined include volume in volumes resources filters configuration, we should respect the opt-out approach to skip backup of the volume.
+- If volume resource policies conflict with themselves, the first matched policy will be respect.
+
+## Implementation
+This implementation should be included in Velero v1.11.0
+
+Currently, in Velero v1.11.0 we only support `Action`
+ `skip`, and support `file-system-backup` and `volume-snapshot` for the later version. And `Parameters` in `Action` is also not supported in v1.11.0, we will support in a later version.
+
+In Velero 1.11, we supported Conditions and format listed below:
+ - capacity
+    ```yaml
+    capacity: "10Gi,100Gi" // match volume has the size between 10Gi and 100Gi
+    ```
+ - storageClass
+    ```yaml
+    storageClass: // match volume has the storage class gp2 or ebs-sc
+     - gp2
+     - ebs-sc
+    ```
+- volume sources (currently only support below format and attributes)
+  1. Specify the volume source name, the name could be `nfs`, `rbd`, `iscsi`, `csi` etc.
+     ```yaml
+     nfs : {} // match any volume has nfs volume source
+     
+     csi : {} // match any volume has csi volume source
+     ```
+
+  2. Specify details for the related volume source (currently we only support csi driver filter and nfs server or path filter)
+     ```yaml
+     csi: // match volume has nfs volume source and using `aws.efs.csi.driver`
+       driver: aws.efs.csi.driver 
+     
+     nfs: // match volume has nfs volume source and using below server and path
+       server: 192.168.200.90
+       path: /mnt/nfs
+     ```
+The conditions also could be extended in later versions, such as we could further supporting filtering other volume source detail not only NFS and CSI.
+
+## Alternatives Considered
+### Configmap VS CRD
+Here we support the user define the YAML config file and storing the resources policies into configmap, also we could define one resource's policies CRD and store policies imported from the user-defined config file in the related CR.
+
+But CRD is more like one kind of resource with status, Kubernetes API Server handles the lifecycle of a CR and handles it in different statuses. Compared to CRD, Configmap is more focused to store data.
+
+## Open Issues
+Should we support more than one version of filter policies configmap?

design/Implemented/json-substitution-action-design.md

@@ -0,0 +1,161 @@
+# Proposal to add support for Resource Modifiers (AKA JSON Substitutions) in Restore Workflow
+
+- [Proposal to add support for Resource Modifiers (AKA JSON Substitutions) in Restore Workflow](#proposal-to-add-support-for-resource-modifiers-aka-json-substitutions-in-restore-workflow)
+    - [Abstract](#abstract)
+    - [Goals](#goals)
+    - [Non Goals](#non-goals)
+    - [User Stories](#user-stories)
+        - [Scenario 1](#scenario-1)
+        - [Scenario 2](#scenario-2)
+    - [Detailed Design](#detailed-design)
+        - [Reference in velero API](#reference-in-velero-api)
+        - [ConfigMap Structure](#configmap-structure)
+        - [Operations supported by the JSON Patch library:](#operations-supported-by-the-json-patch-library)
+        - [Advance scenarios](#advance-scenarios)
+            - [Conditional patches using test operation](#conditional-patches-using-test-operation)
+    - [Alternatives Considered](#alternatives-considered)
+    - [Security Considerations](#security-considerations)
+    - [Compatibility](#compatibility)
+    - [Implementation](#implementation)
+    - [Future Enhancements](#future-enhancements)
+    - [Open Issues](#open-issues)
+
+## Abstract
+Currently velero supports substituting certain values in the K8s resources during restoration like changing the namespace, changing the storage class, etc. This proposal is to add generic support for JSON substitutions in the restore workflow. This will allow the user specify filters for particular resources and then specify a JSON patch (operator, path, value) to apply on a resource. This will allow the user to substitute any value in the K8s resource without having to write a new RestoreItemAction plugin for each kind of substitution.
+
+<!-- ## Background -->
+
+## Goals
+- Allow the user to specify a GroupResource, Name(optional), JSON patch for modification.
+- Allow the user to specify multiple JSON patch.
+
+## Non Goals
+- Deprecating the existing RestoreItemAction plugins for standard substitutions(like changing the namespace, changing the storage class, etc.)
+
+## User Stories
+
+### Scenario 1
+- Alice has a PVC which is encrypted using a DES(Disk Encryption Set - Azure example) mentioned in the PVC YAML through the StorageClass YAML. 
+- Alice wishes to restore this snapshot to a different cluster. The new cluster does not have access to the same DES to provision disk's out of the snapshot.
+- She wishes to use a different DES for all the PVCs which use the certain DES.
+- She can use this feature to substitute the DES in all StorageClass YAMLs with the new DES without having to create a fresh storageclass, or understanding the name of the storageclass.
+
+### Scenario 2
+- Bob has multi zone cluster where nodes are spread across zones. 
+- Bob has pinned certain pods to a particular zone using nodeSelector/ nodeaffinity on the pod spec.
+- In case of zone outage of the cloudprovider, Bob wishes to restore the workload to a different namespace in the same cluster, but change the zone pinning of the workload.
+- Bob can use this feature to substitute the nodeSelector/ nodeaffinity in the pod spec with the new zone pinning to quickly failover the workload to a different zone's nodes.
+
+## Detailed Design
+- The design and approach is inspired from [kubectl patch command](https://github.com/kubernetes/kubectl/blob/0a61782351a027411b8b45b1443ec3dceddef421/pkg/cmd/patch/patch.go#L102C2-L104C1)
+```bash
+# Update a container's image using a json patch with positional arrays
+kubectl patch pod valid-pod -type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"new image"}]'
+```
+- The user is expected to create a configmap with the desired Resource Modifications. Then the reference of the configmap will be provided in the RestoreSpec.
+- The core restore workflow before creating/updating a particular resource in the cluster will be checked against the filters provided and respective substitutions will be applied on it.
+
+### Reference in velero API 
+> Example of Reference to configmap in RestoreSpec
+```yaml
+apiVersion: velero.io/v1
+kind: Restore
+metadata:
+  name: restore-1
+spec:
+    resourceModifier:
+      refType: Configmap
+      ref: resourcemodifierconfigmap
+```
+> Example CLI Command
+```bash
+velero restore create --from-backup backup-1 --resource-modifier-configmap resourcemodifierconfigmap
+```
+
+### Resource Modifier ConfigMap Structure
+- User first needs to provide details on which resources the JSON Substitutions need to be applied. 
+    - For this the user will provide 4 inputs - Namespaces(for NS Scoped resources), GroupResource (resource.group format similar to includeResources field in velero) and Name Regex(optional).
+    - If the user does not provide the Name, the JSON Substitutions will be applied to all the resources of the given Group and Kind under the given namespaces.
+
+- Further the use will specify the JSON Patch using the structure of kubectl's "JSON Patch" based inputs.
+- Sample data in ConfigMap
+```yaml
+version: v1
+resourceModifierRules:
+- conditions:
+    groupResource: persistentvolumeclaims
+    resourceNameRegex: "mysql.*"
+    namespaces:
+    - bar
+    - foo
+  patches:
+  - operation: replace
+    path: "/spec/storageClassName"
+    value: "premium"
+  - operation: remove
+    path: "/metadata/labels/test"
+```
+- The above configmap will apply the JSON Patch to all the PVCs in the namespaces bar and foo with name starting with mysql. The JSON Patch will replace the storageClassName with "premium" and remove the label "test" from the PVCs.
+- Note that the Namespace here is the original namespace of the backed up resource, not the new namespace where the resource is going to be restored.
+- The user can specify multiple JSON Patches for a particular resource. The patches will be applied in the order specified in the configmap. A subsequent patch is applied in order and if multiple patches are specified for the same path, the last patch will override the previous patches.
+- The user can specify multiple resourceModifierRules in the configmap. The rules will be applied in the order specified in the configmap. 
+
+> Users need to create one configmap in Velero install namespace from a YAML file that defined resource modifiers. The creating command would be like the below:
+```bash
+kubectl create cm <configmap-name> --from-file <yaml-file> -n velero
+```
+
+### Operations supported by the JSON Patch library: 
+- add
+- remove
+- replace
+- move
+- copy
+- test (covered below)
+
+### Advance scenarios
+#### **Conditional patches using test operation**
+ The `test` operation can be used to check if a particular value is present in the resource. If the value is present, the patch will be applied. If the value is not present, the patch will not be applied. This can be used to apply a patch only if a particular value is present in the resource. For example, if the user wishes to change the storage class of a PVC only if the PVC is using a particular storage class, the user can use the following configmap.
+```yaml
+version: v1
+resourceModifierRules:
+- conditions:
+    groupResource: persistentvolumeclaims.storage.k8s.io
+    resourceNameRegex: ".*"
+    namespaces:
+    - bar
+    - foo
+  patches:
+  - operation: test
+    path: "/spec/storageClassName"
+    value: "premium"
+  - operation: replace
+    path: "/spec/storageClassName"
+    value: "standard"
+```
+
+## Alternatives Considered
+1. JSON Path based addressal of json fields in the resource
+    - This was the initial planned approach, but there is no open source library which gives satisfactory edit functionality with support for all operators supported by the JsonPath RFC.
+    - We attempted modifying the  [https://kubernetes.io/docs/reference/kubectl/jsonpath/](https://kubernetes.io/docs/reference/kubectl/jsonpath/) but given the complexity of the code it did not make sense to change it since it would become a long term maintainability problem.
+1. RestoreItemAction for each kind of standard substitution
+    - Not an extensible design. If a new kind of substitution is required, a new RestoreItemAction needs to be written.
+1. RIA for JSON Substitution: The approach of doing JSON Substitution through a RestoreItemAction plugin was considered. But it is likely to have performance implications as the plugin will be invoked for all the resources.
+
+## Security Considerations
+No security impact.
+
+## Compatibility
+Compatibility with existing StorageClass mapping RestoreItemAction and similar plugins needs to be evaluated. 
+
+## Implementation
+- Changes in Restore CRD. Add a new field to the RestoreSpec to reference the configmap.
+- One example of where code will be modified:  https://github.com/vmware-tanzu/velero/blob/eeee4e06d209df7f08bfabda326b27aaf0054759/pkg/restore/restore.go#L1266 On the obj before Creation, we can apply the conditions to check if the resource is filtered out using given parameters. Then using JsonPatch provided, we can update the resource.
+- For Jsonpatch - https://github.com/evanphx/json-patch library is used.
+- JSON Patch RFC https://datatracker.ietf.org/doc/html/rfc6902
+
+## Future enhancements
+- Additional features such as wildcard support in path, regex match support in value, etc. can be added in future. This would involve forking the https://github.com/evanphx/json-patch library and adding the required features, since those features are not supported by the library currently and are not part of jsonpatch RFC.
+
+## Open Issues
+NA

design/Implemented/multiple-csi-volumesnapshotclass-support.md

@@ -0,0 +1,177 @@
+# Proposal to add support for Multiple VolumeSnapshotClasses in CSI Plugin
+
+- [Proposal to add support for Multiple VolumeSnapshotClasses in CSI Plugin](#proposal-to-add-support-for-multiple-volumesnapshotclasses-in-csi-plugin)
+	- [Abstract](#abstract)
+	- [Background](#background)
+	- [Goals](#goals)
+	- [Non Goals](#non-goals)
+    - [User Stories](#user-stories)
+        - [Scenario 1](#scenario-1)
+        - [Scenario 2](#scenario-2)
+    - [Detailed Design](#detailed-design)
+        - [Plugin Inputs Contract Changes](#plugin-inputs-contract-changes)
+        - [Using Plugin Inputs for CSI Plugin](#using-plugin-inputs-for-csi-plugin)
+        - [Annotations overrides on PVC for CSI Plugin](#annotations-overrides-on-pvc-for-csi-plugin)
+        - [Using Plugin Inputs for Other Plugins](#using-plugin-inputs-for-other-plugins)
+    - [Alternatives Considered](#alternatives-considered)
+    - [Security Considerations](#security-considerations)
+    - [Compatibility](#compatibility)
+    - [Implementation](#implementation)
+    - [Open Issues](#open-issues)
+
+
+## Abstract
+Currently the Velero CSI plugin chooses the VolumeSnapshotClass in the cluster that has the same driver name and also has the velero.io/csi-volumesnapshot-class label set on it. This global selection is not sufficient for many use cases. This proposal is to add support for multiple VolumeSnapshotClasses in CSI Plugin where the user can specify the VolumeSnapshotClass to use for a particular driver and backup.
+
+
+## Background
+The Velero CSI plugin chooses the VolumeSnapshotClass in the cluster that has the same driver name and also has the velero.io/csi-volumesnapshot-class label set on it. This global selection is not sufficient for many use cases. For example, if a cluster has multiple VolumeSnapshotClasses for the same driver, the user may want to use a VolumeSnapshotClass that is different from the default one. The user might also have different schedules set up for backing up different parts of the cluster and might wish to use different VolumeSnapshotClasses for each of these backups. 
+
+## Goals
+- Allow the user to specify the VolumeSnapshotClass to use for a particular driver and backup.
+
+## Non Goals
+- Deprecating existing VSC selection behaviour. (The current behaviour will remain the default behaviour if the user does not specify the VolumeSnapshotClass to use for a particular driver and backup.)
+
+
+## User Stories
+
+### Scenario 1
+- Consider Alice is a cluster admin and has a cluster with multiple VolumeSnapshotClasses for the same driver. Each VSC stores the snapshots taken in different ResourceGroup(Azure equivalent). 
+- Alice has configured multiple scheduled backups each covering a different set of namespaces, representing different apps owned by different teams. 
+- Alice wants to use a different VolumeSnapshotClass for each backup such that each snapshot goes in it's respective ResourceGroup to simply management of snapshots(COGS, RBAC etc).
+- In current velero, Alice can't achieve this as the CSI plugin will use the default VolumeSnapshotClass for the driver and all snapshots will go in the same ResourceGroup.
+- Proposed design will allow Alice to achieve this by specifying the VolumeSnapshotClass to use for a particular driver and backup/schedule.
+
+## Scenario 2
+- Bob is a cluster admin has PVCs storing different types of data. 
+- Most of the PVCs are used for storing non-sensitive application data. But certain PVCs store critical financial data.
+- For such PVCs Bob wants to use a VolumeSnapshotClass with certain encryption related parameters set. 
+- In current velero, Bob can't achieve this as the CSI plugin will use the default VolumeSnapshotClass for the driver and all snapshots will be taken using the same VolumeSnapshotClass.
+- Proposed design will allow Bob to achieve this by overriding the VolumeSnapshotClass to use for a particular driver and backup/schedule using annotations on those specific PVCs.
+
+
+## Detailed Design
+
+### Staged Approach: 
+
+### Stage 1 Approach
+#### Through Annotations
+    1. **Support VolumeSnapshotClass selection at backup/schedule level**
+    The user can  annotate the backup/ schedule with driver and VolumeSnapshotClass name. The CSI plugin will use the VolumeSnapshotClass specified in the annotation. If the annotation is not present, the CSI plugin will use the default VolumeSnapshotClass for the driver.
+
+        *example annotation on backup/schedule:*
+        ```yaml
+        apiVersion: velero.io/v1
+        kind: Backup
+        metadata:
+        name: backup-1
+        annotations:
+            velero.io/csi-volumesnapshot-class_csi.cloud.disk.driver: csi-diskdriver-snapclass
+            velero.io/csi-volumesnapshot-class_csi.cloud.file.driver: csi-filedriver-snapclass
+            velero.io/csi-volumesnapshot-class_<driver name>: csi-snapclass
+        ```
+
+         To query the annotations on a backup: "velero.io/csi-volumesnapshot-class_'driver name'" - where driver names comes from the PVC's driver.
+
+    2. **Support VolumeSnapshotClass selection at PVC level**
+    The user can annotate the PVCs with driver and VolumeSnapshotClass name. The CSI plugin will use the VolumeSnapshotClass specified in the annotation. If the annotation is not present, the CSI plugin will use the default VolumeSnapshotClass for the driver. If the VolumeSnapshotClass provided is of a different driver, the CSI plugin will use the default VolumeSnapshotClass for the driver.
+
+        *example annotation on PVC:*
+        ```yaml
+        apiVersion: v1
+        kind: PersistentVolumeClaim
+        metadata:
+        name: pvc-1
+        annotations:
+            velero.io/csi-volumesnapshot-class: csi-diskdriver-snapclass
+            
+        ```
+    
+    Consider this as a override option in conjunction to part 1.
+
+**Note**: The user has to annotate the PVCs or backups with the VolumeSnapshotClass to use for each driver. This is not ideal for the user experience.
+    - **Mitigation**: We can extend Velero CLI to also annotate backups/schedules with the VolumeSnapshotClass to use for each driver. This will make it easier for the user to annotate the backups/schedules. This mitigation is not for the PVCs though, since PVCs is anyways a specific use case. Similar to : " kubectl run --image myimage --annotations="foo=bar" --annotations="another=one" mypod"
+    We can add support for  - velero backup create my-backup --annotations "velero.io/csi:csi.cloud.disk.driver=csi-diskdriver-snapclass"
+
+### Stage 2 Approach
+The above annotations route is to get started and for initial design closure/ implementation, north star is to either introduce CSI specific fields (considering that CSI might be a very core part of velero going forward) in the backup/restore CR OR leverage the pluginInputs field as being tracked in: https://github.com/vmware-tanzu/velero/pull/5981
+
+Refer section Alternatives 2. **Through generic property bag in the velero contracts**: in the design doc for more details on the pluginInputs field.
+
+
+## Alternatives Considered
+1. **Through CSI Specific Fields in Velero contracts**
+
+    **Considerations**
+    - Since CSI snapshotting is done through the plugin, we don't intend to bloat up the Backup Spec with CSI specific fields. 
+    - But considering that CSI Snapshotting is the way forward, we can debate if we should add a CSI section to the Backup Spec.
+
+
+    **Approach**: Similar to VolumeSnapshotLocation param in the Backup Spec, we can add a VolumeSnapshotClass param in the Backup Spec. This will allow the user to specify the VolumeSnapshotClass to use for the backup. The CSI plugin will use the VolumeSnapshotClass specified in the Backup Spec. If the VolumeSnapshotClass is not specified, the CSI plugin will use the default VolumeSnapshotClass for the driver.
+
+    *example of VolumeSnapshotClass param in the Backup Spec:*
+    ```yaml
+    apiVersion: velero.io/v1
+    kind: Backup
+    metadata:
+    name: backup-1
+    spec:
+        csiParameters: 
+            volumeSnapshotClasses: 
+                driver: csi.cloud.disk.driver
+                snapClass: csi-diskdriver-snapclass
+            timeout: 10m
+    ```
+
+1. **Through changes in velero contracts**
+    1. **Through configmap references.**
+    Currently even the storageclass mapping plugin expects the user to create a configmap which is used globally, and fetched through labels. This behaviour has same issue as the VolumeSnapshotClass selection. We can introduce a field in the velero contracts which allow passing configmap references for each plugin. And then the plugin can honour the configmap passed in as reference. The configmap can be used to pass the VolumeSnapshotClass to use for the backup, and also other parameters to tweak. This can help in making plugins more flexible while not depending on global behaviour.
+    
+
+        *example of configmap reference in the velero contracts:*
+        ```yaml
+        apiVersion: velero.io/v1
+        kind: Backup
+        metadata:
+        name: backup-1
+        spec:
+            configmapRefs:
+            - name: csi-volumesnapshotclass-configmap
+            - namespace: velero
+            - plugin: velero.io/csi
+         ```
+
+    2. **Through generic property bag in the velero contracts**: We can introduce a field in the velero contracts which allow passing a generic property bag for each plugin. And then the plugin can honour the property bag passed in.
+
+
+        *example of property bag in the velero contracts:*
+        ```yaml
+        apiVersion: velero.io/v1
+        kind: Backup
+        metadata:
+        name: backup-1
+        spec:
+            pluginInputs:
+            - name: velero.io/csi
+            - properties:
+                - key: csi.cloud.disk.driver
+                - value: csi-diskdriver-snapclass
+                - key: csi.cloud.file.driver
+                - value: csi-filedriver-snapclass
+        ```
+
+    **Note**: Both these approaches can also be used to tweak other parameters such as CSI Snapshotting Timeout/intervals. And further can be used by other plugins.
+
+
+## Security Considerations
+No security impact.
+
+## Compatibility
+Existing behaviour of csi plugin will be retained where it fetches the VolumeSnapshotClass through the label. This will be the default behaviour if the user does not specify the VolumeSnapshotClass.
+
+## Implementation
+TBD based on closure of high level design proposals.
+
+## Open Issues
+NA

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

design/Implemented/riav2-design.md

@@ -0,0 +1,130 @@
+# Design for RestoreItemAction v2 API
+
+## Abstract
+This design includes the changes to the RestoreItemAction (RIA) api design as required by the [Item Action Progress Monitoring](general-progress-monitoring.md) feature.
+It also includes changes as required by the [Wait For Additional Items](wait-for-additional-items.md) feature.
+The BIA v2 interface will have three new methods, and the RestoreItemActionExecuteOutput() struct in the return from Execute() will have three optional fields added.
+If there are any additional RIA API changes that are needed in the same Velero release cycle as this change, those can be added here as well.
+
+## Background
+This API change is needed to facilitate long-running plugin actions that may not be complete when the Execute() method returns.
+It is an optional feature, so plugins which don't need this feature can simply return an empty operation ID and the new methods can be no-ops.
+This will allow long-running plugin actions to continue in the background while Velero moves on to the next plugin, the next item, etc.
+The other change allows Velero to wait until newly-restored AdditionalItems returned by a RIA plugin are ready before moving on to restoring the current item.
+
+## Goals
+- Allow for RIA Execute() to optionally initiate a long-running operation and report on operation status.
+- Allow for RIA to allow Velero to call back into the plugin to wait until AdditionalItems are ready before continuing with restore.
+
+## Non Goals
+- Allowing velero control over when the long-running operation begins.
+
+
+## High-Level Design
+As per the [Plugin Versioning](plugin-versioning.md) design, a new RIAv2 plugin `.proto` file will be created to define the GRPC interface.
+v2 go files will also be created in `plugin/clientmgmt/restoreitemaction` and `plugin/framework/restoreitemaction`, and a new PluginKind will be created.
+Changes to RestoreItemActionExecuteOutput will be made to the existing struct.
+Since the new fields are optional elements of the struct, the new enlarged struct will work with both v1 and v2 plugins.
+The velero Restore process will be modified to reference v2 plugins instead of v1 plugins.
+An adapter will be created so that any existing RIA v1 plugin can be executed as a v2 plugin when executing a restore.
+
+## Detailed Design
+
+### proto changes (compiled into golang by protoc)
+
+The v2 RestoreItemAction.proto will be like the current v1 version with the following changes:
+RestoreItemActionExecuteOutput gets three new fields (defined in the current (v1) RestoreItemAction.proto file:
+```
+message RestoreItemActionExecuteResponse {
+    bytes item = 1;
+    repeated ResourceIdentifier additionalItems = 2;
+    bool skipRestore = 3;
+    string operationID = 4;
+    bool waitForAdditionalItems = 5;
+    google.protobuf.Duration additionalItemsReadyTimeout = 6;
+}
+
+```
+The RestoreItemAction service gets three new rpc methods:
+```
+service RestoreItemAction {
+    rpc AppliesTo(RestoreItemActionAppliesToRequest) returns (RestoreItemActionAppliesToResponse);
+    rpc Execute(RestoreItemActionExecuteRequest) returns (RestoreItemActionExecuteResponse);
+    rpc Progress(RestoreItemActionProgressRequest) returns (RestoreItemActionProgressResponse);
+    rpc Cancel(RestoreItemActionCancelRequest) returns (google.protobuf.Empty);
+    rpc AreAdditionalItemsReady(RestoreItemActionItemsReadyRequest) returns (RestoreItemActionItemsReadyResponse);
+}
+
+```
+To support these new rpc methods, we define new request/response message types:
+```
+message RestoreItemActionProgressRequest {
+    string plugin = 1;
+    string operationID = 2;
+    bytes restore = 3;
+}
+
+message RestoreItemActionProgressResponse {
+    generated.OperationProgress progress = 1;
+}
+
+message RestoreItemActionCancelRequest {
+    string plugin = 1;
+    string operationID = 2;
+    bytes restore = 3;
+}
+
+message RestoreItemActionItemsReadyRequest {
+    string plugin = 1;
+    bytes restore = 2;
+    repeated ResourceIdentifier additionalItems = 3;
+}
+message RestoreItemActionItemsReadyResponse {
+    bool ready = 1;
+}
+
+```
+One new shared message type will be needed, as defined in the v2 BackupItemAction design:
+```
+message OperationProgress {
+    bool completed = 1;
+    string err = 2;
+    int64 completed = 3;
+    int64 total = 4;
+    string operationUnits = 5;
+    string description = 6;
+    google.protobuf.Timestamp started = 7;
+    google.protobuf.Timestamp updated = 8;
+}
+```
+
+In addition to the three new rpc methods added to the RestoreItemAction interface, there is also a new `Name()` method. This one is only actually used internally by Velero to get the name that the plugin was registered with, but it still must be defined in a plugin which implements RestoreItemActionV2 in order to implement the interface. It doesn't really matter what it returns, though, as this particular method is not delegated to the plugin via RPC calls. The new (and modified) interface methods for `RestoreItemAction` are as follows:
+```
+type BackupItemAction interface {
+...
+	Name() string
+...
+	Progress(operationID string, restore *api.Restore) (velero.OperationProgress, error)
+	Cancel(operationID string, backup *api.Restore) error
+	AreAdditionalItemsReady(AdditionalItems []velero.ResourceIdentifier, restore *api.Restore) (bool, error)
+...
+}
+type RestoreItemActionExecuteOutput struct {
+	UpdatedItem            runtime.Unstructured
+	AdditionalItems        []ResourceIdentifier
+	SkipRestore            bool
+	OperationID            string
+	WaitForAdditionalItems bool
+}
+
+```
+
+A new PluginKind, `RestoreItemActionV2`, will be created, and the restore process will be modified to use this plugin kind.
+See [Plugin Versioning](plugin-versioning.md) for more details on implementation plans, including v1 adapters, etc.
+
+
+## Compatibility
+The included v1 adapter will allow any existing RestoreItemAction plugin to work as expected, with no-op AreAdditionalItemsReady(), Progress(), and Cancel() methods.
+
+## Implementation
+This will be implemented during the Velero 1.11 development cycle.

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

@@ -3,7 +3,7 @@
 ## Glossary & Abbreviation
 
 **BR**: Backup & Restore  
-**Backup Storage**: The storage that meets BR requirements, for example, scalable, durable, cost-effective, etc., therefore, Backup Storage is usually implemented as Object storage or File System storage, it may be on-premise or in cloud. Backup Storage is not BR specific necessarily, so it usually doesn’t provide most of the BR related features. On the other hand, storage vendors may provide BR specific storages that include some BR features like deduplication, compression, encryption, etc. For a standalone BR solution (i.e. Velero), the Backup Storage is not part of the solution, it is provided by users, so the BR solution should not assume the BR related features are always available from the Backup Storage.  
+**Backup Storage**: The storage that meets BR requirements, for example, scalable, durable, cost-effective, etc., therefore, Backup Storage is usually implemented as Object storage or File System storage, it may be on-premises or in cloud. Backup Storage is not BR specific necessarily, so it usually doesn’t provide most of the BR related features. On the other hand, storage vendors may provide BR specific storages that include some BR features like deduplication, compression, encryption, etc. For a standalone BR solution (i.e. Velero), the Backup Storage is not part of the solution, it is provided by users, so the BR solution should not assume the BR related features are always available from the Backup Storage.  
 **Backup Repository**: Backup repository is layered between BR data movers and Backup Storage to provide BR related features. Backup Repository is a part of BR solution, so generally, BR solution by default leverages the Backup Repository to provide the features because Backup Repository is always available; when Backup Storage provides duplicated features, and the latter is more beneficial (i.e., performance is better), BR solution should have the ability to opt to use the Backup Storage’s implementation.  
 **Data Mover**: The BR module to read/write data from/to workloads, the aim is to eliminate the differences of workloads.  
 **TCO**: Total Cost of Ownership. This is a general criteria for products/solutions, but also means a lot for BR solutions. For example, this means what kind of backup storage (and its cost) it requires, the retention policy of backup copies, the ways to remove backup data redundancy, etc.   
@@ -337,10 +337,9 @@ Therefore, for the new path, Velero uses the information in the BackupStorageLoc
 The legacy path will be kept as is. That is, Velero still sets/gets the repoIdentififer in BackupRepository CRs, PodVolume Backup CRs and PodVolume Restore CRs and then passes to Restic CLI.  
 
 ## Installation
- We will add a new flag "--pod-volume-backup-uploader" during installation. The flag has 3 meanings:
- - It indicates PodVolume BR as the default method to protect PV data over other methods, i.e., durable snapshot. Therefore, the existing --use-restic option will be replaced
+ We will add a new flag "--uploader-type" during installation. The flag has 2 meanings:
  - It indicates the file system uploader to be used by PodVolume BR
- - It implies the backup repository type manner, Restic if pod-volume-backup-uploader=restic, Unified Repository in all other cases
+ - It implies the backup repository type manner, Restic if uploader-type=restic, Unified Repository in all other cases
 
  The flag has below two values:  
  **"Restic"**: it means Velero will use Restic to do the pod volume backup. Therefore, the Velero server deployment will be created as below:
@@ -470,7 +469,7 @@ Below sample files demonstrate complete CRs with all the changes mentioned above
 
 ## User Perspective
 This design aims to provide a flexible backup repository layer and a generic file system uploader, which are fundermental for PodVolume and other data movements. Although this will make Velero more capable, at present, we don't pursue to expose differentiated features end to end. Specifically:  
-- By default, Velero still uses Restic for PodVolume BR
+- For a fresh installation, if the "--uploader-type" is not specified, there is a default value for PodVolume BR. We will keep it as "restic" for at least one release, then we switch the value to "kopia"
 - Even when changing to the new path, Velero still allows users to restore from the data backed up by Restic
 - The capability of PodVolume BR under the new path is kept the same as it under Restic path and the same as the existing PodVolume BR
 - The operational experiences are kept the same as much as possible, the known changes are listed below

design/Implemented/velero-debug.md

@@ -102,7 +102,7 @@ The code will consolidate the input parameters and execution context of the `vel
 https://github.com/vmware-tanzu/crash-diagnostics/blob/v0.3.4/exec/executor.go#L17
 
 ## Alternatives Considered
-The collection could be done via the kubernetes client-go API, but such integration is not necessarily trivial to implement, therefore, `crashd` is preferred approach
+The collection could be done via the Kubernetes client-go API, but such integration is not necessarily trivial to implement, therefore, `crashd` is preferred approach
 
 ## Security Considerations
 - The starlark script will be embedded into the velero binary, and the byte slice will be passed to the `exec.Execute` func directly, so there’s little risk that the script will be modified before being executed.

design/merge-patch-and-strategic-in-resource-modifier.md

@@ -0,0 +1,193 @@
+# Proposal to Support JSON Merge Patch and Strategic Merge Patch in Resource Modifiers
+
+- [Proposal to Support JSON Merge Patch and Strategic Merge Patch in Resource Modifiers](#proposal-to-support-json-merge-patch-and-strategic-merge-patch-in-resource-modifiers)
+    - [Abstract](#abstract)
+    - [Goals](#goals)
+    - [Non Goals](#non-goals)
+    - [User Stories](#user-stories)
+        - [Scenario 1](#scenario-1)
+        - [Scenario 2](#scenario-2)
+    - [Detailed Design](#detailed-design)
+        - [How to choose the right patch type](#how-to-choose-the-right-patch-type)
+        - [New Field MergePatches](#new-field-mergepatches)
+        - [New Field StrategicPatches](#new-field-strategicpatches)
+        - [Conditional Patches in ALL Patch Types](#conditional-patches-in-all-patch-types)
+        - [Wildcard Support for GroupResource](#wildcard-support-for-groupresource)
+        - [Helper Command to Generate Merge Patch and Strategic Merge Patch](#helper-command-to-generate-merge-patch-and-strategic-merge-patch)
+    - [Security Considerations](#security-considerations)
+    - [Compatibility](#compatibility)
+    - [Implementation](#implementation)
+    - [Future Enhancements](#future-enhancements)
+    - [Open Issues](#open-issues)
+
+## Abstract
+Velero introduced the concept of Resource Modifiers in v1.12.0. This feature allows the user to specify a configmap with a set of rules to modify the resources during restore. The user can specify the filters to select the resources and then specify the JSON Patch to apply on the resource. This feature is currently limited to the operations supported by JSON Patch RFC.
+This proposal is to add support for JSON Merge Patch and Strategic Merge Patch in the Resource Modifiers. This will allow the user to use the same configmap to apply JSON Merge Patch and Strategic Merge Patch on the resources during restore.
+
+## Goals
+- Allow the user to specify a JSON patch, JSON Merge Patch or Strategic Merge Patch for modification.
+- Allow the user to specify multiple JSON Patch, JSON Merge Patch or Strategic Merge Patch.
+- Allow the user to specify mixed JSON Patch, JSON Merge Patch and Strategic Merge Patch in the same configmap.
+
+## Non Goals
+- Deprecating the existing RestoreItemAction plugins for standard substitutions(like changing the namespace, changing the storage class, etc.)
+
+## User Stories
+
+### Scenario 1
+- Alice has some Pods and part of them have an annotation `{"for": "bar"}`.
+- Alice wishes to restore these Pods to a different cluster without this annotation.
+- Alice can use this feature to remove this annotation during restore.
+
+### Scenario 2
+- Bob has a Pod with several containers and one container with name nginx has an image `repo1/nginx`.
+- Bob wishes to restore this Pod to a different cluster, but new cluster can not access repo1, so he pushes the image to repo2.
+- Bob can use this feature to update the image of container nginx to `repo2/nginx` during restore.
+
+## Detailed Design
+- The design and approach is inspired by kubectl patch command and [this doc](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/).
+- New fields `MergePatches` and `StrategicPatches` will be added to the `ResourceModifierRule` struct to support all three patch types.
+- Only one of the three patch types can be specified in a single `ResourceModifierRule`.
+- Add wildcard support for `groupResource` in `conditions` struct.
+- The workflow to create Resource Modifier ConfigMap and reference it in RestoreSpec will remain the same as described in document [Resource Modifiers](https://github.com/vmware-tanzu/velero/blob/main/site/content/docs/main/restore-resource-modifiers.md).
+
+### How to choose the right patch type
+- [JSON Merge Patch](https://datatracker.ietf.org/doc/html/rfc7386) is a naively simple format, with limited usability. Probably it is a good choice if you are building something small, with very simple JSON Schema.
+- [JSON Patch](https://datatracker.ietf.org/doc/html/rfc6902) is a more complex format, but it is applicable to any JSON documents. For a comparison of JSON patch and JSON merge patch, see [JSON Patch and JSON Merge Patch](https://erosb.github.io/post/json-patch-vs-merge-patch/).
+- Strategic Merge Patch is a Kubernetes defined patch type, mainly used to process resources of type list. You can replace/merge a list, add/remove items from a list by key, change the order of items in a list, etc. Strategic merge patch is not supported for custom resources. For more details, see [this doc](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/).
+
+### New Field MergePatches
+MergePatches is a list to specify the merge patches to be applied on the resource. The merge patches will be applied in the order specified in the configmap. A subsequent patch is applied in order and if multiple patches are specified for the same path, the last patch will override the previous patches.
+
+Example of MergePatches in ResourceModifierRule
+```yaml
+version: v1
+resourceModifierRules:
+- conditions:
+    groupResource: pods
+    namespaces:
+    - ns1
+  mergePatches:
+  - patchData: |
+      {
+        "metadata": {
+          "annotations": {
+            "foo": null
+          }
+        }
+      }
+```
+- The above configmap will apply the Merge Patch to all the pods in namespace ns1 and remove the annotation `foo` from the pods.
+- Both json and yaml format are supported for the patchData.
+
+### New Field StrategicPatches
+StrategicPatches is a list to specify the strategic merge patches to be applied on the resource. The strategic merge patches will be applied in the order specified in the configmap. A subsequent patch is applied in order and if multiple patches are specified for the same path, the last patch will override the previous patches.
+
+Example of StrategicPatches in ResourceModifierRule
+```yaml
+version: v1
+resourceModifierRules:
+- conditions:
+    groupResource: pods
+    resourceNameRegex: "^my-pod$"
+    namespaces:
+    - ns1
+  strategicPatches:
+  - patchData: |
+      {
+        "spec": {
+          "containers": [
+            {
+              "name": "nginx",
+              "image": "repo2/nginx"
+            }
+          ]
+        }
+      }
+```
+- The above configmap will apply the Strategic Merge Patch to the pod with name my-pod in namespace ns1 and update the image of container nginx to `repo2/nginx`.
+- Both json and yaml format are supported for the patchData.
+
+### Conditional Patches in ALL Patch Types
+Since JSON Merge Patch and Strategic Merge Patch do not support conditional patches, we will use the `test` operation of JSON Patch to support conditional patches in all patch types by adding it to `Conditions` struct in `ResourceModifierRule`.
+
+Example of test in conditions
+```yaml
+version: v1
+resourceModifierRules:
+- conditions:
+    groupResource: persistentvolumeclaims.storage.k8s.io
+    matches:
+    - path: "/spec/storageClassName"
+      value: "premium"
+  mergePatches:
+  - patchData: |
+      {
+        "metadata": {
+          "annotations": {
+            "foo": null
+          }
+        }
+      }
+```
+- The above configmap will apply the Merge Patch to all the PVCs in all namespaces with storageClassName premium and remove the annotation `foo` from the PVCs.
+- You can specify multiple rules in the `matches` list. The patch will be applied only if all the matches are satisfied.
+
+### Wildcard Support for GroupResource
+The user can specify a wildcard for groupResource in the conditions' struct. This will allow the user to apply the patches for all the resources of a particular group or all resources in all groups. For example, `*.apps` will apply to all the resources in the `apps` group, `*` will apply to all the resources in all groups.
+
+### Helper Command to Generate Merge Patch and Strategic Merge Patch
+The patchData of Strategic Merge Patch is sometimes a bit complex for user to write. We can provide a helper command to generate the patchData for Strategic Merge Patch. The command will take the original resource and the modified resource as input and generate the patchData.
+It can also be used in JSON Merge Patch.
+
+Here is a sample code snippet to achieve this:
+```go
+package main
+
+import (
+	"fmt"
+
+	corev1 "k8s.io/api/core/v1"
+	"sigs.k8s.io/controller-runtime/pkg/client"
+)
+
+func main() {
+	pod := &corev1.Pod{
+		Spec: corev1.PodSpec{
+			Containers: []corev1.Container{
+				{
+					Name:  "web",
+					Image: "nginx",
+				},
+			},
+		},
+	}
+	newPod := pod.DeepCopy()
+	patch := client.StrategicMergeFrom(pod)
+	newPod.Spec.Containers[0].Image = "nginx1"
+
+	data, _ := patch.Data(newPod)
+	fmt.Println(string(data))
+	// Output:
+	// {"spec":{"$setElementOrder/containers":[{"name":"web"}],"containers":[{"image":"nginx1","name":"web"}]}}
+}
+```
+
+## Security Considerations
+No security impact.
+
+## Compatibility
+Compatible with current Resource Modifiers.
+
+## Implementation
+- Use "github.com/evanphx/json-patch" to support JSON Merge Patch.
+- Use "k8s.io/apimachinery/pkg/util/strategicpatch" to support Strategic Merge Patch.
+- Use glob to support wildcard for `groupResource` in `conditions` struct.
+- Use `test` operation of JSON Patch to calculate the `matches` in `conditions` struct.
+
+## Future enhancements
+- add a Velero subcommand to generate/validate the patchData for Strategic Merge Patch and JSON Merge Patch.
+- add jq support for more complex conditions or patches, to meet the situations that the current conditions or patches can not handle. like [this issue](https://github.com/vmware-tanzu/velero/issues/6344)
+
+## Open Issues
+N/A

design/secrets.md

@@ -160,10 +160,10 @@ while the cloud credential will always be used for the VolumeSnapshotter.
 
 ## Velero Plugin for vSphere compatibility
 
-The vSphere plugin is implemented as a BackupItemAction and shares the credentials of the AWS plug-in for S3 access.
+The vSphere plugin is implemented as a BackupItemAction and shares the credentials of the AWS plugin for S3 access.
 The backup storage location is passed in _Backup.Spec.StorageLocation_.  Currently the plugin retrieves the S3 bucket and
 server from the BSL and creates a BackupRespositoryClaim with that and the credentials retrieved from the cloud credential.
-The plug-in will need to be modified to retrieve the credentials field from the BSL and use that credential in the
+The plugin will need to be modified to retrieve the credentials field from the BSL and use that credential in the
 BackupRepositoryClaim.
 
 ## Backwards compatibility
@@ -185,7 +185,7 @@ In order to support parallelism, Velero will need to be able to use multiple cre
 ObjectStore.  Currently backups are single threaded and a single BSL will be used throughout the entire backup.  The only
 existing points of parallelism are when a user downloads logs for a backup or the BackupStorageLocationReconciler 
 reconciles while a backup or restore is running.  In the current code, `download_request_controller.go` and 
-`backup_storage_location_controller.go` create a new plug-in manager and hence another ObjectStore plugin in 
+`backup_storage_location_controller.go` create a new plugin manager and hence another ObjectStore plugin in 
 parallel with the ObjectStore plugin servicing a backup or restore (if one is running).
 
 ## Alternatives Considered

design/upload-progress.md

@@ -1,8 +1,8 @@
 # Upload Progress Monitoring
 
-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
@@ -23,7 +23,7 @@ Restic - Does not go through the volume snapshot path.  Restic backups will bloc
 
 - Enable monitoring of operations that continue after snapshotting operations have completed
 - Keep non-usable backups (upload/persistence has not finished) from appearing as completed
-- Minimize change to volume snapshot and BackupItemAction plug-ins
+- Minimize change to volume snapshot and BackupItemAction plugins
 
 ## Non-goals
 - Unification of BackupItemActions and VolumeSnapshotters
@@ -32,7 +32,7 @@ Restic - Does not go through the volume snapshot path.  Restic backups will bloc
 
 ### 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
@@ -56,7 +56,7 @@ slow the progress of the system without adding any actual benefit to the user.
 A new backup phase, "Uploading" will be introduced.  When a backup has entered this phase, Velero
 is free to start another backup.  The backup will remain in the "Uploading" phase until all data
 has been successfully moved to persistent storage.  The backup will not fail once it reaches
-this phase, it will continuously retry moving the data.  If the backup is deleted (cancelled), the plug-ins will
+this phase, it will continuously retry moving the data.  If the backup is deleted (cancelled), the plugins will
 attempt to delete the snapshots and stop the data movement - this may not be possible with all
 storage systems.
 
@@ -74,7 +74,7 @@ If the backup request is incorrectly formed, it goes to the "FailedValidation" p
 ### InProgress
 When work on the backup 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 info is safely written to the object store plug-in.
+Kubernetes metadata and backup info is safely written to the object store 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
@@ -89,7 +89,7 @@ will be deleted and at that point any uploads still in progress should be aborte
 
 ### Uploading (new)
 The "Uploading" phase signifies that the main part of the backup, including snapshotting has completed successfully
-and and uploading is continuing.  In the event of an error during uploading, the phase will change to 
+and uploading is continuing.  In the event of an error during uploading, the phase will change to 
 UploadingPartialFailure.  On success, the phase changes to Completed.  The backup cannot be
 restored from when it is in the Uploading state.
 
@@ -146,7 +146,7 @@ Completed, Failed or PartialFailure
 InProgress backups will not have a `velero-backup.json` present in the object store.  During 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
 
 ### UploadProgress struct
 
@@ -166,23 +166,23 @@ do not have a `velero-backup.json` object in the object store will be ignored.
 
 ### VolumeSnapshotter changes
 
-A new method will be added to the VolumeSnapshotter interface (details depending on plug-in versioning spec)
+A new method will be added to the VolumeSnapshotter interface (details depending on plugin versioning spec)
 
     UploadProgress(snapshotID string) (UploadProgress, error)
 
 UploadProgress 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 snapshotID continues to be valid it should be possible to
+has been taken.  In the event a plugin is restarted, if the snapshotID 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 return in UploadProgress and error should be nil.
 
-### SnapshotItemAction plug-in
+### SnapshotItemAction plugin
 
-Currently CSI snapshots and the Velero Plug-in for vSphere are implemented as BackupItemAction plugins.  The majority of
+Currently CSI snapshots and the Velero Plugin for vSphere are implemented as BackupItemAction plugins.  The majority of
 BackupItemAction plugins do not take snapshots or upload data so rather than modify BackupItemAction we introduce a new
-plug-ins, SnapshotItemAction.  SnapshotItemAction will be used in place of BackupItemAction for
-the CSI snapshots and the Velero Plug-in for vSphere and will return a snapshot ID in addition to the item itself.
+plugins, SnapshotItemAction.  SnapshotItemAction will be used in place of BackupItemAction for
+the CSI snapshots and the Velero Plugin for vSphere and will return a snapshot ID in addition to the item itself.
 
 The SnapshotItemAction plugin identifier as well as the Item and Snapshot ID will be stored in the 
 `<backup-name>-itemsnapshots.json.gz`.  When checking for progress, this info will be used to select the appropriate
@@ -248,9 +248,9 @@ stable storage.  CSI snapshots expose the _readyToUse_ state that, in the case o
 has been transferred to durable storage and is ready to be used.  The CSI BackupItemProgress.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,
+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
@@ -281,13 +281,13 @@ VolumeSnapshotter new plugin APIs
 BackupItemProgress new plugin interface  
 New backup phases  
 Defer uploading `velero-backup.json`  
-AWS EBS plug-in UploadProgress implementation  
+AWS EBS plugin UploadProgress implementation  
 Upload monitoring  
 Implementation of `<backup-name>-itemsnapshots.json.gz` file  
 Restart logic  
 Change in reconciliation logic to ignore backups that have not completed  
-CSI plug-in BackupItemProgress implementation  
-vSphere plug-in BackupItemProgress implementation (vSphere plug-in team)  
+CSI plugin BackupItemProgress implementation  
+vSphere plugin BackupItemProgress implementation (vSphere plugin team)  
 
 # Future Fragile/Durable snapshot tracking
 Futures are here for reference, they may change radically when actually implemented.
@@ -296,11 +296,11 @@ Some storage systems have the ability to provide different levels of protection
 and "Durable".  Currently, Velero expects snapshots to be Durable (they should be able to survive the destruction of the
 cluster and the storage it is using).  In the future we would like the ability to take advantage of snapshots that are
 Fragile.  For example, vSphere snapshots are Fragile (they reside in the same datastore as the virtual disk).  The Velero
-Plug-in for vSphere uses a vSphere local/fragile snapshot to get a consistent snapshot, then uploads the data to S3 to
+Plugin for vSphere uses a vSphere local/fragile snapshot to get a consistent snapshot, then uploads the data to S3 to
 make it Durable.  In the current design, upload progress will not be complete until the snapshot is ready to use and
 Durable.  It is possible, however, to restore data from a vSphere snapshot before it has been made Durable, and this is a
 capability we'd like to expose in the future.  Other storage systems implement this functionality as well.  We will be moving
-the control of the data movement from the vSphere plug-in into Velero.
+the control of the data movement from the vSphere plugin into Velero.
 
 Some storage system, such as EBS, are only capable of creating Durable snapshots.  There is no usable intermediate Fragile stage.
 

design/volume-snapshot-data-movement/volume-snapshot-data-movement.md

@@ -0,0 +1,970 @@
+# Volume Snapshot Data Movement Design
+
+## Glossary & Abbreviation
+
+**BR**: Backup & Restore  
+**Backup Storage**: See the same definition in [Unified Repository design][1].  
+**Backup Repository**: See the same definition in [Unified Repository design][1].  
+**BIA/RIA V2**: Backup Item Action/Restore Item Action V2 that supports asynchronized operations, see the [general progress monitoring design][2] for details.  
+
+## Background
+
+As a Kubernetes BR solution, Velero is pursuing the capability to back up data from the volatile and limited production environment into the durable, heterogeneous and scalable backup storage. This relies on two parts:  
+
+- Data Movement: Move data from various production workloads, including the snapshots of the workloads or volumes of the workloads
+- Data Persistency and Management: Persistent the data in backup storage and manage its security, redundancy, accessibility, etc. through backup repository. This has been covered by the [Unified Repository design][1]
+
+At present, Velero supports moving file system data from PVs through Pod Volume Backup (a.k.a. file system backup). However, it backs up the data from the live file system, so it should be the last option when more consistent data movement (i.e., moving data from snapshot) is not available.  
+
+Moreover, we would like to create a general workflow to variations during the data movement, e.g., data movement plugins, different snapshot types, different snapshot accesses and different data accesses. 
+
+## Goals
+
+- Create components and workflows for Velero to move data based on volume snapshots
+- Create components and workflows for Velero built-in data mover
+- Create the mechanism to support data mover plugins from third parties
+- Implement CSI snapshot data movement on file system level
+- Support different data accesses, i.e., file system level and block level
+- Support different snapshot types, i.e., CSI snapshot, volume snapshot API from storage vendors
+- Support different snapshot accesses, i.e., through PV generated from snapshots, and through direct access API from storage vendors
+- Reuse the existing Velero generic data path as creatd in [Unified Repository design][1]
+
+## Non-Goals
+
+- The current support for block level access is through file system uploader, so it is not aimed to deliver features of an ultimate block level backup. Block level backup will be included in a future design
+- Most of the components are generic, but the Exposer is snapshot type specific or snapshot access specific. The current design covers the implementation details for exposing CSI snapshot to host path access only, for other types or accesses, we may need a separate design
+- The current workflow focuses on snapshot-based data movements. For some application/SaaS level data sources, snapshots may not be taken explicitly. We don’t take them into consideration, though we believe that some workflows or components may still be reusable.
+
+## Architecture of Volume Snapshot Data Movement
+
+## Workflows  
+
+Here are the diagrams that illustrate components and workflows for backup and restore respectively.  
+For backup, we intend to create an extensive architecture for various snapshot types, snapshot accesses and various data accesses. For example, the snapshot specific operations are isolated in Data Mover Plugin and Exposer. In this way, we only need to change the two modules for variations. Likely, the data access details are isolated into uploaders, so different uploaders could be plugged into the workflow seamlessly.  
+
+For restore, we intend to create a generic workflow that could for all backups. This means the restore is backup source independent. Therefore, for example, we can restore a CSI snapshot backup to another cluster with no CSI facilities or with CSI facilities different from the source cluster.  
+We still have the Exposer module for restore and it is to expose the target volume to the data path. Therefore, we still have the flexibility to introduce different ways to expose the target volume.  
+Likely, the data downloading details are isolated in uploaders, so we can still create multiple types of uploaders.  
+
+Below is the backup workflow:  
+![backup-workflow.png](backup-workflow.png)  
+
+Below is the restore workflow:  
+![restore-workflow.png](restore-workflow.png)  
+
+## Components
+Below are the generic components in the data movement workflow:  
+
+**Velero**: Velero controls the backup/restore workflow, it calls BIA/RIA V2 to backup/restore an object that involves data movement, specifically, a PVC or a PV.  
+**BIA/RIA V2**: BIA/RIA V2 are the protocols between Velero and the data mover plugins. They support asynchronized operations so that Velero backup/restore is not marked as completion until the data movement is done and in the meantime, Velero is free to process other backups during the data movement.  
+**Data Mover Plugin (DMP)**: DMP implement BIA/RIA V2 and it invokes the corresponding data mover by creating the DataUpload/DataDownload CRs. DMP is also responsible to take snapshot of the source volume, so it is a snapshot type specific module. For CSI snapshot data movement, the CSI plugin could be extended as a DMP, this also means that the CSI plugin will fully implement BIA/RIA V2 and support some more methods like Progress, Cancel, etc.  
+**DataUpload CR (DUCR)/ DataDownload CR (DDCR)**: DUCR/DDCR are Kubernetes CRs that act as the protocol between data mover plugins and data movers. The parties who want to provide a data mover need to watch and process these CRs.  
+**Data Mover (DM)**: DM is a collective of modules to finish the data movement, specifically, data upload and data download. The modules may include the data mover controllers to reconcile DUCR/DDCR and the data path to transfer data.  
+
+DMs take the responsibility to handle DUCR/DDCRs, Velero provides a built-in DM and meanwhile Velero supports plugin DMs. Below shows the components for the built-in DM:  
+
+**Velero Built-in Data Mover (VBDM)**: VBDM is the built-in data mover shipped along with Velero, it includes Velero data mover controllers and Velero generic data path.  
+**Node-Agent**: Node-Agent is an existing Velero module that will be used to host VBDM.  
+**Exposer**: Exposer is to expose the snapshot/target volume as a path/device name/endpoint that are recognizable by Velero generic data path. For different snapshot types/snapshot accesses, the Exposer may be different. This isolation guarantees that when we want to support other snapshot types/snapshot accesses, we only need to replace with a new Exposer and keep other components as is.  
+**Velero Generic Data Path (VGDP)**: VGDP is the collective of modules that is introduced in [Unified Repository design][1]. Velero uses these modules to finish data transmission for various purposes. In includes uploaders and the backup repository.  
+**Uploader**: Uploader is the module in VGDP that reads data from the source and writes to backup repository for backup; while read data from backup repository and write to the restore target for restore. At present, only file system uploader is supported. In future, the block level uploader will be added. For file system and basic block uploader, only Kopia uploader will be used, Restic will not be integrated with VBDM.   
+
+## Replacement
+3rd parties could integrate their own data movement into Velero by replacing VBDM with their own DMs. The DMs should process DUCR/DDCRs appropriately and finally put them into one of the terminal states as shown in the DataUpload CRD and DataDownload CRD sections.  
+Theoretically, replacing the DMP is also allowed. In this way, the entire workflow is customized, so this is out of the scope of this design.  
+
+# Detailed Design
+
+## Backup Sequence
+Below are the data movement actions and sequences during backup:  
+![backup-sequence.png](backup-sequence.png) 
+
+Below are actions from Velero and DMP:
+
+**BIA Execute**  
+This is the existing logic in Velero. For a source PVC/PV, Velero delivers it to the corresponding BackupItemAction plugin, the plugin then takes the related actions to back it up.
+For example, the existing CSI plugin takes a CSI snapshot to the volume represented by the PVC and then returns additional items (i.e., VolumeSnapshot, VolumeSnapshotContent and VolumeSnapshotClass) for Velero to further backup.
+To support data movement, we will use BIA V2 which supports asynchronized operation management. Here is the Execute method from BIA V2:  
+```
+Execute(item runtime.Unstructured, backup *api.Backup) (runtime.Unstructured, []velero.ResourceIdentifier, string, []velero.ResourceIdentifier, error)
+```
+Besides ```additionalItem``` (as the 2nd return value), Execute method will return one more resource list called ```itemToUpdate```, which means the items to be updated  and persisted when the async operation completes. For details, visit [general progress monitoring design][2].   
+Specifically, this mechanism will be used to persist DUCR into the persisted backup data, in another words, DUCR will be returned as ```itemToUpdate``` from Execute method. DUCR contains all the information the restore requires, so during restore, DUCR will be extracted from the backup data.  
+Additionally, in the same way, a DMP could add any other items into the persisted backup data.  
+Execute method also returns the ```operationID``` which uniquely identifies the asynchronized operation. This ```operationID``` is generated by plugins. The [general progress monitoring design][2] doesn't restrict the format of the ```operationID```, for Velero CSI plugin, the ```operationID``` is a combination of the backup CR UID and the source PVC (represented by the ```item``` parameter) UID.  
+
+**Create Snapshot**  
+The DMP creates a snapshot of the requested volume and deliver it to DM through DUCR. After that, the DMP leaves the snapshot and its related objects (e.g., VolumeSnapshot and VolumeSnapshotContent for CSI snapshot) to the DM, DM then has full control of the snapshot and its related objects, i.e., deciding whether to delete the snapshot or its related objects and when to do it.  
+This also indicates that the DUCR should contain the snapshot type specific information because different snapshot types may have their unique information.  
+For Velero built-in implementation, the existing logics to create the snapshots will be reused, specifically, for CSI snapshot, the related logics in CSI plugin are fully reused.  
+
+**Create DataUpload CR**  
+A DUCR is created for as the result of each Execute call, then Execute method will return and leave DUCR being processed asynchronously.  
+
+**Set Backup As WaitForAsyncOperations**  
+**Persist Backup**  
+After ```Execute``` returns, the backup is set to ```WaitingForPluginOperations```, and then Velero is free to process other items or backups.  
+Before Velero moves to other items/backups, it will persist the backup data. This is the same as the existing behavior.  
+The backup then is left as ```WaitForAsyncOperations``` until the DM completes or timeout.  
+
+**BIA Progress**  
+Velero keeps monitoring the status of the backup by calling BIA V2’s Progress method. Below is the Progress method from BIA V2:
+```
+Progress(operationID string, backup *api.Backup) (velero.OperationProgress, error)
+```
+On the call of this method, DMP will query the DUCR’s status. Some critical progress data is transferred from DUCR to the ```OperationProgress``` which is the return value of BIA V2’s Progress method. For example, NCompleted indicates the size/number of data that have been completed and NTotal indicates the total size/number of data.  
+When the async operation completes, the Progress method returns an OperationProgress with ```Completed``` set as true. Then Velero will persist DUCR as well as any other items returned by DUP as ```itemToUpdate```.  
+Finally, then backup is as ```Completed```.  
+To help BIA Progress find the corresponding DUCR, the ```operationID``` is saved along with the DUCR as a label ```velero.io/async-operation-id```.
+
+DUCRs are handled by the data movers, so how to handle them are totally decided by the data movers. Below covers the details of VBDM, plugging data movers should have their own actions and workflows.  
+
+**Persist DataUpload CR**  
+As mentioned above, the DUCR will be persisted when it is completed under the help of BIA V2 async operation finalizing mechanism.   
+This means the backup tarball will be uploaded twice, this is as the designed behavior of [general progress monitoring design][2].  
+
+Conclusively, as a result of the above executions:
+- A DataUpload CR is created and persisted to the backup tarball. The CR will be left there after the backup completes because the CR includes many information connecting to the backup that may be useful to end users or upper level modules.  
+- A snapshot as well as the objects representing it are created. For CSI snapshot, a VolumeSnapshot object and a VolumeSnapshotContent object is created. The DMP leaves the snapshot as well as its related objects to DM for further processing.  
+
+VBDM creates a Data Uploader Controller to handle the DUCRs in node-agent daemonset, therefore, on each node, there will be an instance of this controller. The controller connects to the backup repository and calls the uploader. Below are the VBDM actions.  
+
+**Acquire Object Lock**  
+**Release Object Lock**  
+There are multiple instances of Data Uploader Controllers and when a DUCR is created, there should be only one of the instances handle the CR.  
+Therefore, an operation called “Acquired Object Lock” is used to reach a consensus among the controller instances so that only one controller instance takes over the CR and tries the next action – Expose for the CR.  
+After the CR is completed in the Expose phase, the CR is released with the operation of “Release Object Lock”.  
+We fulfil the “Acquired Object Lock” and “Release Object Lock” under the help of Kubernetes API server and the etcd in the background, which guarantees strong write consistency among all the nodes.  
+
+**Expose**  
+For some kinds of snapshot, it may not be usable directly after it is taken. For example, a CSI snapshot is represented by the VolumeSnapshot and VolumeSnapshotContent object, if we don’t do anything, we don’t see any PV really exists in the cluster, so VGDP has no way to access it. Meanwhile, when we have a PV representing the snapshot data, we still need a way to make it accessible by the VGDP.  
+The details of the expose process are snapshot specific, and for one kind of snapshot, we may have different methods to expose it to VGDP. Later, we will have a specific section to explain the current design of the Exposer.  
+
+**Backup From Data Path**  
+After a snapshot is exposed, VGDP will be able to access the snapshot data, so the controller calls the uploader to start the data backup.  
+To support cancellation and concurrent backup, the call to the VGDP is done asynchronously. How this asynchronization is implemented may be related to the Exposer. as the current design of Exposer, the asynchronization is implemented by the controller with go routines.    
+
+We keep VGDP reused for VBDM, so everything inside VGDP are kept as is. For details of VGDP, refer to the [Unified Repository design][1].  
+
+**Update Repo Snapshot ID**
+When VGDP completes backup, it returns an ID that represent the root object saved into the backup repository for this backup, through the root object, we will be able to enumerate the entire backup data.  
+This Repo Snapshot ID will be saved along with the DUCR.  
+
+## DataUpload CRD
+Below are the essential fields of DataUpload CRD. The CRD covers below information:
+- The information to manipulate the specified snapshot
+- The information to manipulate the specified data mover
+- The information to manipulate the specified backup repository
+- The progress of the current data upload
+- The result of the current data upload once it finishes
+
+For snapshot manipulation:
+- ```snapshotType``` indicates the type of the snapshot, at present, the only valid value is ```CSI```.  
+- If ```snapshotType``` is ```CSI```, ```csiSnapshot``` which is a pointer to a ```CSISnapshotSpec``` must not be absent. 
+- ```CSISnapshotSpec``` specifies the information of the CSI snapshot, e.g., ```volumeSnapshot``` is the name of VolumeSnapshot object representing the CSI snapshot; ```storageClass``` specifies the name of the StorageClass of the source PVC, which will be used to create the backupPVC during the data upload.
+
+For data mover manipulation:
+- ```datamover``` indicates the name of the data mover, if it is empty or ```velero```, it means the built-in data mover will be used for this data upload  
+
+For backup repository manipulation, ```backupStorageLocation``` is the name of the related BackupStorageLocation, where we can find all the required information.
+
+For the progress, it includes the ```totalBytes``` and ```doneBytes``` so that other modules could easily cuclulate a progress.  
+
+For data upload result, ```snapshotID``` in the ```status``` field is the Repo Snapshot ID. Data movers may have their private outputs as a result of the DataUpload, they will be put in the ```dataMoverResult``` map of the ```status``` field.  
+
+Here are the statuses of DataUpload CRD and their descriptions:
+- New: The DUCR has been created but not processed by a controller
+- Accepted: the Object lock has been acquired for this DUCR and the elected controller is trying to expose the snapshot
+- Prepared: the snapshot has been exposed, the related controller is starting to process the upload
+- InProgress: the data upload is in progress
+- Canceling: the data upload is being canceled
+- Canceled: the data upload has been canceled
+- Completed: the data upload has completed
+- Failed: the data upload has failed
+
+Below is the full spec of DataUpload CRD:
+```
+apiVersion: apiextensions.k8s.io/v1alpha1
+kind: CustomResourceDefinition
+metadata:
+  labels:
+    component: velero
+  name: datauploads.velero.io
+spec:
+  conversion:
+    strategy: None
+  group: velero.io
+  names:
+    kind: DataUpload
+    listKind: DataUploadList
+    plural: datauploads
+    singular: dataupload
+  scope: Namespaced
+  versions:
+  - additionalPrinterColumns:
+    - description: DataUpload status such as New/InProgress
+      jsonPath: .status.phase
+      name: Status
+      type: string
+    - description: Time duration since this DataUpload was started
+      jsonPath: .status.startTimestamp
+      name: Started
+      type: date
+    - description: Completed bytes
+      format: int64
+      jsonPath: .status.progress.bytesDone
+      name: Bytes Done
+      type: integer
+    - description: Total bytes
+      format: int64
+      jsonPath: .status.progress.totalBytes
+      name: Total Bytes
+      type: integer
+    - description: Name of the Backup Storage Location where this backup should be
+        stored
+      jsonPath: .spec.backupStorageLocation
+      name: Storage Location
+      type: string
+    - description: Time duration since this DataUpload was created
+      jsonPath: .metadata.creationTimestamp
+      name: Age
+      type: date
+    name: v1
+    schema:
+      openAPIV3Schema:
+        properties:
+          spec:
+            description: DataUploadSpec is the specification for a DataUpload.
+            properties:
+              backupStorageLocation:
+                description: BackupStorageLocation is the name of the backup storage
+                  location where the backup repository is stored.
+                type: string
+              csiSnapshot:
+                description: If SnapshotType is CSI, CSISnapshot provides the information
+                  of the CSI snapshot.
+                properties:
+                  snapshotClass:
+                    description: SnapshotClass is the name of the snapshot class that
+                      the volume snapshot is created with
+                    type: string                
+                  storageClass:
+                    description: StorageClass is the name of the storage class of
+                      the PVC that the volume snapshot is created from
+                    type: string
+                  volumeSnapshot:
+                    description: VolumeSnapshot is the name of the volume snapshot
+                      to be backed up
+                    type: string
+                required:
+                - storageClass
+                - volumeSnapshot
+                type: object
+              datamover:
+                description: DataMover specifies the data mover to be used by the
+                  backup. If DataMover is "" or "velero", the built-in data mover
+                  will be used.
+                type: string
+			  operationTimeout:
+                description: OperationTimeout specifies the time used to wait internal 
+                  operations, e.g., wait the CSI snapshot to become readyToUse.
+                type: string
+              snapshotType:
+                description: SnapshotType is the type of the snapshot to be backed
+                  up.
+                type: string
+              sourceNamespace:
+                description: SourceNamespace is the original namespace where the volume
+                  is backed up from.
+                type: string
+            required:
+            - backupStorageLocation
+            - csiSnapshot
+            - snapshotType
+            - sourceNamespace
+            type: object
+          status:
+            description: DataUploadStatus is the current status of a DataUpload.
+            properties:
+              completionTimestamp:
+                description: CompletionTimestamp records the time a backup was completed.
+                  Completion time is recorded even on failed backups. Completion time
+                  is recorded before uploading the backup object. The server's time
+                  is used for CompletionTimestamps
+                format: date-time
+                nullable: true
+                type: string
+              dataMoverResult:
+                additionalProperties:
+                  type: string
+                description: DataMoverResult stores data-mover-specific information
+                  as a result of the DataUpload.
+                nullable: true
+                type: object
+              message:
+                description: Message is a message about the DataUpload's status.
+                type: string
+			  node:
+                description: Node is the name of the node where the DataUpload is running.
+                type: string			    
+              path:
+                description: Path is the full path of the snapshot volume being backed
+                  up.
+                type: string
+              phase:
+                description: Phase is the current state of the DataUpload.
+                enum:
+                - New
+                - Accepted
+                - Prepared
+                - InProgress
+                - Canceling
+                - Canceled
+                - Completed
+                - Failed
+                type: string
+              progress:
+                description: Progress holds the total number of bytes of the volume
+                  and the current number of backed up bytes. This can be used to display
+                  progress information about the backup operation.
+                properties:
+                  bytesDone:
+                    format: int64
+                    type: integer
+                  totalBytes:
+                    format: int64
+                    type: integer
+                type: object
+              snapshotID:
+                description: SnapshotID is the identifier for the snapshot in the
+                  backup repository.
+                type: string
+              startTimestamp:
+                description: StartTimestamp records the time a backup was started.
+                  Separate from CreationTimestamp, since that value changes on restores.
+                  The server's time is used for StartTimestamps
+                format: date-time
+                nullable: true
+                type: string
+            type: object
+        type: object
+
+```
+
+## Restore Sequence
+
+Below are the data movement actions sequences during restore:  
+![restore-sequence.png](restore-sequence.png) 
+
+Many of the actions are the same with backup, here are the different ones.    
+
+**Query Backup Result**  
+The essential information to be filled into DataDownload all comes from the DataUpload CR. For example, the Repo Snapshot ID is stored in the status fields of DataUpload CR. However, we don't want to restore the DataUpload CR and leave it in the cluster since it is useless after the restore. Therefore, we will retrieve the necessary information from DataUpload CR and store it in a temporary ConfigMap for the DM to use. There is one ConfigMap for each DataDownload CR and the ConfigMaps belong to a restore will be deleted when the restore finishes.  
+
+**Prepare Volume Readiness**  
+As the current pattern, Velero delivers an object representing a volume, either a PVC or a PV, to DMP and Velero will create the object after DMP's Execute call returns. However, by this time, DM should have not finished the restore, so the volume is not ready for use.  
+In this step, DMP needs to mark the object as unready to use so as to prevent others from using it, i.e., a pod mounts the volume. Additionlly, DMP needs to provide an approach for DM to mark it as ready when the data movement finishes.  
+How to mark the volume as unready or ready varying from the type of the object, specifically, a PVC or a PV; and there are more than one ways to achieve this.  
+Below show the details of how to do this for CSI snapshot data movement.  
+After the DMP submits the DataDownload CR, it does below modifications to the PVC spec:
+- Set spec.VolumeName to empty ("")
+- Add a selector with a matchLabel ```velero.io/dynamic-pv-restore```
+
+With these two steps, it tells Kubernetes that the PVC is not bound and it only binds a PV with the ```velero.io/dynamic-pv-restore``` label. As a result, even after the PVC object is created by Velero later and is used by other resources, it is not usable until the DM creates the target PV.      
+
+**Expose**  
+The purpose of expose process for restore is to create the target PV and make the PV accessible by VGDP. Later the Expose section will cover the details. 
+
+**Finish Volume Readiness**  
+By the data restore finishes, the target PV is ready for use but it is not delivered to the outside world. This step is the follow up of Prepare Volume Readiness, which does necessary work to mark the volume ready to use.  
+For CSI snapshot restore, DM does below steps:
+- Set the target PV's claim reference (the ```claimRef``` filed) to the target PVC
+- Add the ```velero.io/dynamic-pv-restore``` label to the target PV
+
+By the meantime, the target PVC should have been created in the source user namespace and waiting for binding.  
+When the above steps are done, the target PVC will be bound immediately by Kubernetes.  
+This also means that Velero should not restore the PV if a data movement restore is involved, this follows the existing CSI snapshot behavior.  
+
+For restore, VBDM doesn’t need to persist anything.  
+
+## DataDownload CRD
+Below are the essential fields of DataDownload CRD. The CRD covers below information:
+- The information to manipulate the target volume
+- The information to manipulate the specified data mover
+- The information to manipulate the specified backup repository
+
+Target volume information includes PVC and PV that represents the volume and the target namespace.        
+The data mover information and backup repository information are the same with DataUpload CRD.
+DataDownload CRD defines the same status as DataUpload CRD with nearly the same meanings.  
+
+Below is the full spec of DataUpload CRD:
+```
+apiVersion: apiextensions.k8s.io/v1alpha1
+kind: CustomResourceDefinition
+metadata:
+  labels:
+    component: velero
+  name: datadownloads.velero.io
+spec:
+  conversion:
+    strategy: None
+  group: velero.io
+  names:
+    kind: DataDownload
+    listKind: DataDownloadList
+    plural: datadownloads
+    singular: datadownload
+  scope: Namespaced
+  versions:
+  - DataDownload:
+    - description: DataDownload status such as New/InProgress
+      jsonPath: .status.phase
+      name: Status
+      type: string
+    - description: Time duration since this DataDownload was started
+      jsonPath: .status.startTimestamp
+      name: Started
+      type: date
+    - description: Completed bytes
+      format: int64
+      jsonPath: .status.progress.bytesDone
+      name: Bytes Done
+      type: integer
+    - description: Total bytes
+      format: int64
+      jsonPath: .status.progress.totalBytes
+      name: Total Bytes
+      type: integer
+    - description: Time duration since this DataDownload was created
+      jsonPath: .metadata.creationTimestamp
+      name: Age
+      type: date
+    name: v1
+    schema:
+      openAPIV3Schema:
+        properties:
+          spec:
+            description: SnapshotDownloadSpec is the specification for a SnapshotDownload.
+            properties:
+              backupStorageLocation:
+                description: BackupStorageLocation is the name of the backup storage
+                  location where the backup repository is stored.
+                type: string
+              datamover:
+                description: DataMover specifies the data mover to be used by the
+                  backup. If DataMover is "" or "velero", the built-in data mover
+                  will be used.
+                type: string
+              operationTimeout:
+                description: OperationTimeout specifies the time used to wait internal
+                  operations, before returning error as timeout.
+                type: string
+              snapshotID:
+                description: SnapshotID is the ID of the Velero backup snapshot to
+                  be restored from.
+                type: string
+              sourceNamespace:
+                description: SourceNamespace is the original namespace where the volume
+                  is backed up from.
+                type: string
+              targetVolume:
+                description: TargetVolume is the information of the target PVC and
+                  PV.
+                properties:
+                  namespace:
+                    description: Namespace is the target namespace
+                    type: string
+                  pv:
+                    description: PV is the name of the target PV that is created by
+                      Velero restore
+                    type: string
+                  pvc:
+                    description: PVC is the name of the target PVC that is created
+                      by Velero restore
+                    type: string
+                required:
+                - namespace
+                - pv
+                - pvc
+                type: object
+            required:
+            - backupStorageLocation
+            - restoreName
+            - snapshotID
+            - sourceNamespace
+            - targetVolume
+            type: object
+          status:
+            description: SnapshotRestoreStatus is the current status of a SnapshotRestore.
+            properties:
+              completionTimestamp:
+                description: CompletionTimestamp records the time a restore was completed.
+                  Completion time is recorded even on failed restores. The server's
+                  time is used for CompletionTimestamps
+                format: date-time
+                nullable: true
+                type: string
+              message:
+                description: Message is a message about the snapshot restore's status.
+                type: string
+			  node:
+                description: Node is the name of the node where the DataDownload is running.
+                type: string				
+              phase:
+                description: Phase is the current state of theSnapshotRestore.
+                enum:
+                - New
+                - Accepted
+                - Prepared
+                - InProgress
+                - Canceling
+                - Canceled
+                - Completed
+                - Failed
+                type: string
+              progress:
+                description: Progress holds the total number of bytes of the snapshot
+                  and the current number of restored bytes. This can be used to display
+                  progress information about the restore operation.
+                properties:
+                  bytesDone:
+                    format: int64
+                    type: integer
+                  totalBytes:
+                    format: int64
+                    type: integer
+                type: object
+              startTimestamp:
+                description: StartTimestamp records the time a restore was started.
+                  The server's time is used for StartTimestamps
+                format: date-time
+                nullable: true
+                type: string
+            type: object
+        type: object
+```  
+
+## Expose  
+
+### Expose for DataUpload  
+At present, for a file system backup, VGDP accepts a string representing the root path of the snapshot to be backed up, the path should be accessible from the process/pod that VGDP is running. In future, VGDP may accept different access parameters. Anyway, the snapshot should be accessible local.  
+Therefore, the first phase for Expose is to expose the snapshot to be locally accessed. This is a snapshot specific operation.  
+For CSI snapshot, the final target is to create below 3 objects in Velero namespace:  
+- backupVSC: This is the Volume Snapshot Content object represents the CSI snapshot
+- backupVS: This the Volume Snapshot object for BackupVSC in Velero namespace
+- backupPVC: This is the PVC created from the backupVS in Velero namespace. Specifically, backupPVC’s data source points to backupVS
+- backupPod: This is a pod attaching backupPVC in Velero namespace. As Kubernetes restriction, the PV is not provisioned until the PVC is attached to a pod and the pod is scheduled to a node. Therefore, after the backupPod is running, the backupPV which represents the data of the snapshot will be provisioned
+- backupPV: This is the PV provisioned as a result of backupPod schedule, it has the same data of the snapshot
+
+Initially, the CSI VS object is created in the source user namespace (we call it sourceVS), after the Expose, all the objects will be in Velero namespace, so all the data upload activities happen in the Velero namespace only.  
+As you can see, we have duplicated some objects (sourceVS and sourceVSC), this is due to Kubernetes restriction – the data source reference cannot across namespaces.  
+After the duplication completes, the objects related to the source user namespace will be deleted.  
+
+Below diagram shows the relationships of the objects:  
+![expose-objects.png](expose-objects.png) 
+
+After the first phase, we will see a backupPod attaching a backupPVC/backupPV which data is the same as the snapshot data. Then the second phase could start, this phase is related to the uploader.  
+For file system uploader, the target of this phase is to get a path that is accessible locally by the uploader. There are some alternatives:
+- Get the path in the backupPod, so that VGDP runs inside the backupPod
+- Get the path on the host, so that VGDP runs inside node-agent, this is similar to the existing PodVolumeBackup
+
+Each option has their pros and cons, in the current design, we will use the second way because it is simpler in implementation and more controllable in workflow.  
+
+### Expose for DataDownload
+The Expose operation for DataDownload still takes two phases, The first phase creates below objects:
+- restorePVC: It is a PVC in Velero namespace with the same specification, it is used to provision the restorePV
+- restorePod: It is used to attach the restorePVC so that the restorePV could be provisioned by Kubernetes
+- restorePV: It is provisioned by Kubernetes and bound to restorePVC
+
+Data will be downloaded to the restorePV. No object is created in user source namespace and no activity is done there either.  
+The second phase is the same as DataUpload, that is, we still use the host path to access restorePV and run VGDP in node-agent.  
+
+### Expose cleanup
+Some internal objects are created during the expose. Therefore, we need to clean them up to prevent internal objects from rampant growth. The cleanup happens in two cases:
+- When the controller finishes processing the DUCR/DDCR, this includes the cases that the DUCR/DDCR is completed, failed and cancelled.  
+- When the DM restarts and the DM doesn't support restart recovery. When the DM comes back, it should detect all the ongoing DUCR/DDCR and clean up the expose. Specifically, VBDM should follow this rule since it doesn't support restart recovery.  
+
+
+## Cancellation
+We will leverage on BIA/RIA V2's Cancel method to implement the cancellation, below are the prototypes from BIA/RIA V2:  
+```  
+Cancel(operationID string, backup *api.Backup) error  
+Cancel(operationID string, restore *api.Restore) error
+```  
+
+At present, Velero doesn’t support canceling an ongoing backup, the current version of BIA/RIA V2 framework has some problems to support the end to end cancellation as well.   
+Therefore, the current design doesn’t aim to deliver an end-to-end cancellation workflow but to implement the cancellation workflow inside the data movement, in future, when the other two parts are ready for cancellation, the data movement cancellation workflow could be directly used.  
+
+Additionally, at present, the data movement cancellation will be used in the below scenarios:  
+- When a backup is deleted, the backup deletion controller will call DMP’s Cancel method, so that the ongoing data movement will not run after the backup is deleted.
+- In the restart case, the ongoing backups will be marked as ```Failed``` when Velero restarts, at this time, DMP’s Cancel method will also be called when Velero server comes back because Velero will never process these backups.  
+
+For data movement implementation, a ```Cancel``` field is included in the DUCR/DDCR.
+DMP patches the DUCR/DDCR with ```Cancel``` field set to true, then it keeps querying the status of DUCR/DDCR until it comes to Canceled status or timeout, by which time, DMP returns the Cancel call to Velero.  
+Then DM needs to handle the cancel request, e.g., stop the data transition. For VBDM, it sets a signal to the uploader and the uploader will abort in a short time.  
+The cancelled DUCR/DDCR is marked as ```Canceled```.  
+
+Below diagram shows VBDM’s cancel workflow (take backup for example, restore is the same). 
+![cancel-sequence.png](cancel-sequence.png)    
+
+It is possible that a DM doesn’t support cancellation at all or only support in a specific phase (e.g., during InProgress phase), if the cancellation is requested at an unexpected time or to an unexpecting DM, the behavior is decided by the DMP and DM, below are some recommendations:
+- If a DM doesn't support cancellation at all, DMP should be aware of this, so the DMP could return an error and fail early
+- If the cancellation is requested at an unexpected time, DMP is possibly not aware of this, it could still deliver it to the DM, so both Velero and DMP wait there until DM completes the cancel request or timeout
+
+VBDM's cancellation exactly follows the above rules.  
+
+
+## Parallelism
+Velero uses BIA/RIA V2 to launch data movement tasks, so from Velero’s perspective, the DataUpload/DataDownload CRs from the running backups will be submitted in parallel.  
+Then how these CRs are handled is decided by data movers, in another words, the specific data mover decides whether to handle them sequentially or in parallel, as well what the parallelism is like. Velero makes no restriction to data movers regarding to this.  
+Next, let’s focus on the parallelism of VBDM, which could also be a reference of the plugin data movers.  
+VBDM is hosted by Velero node-agent, so there is one data movement controller instance on each Kubernetes node, which also means that these instances could handle the DataUpload/DataDownload CRs in parallel.  
+On the other hand, a volume/volume snapshot may be accessed from only one or multiple nodes varying from its location, the backend storage architecture, etc. Therefore, the first decisive factor of the parallelism is the accessibility of a volume/volume snapshot.  
+Therefore, we have below principles:
+- We should spread the data movement activities equally to all the nodes in the cluster. This requires a load balance design from Velero
+- In one node, it doesn’t mean the more concurrency the better, because the data movement activities are high in resource consumption, i.e., CPU, memory, and network throughput. For the same consideration, we should make this configurable because the best number should be set by users according to the bottleneck they detect  
+
+We will address the two principles step by step. As the first step, VBDM’s parallelism is designed as below:  
+- We don’t create the load balancing mechanism for the first step, we don’t detect the accessibility of the volume/volume snapshot explicitly. Instead, we create the backupPod/restorePod under the help of Kubernetes, Kubernetes schedules the backupPod/restorePod to the appropriate node, then the data movement controller on that node will handle the DataUpload/DataDownload CR there, so the resource will be consumed from that node.
+- We don’t expose the configurable concurrency value in one node, instead, the concurrency value in value will be set to 1, that is, there is no concurrency in one node.
+
+As for the resource consumption, it is related to the data scale of the data movement activity and it is charged to node-agent pods, so users should configure enough resource to node-agent pods.  
+Meanwhile, Pod Volume Backup/Restore are also running in node-agent pods, we don’t restrict the concurrency of these two types. For example, in one node, one Pod Volume Backup and one DataUpload could run at the same time, in this case, the resource will be shared by the two activities.  
+
+## Progress Report
+When a DUCR/DDCR is in InProgress phase, users could check the progress.  
+In DUCR/DDCR’s status, we have fields like ```totalBytes``` and ```doneBytes```, the same values will be displayed as a result of below querires:
+- Call ```kubectl get dataupload -n velero xxx or kubectl get datadownload -n velero xxx```.
+- Call ```velero backup describe –details```. This is implemented as part of BIA/RIA V2, the above values are transferred to async operation and this command retrieve them from the async operation instead of DUCR/DDCR. See [general progress monitoring design][2] for details
+
+
+## Backup Sync
+DUCR contains the information that is required during restore but as mentioned above, it will not be synced because during restore its information is retrieved dynamically. Therefore, we have no change to Backup Sync.  
+
+## Backup Deletion
+Once a backup is deleted, the data in the backup repository should be deleted as well. On the other hand, the data is created by the specific DM, Velero doesn't know how to delete the data. Therefore, Velero relies on the DM to delete the backup data.  
+As the current workflow, when ```velero backup delete``` CLI is called, a ```deletebackuprequests``` CR is submitted; after the backup delete controller finishes all the work, the ```deletebackuprequests``` CR will be deleted. In order to give an opportunity for the DM to delete the backup data, we remedy the workflow as below:  
+- During the backup deletion, the backup delete controller retrieves all the DUCRs belong to the backup  
+- The backup delete controller then creates the DUCRs into the cluster
+- Before deleting the ```deletebackuprequests``` CR, the backup delete controller adds a ```velero.io/dm-delete-backup``` finalizer to the CR
+- As a result, the ```deletebackuprequests``` CR will not be deleted until the finalizer is removed
+- The DM needs to watch the ```deletebackuprequests``` CRs with the ```velero.io/dm-delete-backup``` finalizer
+- Once the DM finds one, it collects a list of DUCRs that belong to the backup indicating by the ```deletebackuprequests``` CR's spec
+- If the list is not empty, the DM delete the backup data for each of the DUCRs in the list as well as the DUCRs themselves
+- Finally, when all the items in the list are processed successfully, the DM removes the ```velero.io/dm-delete-backup``` finalizer
+- Otherwise, if any error happens during the processing, the ```deletebackuprequests``` CR will be left there with the ```velero.io/dm-delete-backup``` finalizer, as well as the failed DUCRs
+- DMs may use a periodical manner to retry the failed delete requests  
+
+## Restarts
+If Velero restarts during a data movement activity, the backup/restore will be marked as failed when Velero server comes back, by this time, Velero will request a cancellation to the ongoing data movement.  
+If DM restarts, Velero has no way to detect this, DM is expected to:
+- Either recover from the restart and continue the data movement
+- Or if DM doesn’t support recovery, it should cancel the data movement and mark the DUCR/DDCR as failed. DM should also clear any internal objects created during the data movement before and after the restart  
+
+At present, VBDM doesn't support recovery, so it will follow the second rule.  
+
+## Kopia For Block Device
+To work with block devices, VGDP will be updated. Today, when Kopia attempts to create a snapshot of the block device, it will error because kopia does not support this file type. Kopia does have a nice set of interfaces that are able to be extended though.
+
+To achieve the necessary information to determine the type of volume that is being used, we will need to pass in the volume mode in provider interface.
+
+```go
+type PersistentVolumeMode string 
+
+const (
+	// PersistentVolumeBlock means the volume will not be formatted with a filesystem and will remain a raw block device.
+	PersistentVolumeBlock PersistentVolumeMode = "Block"
+	// PersistentVolumeFilesystem means the volume will be or is formatted with a filesystem.
+	PersistentVolumeFilesystem PersistentVolumeMode = "Filesystem"
+)
+
+// Provider which is designed for one pod volume to do the backup or restore
+type Provider interface {
+	// RunBackup which will do backup for one specific volume and return snapshotID, isSnapshotEmpty, error
+	// updater is used for updating backup progress which implement by third-party
+	RunBackup(
+		ctx context.Context,
+		path string,
+		realSource string,
+		tags map[string]string,
+		forceFull bool,
+		parentSnapshot string,
+		volMode uploader.PersistentVolumeMode,
+		updater uploader.ProgressUpdater) (string, bool, error)
+
+  RunRestore(
+		ctx context.Context,
+		snapshotID string,
+		volumePath string,
+		volMode uploader.PersistentVolumeMode,
+		updater uploader.ProgressUpdater) error
+```
+
+In this case, we will extend the default kopia uploader to add the ability, when a given volume is for a block mode and is mapped as a device, we will use the [StreamingFile](https://pkg.go.dev/github.com/kopia/kopia@v0.13.0/fs#StreamingFile) to stream the device and backup to the kopia repository. 
+
+```go
+func getLocalBlockEntry(sourcePath string) (fs.Entry, error) {
+	source, err := resolveSymlink(sourcePath)
+	if err != nil {
+		return nil, errors.Wrap(err, "resolveSymlink")
+	}
+
+	fileInfo, err := os.Lstat(source)
+	if err != nil {
+		return nil, errors.Wrapf(err, "unable to get the source device information %s", source)
+	}
+
+	if (fileInfo.Sys().(*syscall.Stat_t).Mode & syscall.S_IFMT) != syscall.S_IFBLK {
+		return nil, errors.Errorf("source path %s is not a block device", source)
+	}
+
+	device, err := os.Open(source)
+	if err != nil {
+		if os.IsPermission(err) || err.Error() == ErrNotPermitted {
+			return nil, errors.Wrapf(err, "no permission to open the source device %s, make sure that node agent is running in privileged mode", source)
+		}
+		return nil, errors.Wrapf(err, "unable to open the source device %s", source)
+	}
+
+	sf := virtualfs.StreamingFileFromReader(source, device)
+	return virtualfs.NewStaticDirectory(source, []fs.Entry{sf}), nil
+}
+```
+
+In the `pkg/uploader/kopia/snapshot.go` this is used in the Backup call like
+
+```go
+	if volMode == uploader.PersistentVolumeFilesystem {
+		// to be consistent with restic when backup empty dir returns one error for upper logic handle
+		dirs, err := os.ReadDir(source)
+		if err != nil {
+			return nil, false, errors.Wrapf(err, "Unable to read dir in path %s", source)
+		} else if len(dirs) == 0 {
+			return nil, true, nil
+		}
+	}
+
+  source = filepath.Clean(source)
+  ...
+
+	var sourceEntry fs.Entry
+
+	if volMode == uploader.PersistentVolumeBlock {
+		sourceEntry, err = getLocalBlockEntry(source)
+		if err != nil {
+			return nil, false, errors.Wrap(err, "unable to get local block device entry")
+		}
+	} else {
+		sourceEntry, err = getLocalFSEntry(source)
+		if err != nil {
+			return nil, false, errors.Wrap(err, "unable to get local filesystem entry")
+		}
+	}
+
+  ...
+  	snapID, snapshotSize, err := SnapshotSource(kopiaCtx, repoWriter, fsUploader, sourceInfo, sourceEntry, forceFull, parentSnapshot, tags, log, "Kopia Uploader")
+
+```
+
+To handle restore, we need to extend the [Output](https://pkg.go.dev/github.com/kopia/kopia@v0.13.0/snapshot/restore#Output) interface and specifically the [FilesystemOutput](https://pkg.go.dev/github.com/kopia/kopia@v0.13.0/snapshot/restore#FilesystemOutput).
+
+We only need to extend two functions the rest will be passed through.
+
+```go
+type BlockOutput struct {
+	*restore.FilesystemOutput
+
+	targetFileName string
+}
+
+var _ restore.Output = &BlockOutput{}
+
+const bufferSize = 128 * 1024
+
+func (o *BlockOutput) WriteFile(ctx context.Context, relativePath string, remoteFile fs.File) error {
+	remoteReader, err := remoteFile.Open(ctx)
+	if err != nil {
+		return errors.Wrapf(err, "failed to open remote file %s", remoteFile.Name())
+	}
+	defer remoteReader.Close()
+
+	targetFile, err := os.Create(o.targetFileName)
+	if err != nil {
+		return errors.Wrapf(err, "failed to open file %s", o.targetFileName)
+	}
+	defer targetFile.Close()
+
+	buffer := make([]byte, bufferSize)
+
+	readData := true
+	for readData {
+		bytesToWrite, err := remoteReader.Read(buffer)
+		if err != nil {
+			if err != io.EOF {
+				return errors.Wrapf(err, "failed to read data from remote file %s", o.targetFileName)
+			}
+			readData = false
+		}
+
+		if bytesToWrite > 0 {
+			offset := 0
+			for bytesToWrite > 0 {
+				if bytesWritten, err := targetFile.Write(buffer[offset:bytesToWrite]); err == nil {
+					bytesToWrite -= bytesWritten
+					offset += bytesWritten
+				} else {
+					return errors.Wrapf(err, "failed to write data to file %s", o.targetFileName)
+				}
+			}
+		}
+	}
+
+	return nil
+}
+
+func (o *BlockOutput) BeginDirectory(ctx context.Context, relativePath string, e fs.Directory) error {
+	var err error
+	o.targetFileName, err = filepath.EvalSymlinks(o.TargetPath)
+	if err != nil {
+		return errors.Wrapf(err, "unable to evaluate symlinks for %s", o.targetFileName)
+	}
+
+	fileInfo, err := os.Lstat(o.targetFileName)
+	if err != nil {
+		return errors.Wrapf(err, "unable to get the target device information for %s", o.TargetPath)
+	}
+
+	if (fileInfo.Sys().(*syscall.Stat_t).Mode & syscall.S_IFMT) != syscall.S_IFBLK {
+		return errors.Errorf("target file %s is not a block device", o.TargetPath)
+	}
+
+	return nil
+}
+```
+
+Additional mount is required in the node-agent specification to resolve symlinks to the block devices from /host_pods/POD_ID/volumeDevices/kubernetes.io~csi directory.
+
+```yaml
+            - mountPath: /var/lib/kubelet/plugins
+              mountPropagation: HostToContainer
+              name: host-plugins
+....
+        - hostPath:
+            path: /var/lib/kubelet/plugins
+          name: host-plugins
+```
+
+Privileged mode is required to access the block devices in /var/lib/kubelet/plugins/kubernetes.io/csi/volumeDevices/publish directory as confirmed by testing on EKS and Minikube.
+
+```yaml
+							SecurityContext: &corev1.SecurityContext{
+								Privileged: &c.privilegedNodeAgent,
+							},
+```
+
+## Plugin Data Movers
+There should be only one DM to handle a specific DUCR/DDCR in all cases. If more than one DMs process a DUCR/DDCR at the same time, there will be a disaster.  
+Therefore, a DM should check the dataMover field of DUCR/DDCR and process the CRs belong to it only.  
+For example, VBDM reconciles DUCR/DDCR with their ```dataMover``` field set to "" or "velero", it will skip all others.  
+This means during the installation, users are allowed to install more than one DMs, but the DMs should follow the above rule.   
+When creating a backup, we should allow users to specify the data mover, so a new backup CLI option is required.  
+For restore, we should retrieve the same information from the corresponding backup, so that the data mover selection is consistent.  
+
+At present, Velero doesn't have the capability to verify the existence of the specified data mover. As a result, if a wrong data mover name is specified for the backup or the specified data mover is not installed, nothing will fail early, DUCR/DDCR is still created and Velero will wait there until timeout.  
+
+Plugin DMs may need some private configurations, the plugin DM providers are recommended to create a self-managed configMap to take the information. Velero doesn't maintain the lifecycle of the configMap.  
+Besides, the configMap is recommended to named as the DM's name, in this way, if Velero or DMP recognizes some generic options that varies between DMs, the options could be added into the configMap and visited by Velero or DMP.  
+
+Conclusively, below are the steps plugin DMs need to do in order to integrate to Velero volume snapshot data movement.  
+### Backup
+- Handle and only handle DUCRs with the matching ```dataMover``` value
+- Maintain the phases and progresses of DUCRs correctly
+- If supported, response to the Cancel request of DUCRs
+- Dispose the volume snapshots as well as their related objects after the snapshot data is transferred
+
+### Restore
+- Handle and only handle DDCRs with the matching ```dataMover``` value
+- Maintain the phases and progresses of DDCRs correctly
+- If supported, response to the Cancel request of DDCRs
+- Create the PV with data restored to it
+- Set PV's ```claimRef``` to the provided PVC and set ```velero.io/dynamic-pv-restore``` label
+
+## Working Mode
+It doesn’t mean that once the data movement feature is enabled users must move every snapshot. We will support below two working modes:
+- Don’t move snapshots. This is same with the existing CSI snapshot feature, that is, native snapshots are taken and kept
+- Move snapshot data and delete native snapshots. This means that once the data movement completes, the native snapshots will be deleted.
+
+For this purpose, we need to add a new option in the backup command as well as the Backup CRD.  
+The same option for restore will be retrieved from the specified backup, so that the working mode is consistent.  
+
+## Backup and Restore CRD Changes
+We add below new fields in the Backup CRD:
+```
+	// SnapshotMoveData specifies whether snapshot data should be moved
+	// +optional
+	// +nullable
+	SnapshotMoveData *bool `json:"snapshotMoveData,omitempty"`
+
+	// DataMover specifies the data mover to be used by the backup.
+	// If DataMover is "" or "velero", the built-in data mover will be used.
+	// +optional
+	DataMover string `json:"datamover,omitempty"`
+```	
+SnapshotMoveData will be used to decide the Working Mode.  
+DataMover will be used to decide the data mover to handle the DUCR. DUCR's DataMover value is derived from this value.    
+
+As mentioned in the Plugin Data Movers section, the data movement information for a restore should be the same with the backup. Therefore, the working mode for restore should be decided by checking the corresponding Backup CR; when creating a DDCR, the DataMover value should be retrieved from the corresponding Backup Result.  
+
+## Logging
+The logs during the data movement are categorized as below:
+- Logs generated by Velero
+- Logs generated by DMPs
+- Logs generated by DMs
+
+For 1 and 2, the existing plugin mechanism guarantees that the logs could be saved into the Velero server log as well as backup/restore persistent log.  
+For 3, Velero leverage on DMs to decide how to save the log, but they will not go to Velero server log or backup/restore persistent log. For VBDM, the logs are saved in the node-agent server log.  
+
+## Installation
+DMs need to be configured during installation so that they can be installed. Plugin DMs may have their own configuration, for VGDM, the only requirement is to install Velero node-agent.  
+Moreover, the DMP is also required during the installation.  
+For example, to move CSI snapshot through VBDM, below is the installation script:  
+```
+velero install \
+    --provider \
+    --image \
+    --plugins velero/velero-plugin-for-csi:xxx \
+    --features=EnableCSI \
+    --use-node-agent \ 
+```
+
+## Upgrade
+For VBDM, no new installation option is introduced, so upgrade is not affected.
+If plugin DMs require new options and so the upgrade is affected, they should explain them in their own documents.
+
+## CLI
+As explained in the Working Mode section, we add one more flag ```snapshot-move-data``` to indicate whether the snapshot data should be moved.  
+As explained in the Plugin Data Movers section, we add one more flag ```data-mover``` for users to configure the data mover to move the snapshot data.  
+Example of backup command are as below.  
+
+Below CLI means to create a backup with volume snapshot data movement enabled and with VBDM as the data mover:  
+```
+velero backup create xxx --include-namespaces --snapshot-move-data
+```
+
+Below CLI has the same meaning as the first one:  
+```
+velero backup create xxx --include-namespaces --snapshot-move-data --data-mover velero
+```
+
+Below CLI means to create a backup with volume snapshot data movement enabled and with "xxx-plugin-dm" as the data mover:  
+```
+velero backup create xxx --include-namespaces --snapshot-move-data --data-mover xxx-plugin-dm
+```
+
+Restore command is kept as is.  
+
+
+
+
+[1]: ../unified-repo-and-kopia-integration/unified-repo-and-kopia-integration.md
+[2]: ../general-progress-monitoring.md

design/vsv2-design.md

@@ -0,0 +1,84 @@
+# Design for VolumeSnapshotter v2 API
+
+## Abstract
+This design includes the changes to the VolumeSnapshotter api design as required by the [Item Action Progress Monitoring](general-progress-monitoring.md) feature.
+The VolumeSnapshotter v2 interface will have two new methods.
+If there are any additional VolumeSnapshotter API changes that are needed in the same Velero release cycle as this change, those can be added here as well.
+
+## Background
+This API change is needed to facilitate long-running plugin actions that may not be complete when the Execute() method returns.
+The existing snapshotID returned by CreateSnapshot will be used as the operation ID.
+This will allow long-running plugin actions to continue in the background while Velero moves on to the next plugin, the next item, etc.
+
+## Goals
+- Allow for VolumeSnapshotter CreateSnapshot() to initiate a long-running operation and report on operation status.
+
+## Non Goals
+- Allowing velero control over when the long-running operation begins.
+
+
+## High-Level Design
+As per the [Plugin Versioning](plugin-versioning.md) design, a new VolumeSnapshotterv2 plugin `.proto` file will be created to define the GRPC interface.
+v2 go files will also be created in `plugin/clientmgmt/volumesnapshotter` and `plugin/framework/volumesnapshotter`, and a new PluginKind will be created.
+The velero Backup process will be modified to reference v2 plugins instead of v1 plugins.
+An adapter will be created so that any existing VolumeSnapshotter v1 plugin can be executed as a v2 plugin when executing a backup.
+
+## Detailed Design
+
+### proto changes (compiled into golang by protoc)
+
+The v2 VolumeSnapshotter.proto will be like the current v1 version with the following changes:
+The VolumeSnapshotter service gets two new rpc methods:
+```
+service VolumeSnapshotter {
+    rpc Init(VolumeSnapshotterInitRequest) returns (Empty);
+    rpc CreateVolumeFromSnapshot(CreateVolumeRequest) returns (CreateVolumeResponse);
+    rpc GetVolumeInfo(GetVolumeInfoRequest) returns (GetVolumeInfoResponse);
+    rpc CreateSnapshot(CreateSnapshotRequest) returns (CreateSnapshotResponse);
+    rpc DeleteSnapshot(DeleteSnapshotRequest) returns (Empty);
+    rpc GetVolumeID(GetVolumeIDRequest) returns (GetVolumeIDResponse);
+    rpc SetVolumeID(SetVolumeIDRequest) returns (SetVolumeIDResponse);
+    rpc Progress(VolumeSnapshotterProgressRequest) returns (VolumeSnapshotterProgressResponse);
+    rpc Cancel(VolumeSnapshotterCancelRequest) returns (google.protobuf.Empty);
+}
+```
+To support these new rpc methods, we define new request/response message types:
+```
+message VolumeSnapshotterProgressRequest {
+    string plugin = 1;
+    string snapshotID = 2;
+}
+
+message VolumeSnapshotterProgressResponse {
+    generated.OperationProgress progress = 1;
+}
+
+message VolumeSnapshotterCancelRequest {
+    string plugin = 1;
+    string operationID = 2;
+}
+
+```
+One new shared message type will be needed, as defined in the v2 BackupItemAction design:
+```
+message OperationProgress {
+    bool completed = 1;
+    string err = 2;
+    int64 completed = 3;
+    int64 total = 4;
+    string operationUnits = 5;
+    string description = 6;
+    google.protobuf.Timestamp started = 7;
+    google.protobuf.Timestamp updated = 8;
+}
+```
+
+A new PluginKind, `VolumeSnapshotterV2`, will be created, and the backup process will be modified to use this plugin kind.
+See [Plugin Versioning](plugin-versioning.md) for more details on implementation plans, including v1 adapters, etc.
+
+
+## Compatibility
+The included v1 adapter will allow any existing VolumeSnapshotter plugin to work as expected, with no-op Progress() and Cancel() methods.
+
+## Implementation
+This will be implemented during the Velero 1.11 development cycle.

examples/nginx-app/base.yaml

@@ -26,6 +26,8 @@ kind: Deployment
 metadata:
   name: nginx-deployment
   namespace: nginx-example
+  labels:
+    app: nginx
 spec:
   replicas: 2
   selector:

go.mod

@@ -1,111 +1,120 @@
 module github.com/vmware-tanzu/velero
 
-go 1.18
+go 1.20
 
 require (
-	cloud.google.com/go/storage v1.21.0
+	cloud.google.com/go/storage v1.30.1
 	github.com/Azure/azure-pipeline-go v0.2.3
-	github.com/Azure/azure-sdk-for-go v61.4.0+incompatible
-	github.com/Azure/azure-storage-blob-go v0.14.0
-	github.com/Azure/go-autorest/autorest v0.11.21
+	github.com/Azure/azure-sdk-for-go v67.2.0+incompatible
+	github.com/Azure/azure-storage-blob-go v0.15.0
+	github.com/Azure/go-autorest/autorest v0.11.27
 	github.com/Azure/go-autorest/autorest/azure/auth v0.5.8
 	github.com/Azure/go-autorest/autorest/to v0.3.0
-	github.com/aws/aws-sdk-go v1.43.31
+	github.com/aws/aws-sdk-go v1.44.253
 	github.com/bombsimon/logrusr/v3 v3.0.0
 	github.com/evanphx/json-patch v5.6.0+incompatible
-	github.com/fatih/color v1.13.0
+	github.com/fatih/color v1.15.0
 	github.com/gobwas/glob v0.2.3
-	github.com/golang/protobuf v1.5.2
-	github.com/google/go-cmp v0.5.8
+	github.com/golang/protobuf v1.5.3
+	github.com/google/go-cmp v0.5.9
 	github.com/google/uuid v1.3.0
 	github.com/hashicorp/go-hclog v0.14.1
 	github.com/hashicorp/go-plugin v1.4.3
 	github.com/joho/godotenv v1.3.0
-	github.com/kopia/kopia v0.10.7
+	github.com/kopia/kopia v0.13.0
 	github.com/kubernetes-csi/external-snapshotter/client/v4 v4.2.0
 	github.com/onsi/ginkgo v1.16.5
-	github.com/onsi/gomega v1.18.1
+	github.com/onsi/gomega v1.20.1
 	github.com/pkg/errors v0.9.1
-	github.com/prometheus/client_golang v1.12.2
+	github.com/prometheus/client_golang v1.15.0
 	github.com/robfig/cron v1.1.0
-	github.com/sirupsen/logrus v1.8.1
+	github.com/sirupsen/logrus v1.9.0
 	github.com/spf13/afero v1.6.0
 	github.com/spf13/cobra v1.4.0
 	github.com/spf13/pflag v1.0.5
-	github.com/stretchr/testify v1.7.1
+	github.com/stretchr/testify v1.8.2
 	github.com/vmware-tanzu/crash-diagnostics v0.3.7
-	golang.org/x/mod v0.6.0-dev.0.20220419223038-86c51ed26bb4
-	golang.org/x/net v0.7.0
-	golang.org/x/oauth2 v0.0.0-20220608161450-d0670ef3b1eb
-	golang.org/x/sync v0.0.0-20210220032951-036812b2e83c
-	google.golang.org/api v0.74.0
-	google.golang.org/grpc v1.45.0
-	google.golang.org/protobuf v1.28.0
-	k8s.io/api v0.24.2
+	go.uber.org/zap v1.24.0
+	golang.org/x/exp v0.0.0-20221028150844-83b7d23a625f
+	golang.org/x/mod v0.10.0
+	golang.org/x/net v0.17.0
+	golang.org/x/oauth2 v0.7.0
+	golang.org/x/text v0.13.0
+	google.golang.org/api v0.120.0
+	google.golang.org/grpc v1.56.3
+	google.golang.org/protobuf v1.30.0
+	gopkg.in/yaml.v3 v3.0.1
+	k8s.io/api v0.25.6
 	k8s.io/apiextensions-apiserver v0.24.2
-	k8s.io/apimachinery v0.24.2
+	k8s.io/apimachinery v0.25.6
 	k8s.io/cli-runtime v0.24.0
-	k8s.io/client-go v0.24.2
-	k8s.io/klog/v2 v2.60.1
+	k8s.io/client-go v0.25.6
+	k8s.io/klog/v2 v2.70.1
 	k8s.io/kube-aggregator v0.19.12
-	k8s.io/utils v0.0.0-20220210201930-3a6ce19ff2f9
+	k8s.io/metrics v0.25.6
+	k8s.io/utils v0.0.0-20220728103510-ee6ede2d64ed
 	sigs.k8s.io/controller-runtime v0.12.2
+	sigs.k8s.io/json v0.0.0-20221116044647-bc3834ca7abd
 	sigs.k8s.io/yaml v1.3.0
 )
 
 require (
-	cloud.google.com/go v0.100.2 // indirect
-	cloud.google.com/go/compute v1.5.0 // indirect
-	cloud.google.com/go/iam v0.1.1 // indirect
+	cloud.google.com/go v0.110.0 // indirect
+	cloud.google.com/go/compute v1.19.1 // indirect
+	cloud.google.com/go/compute/metadata v0.2.3 // indirect
+	cloud.google.com/go/iam v0.13.0 // indirect
 	github.com/Azure/azure-sdk-for-go/sdk/azcore v0.21.1 // indirect
 	github.com/Azure/azure-sdk-for-go/sdk/internal v0.8.3 // indirect
 	github.com/Azure/azure-sdk-for-go/sdk/storage/azblob v0.3.0 // indirect
 	github.com/Azure/go-autorest v14.2.0+incompatible // indirect
-	github.com/Azure/go-autorest/autorest/adal v0.9.16 // indirect
+	github.com/Azure/go-autorest/autorest/adal v0.9.20 // indirect
 	github.com/Azure/go-autorest/autorest/azure/cli v0.4.2 // indirect
 	github.com/Azure/go-autorest/autorest/date v0.3.0 // indirect
 	github.com/Azure/go-autorest/autorest/validation v0.2.0 // indirect
 	github.com/Azure/go-autorest/logger v0.2.1 // indirect
 	github.com/Azure/go-autorest/tracing v0.6.0 // indirect
 	github.com/beorn7/perks v1.0.1 // indirect
-	github.com/cespare/xxhash/v2 v2.1.2 // indirect
+	github.com/cespare/xxhash/v2 v2.2.0 // indirect
 	github.com/chmduquesne/rollinghash v4.0.0+incompatible // indirect
 	github.com/davecgh/go-spew v1.1.1 // indirect
 	github.com/dimchansky/utfbom v1.1.1 // indirect
-	github.com/dustin/go-humanize v1.0.0 // indirect
+	github.com/dustin/go-humanize v1.0.1 // indirect
+	github.com/edsrzf/mmap-go v1.1.0 // indirect
 	github.com/emicklei/go-restful/v3 v3.8.0 // indirect
 	github.com/fsnotify/fsnotify v1.5.4 // indirect
 	github.com/go-logr/logr v1.2.3 // indirect
+	github.com/go-logr/stdr v1.2.2 // indirect
 	github.com/go-logr/zapr v1.2.0 // indirect
 	github.com/go-openapi/jsonpointer v0.19.5 // indirect
 	github.com/go-openapi/jsonreference v0.20.0 // indirect
 	github.com/go-openapi/swag v0.21.1 // indirect
 	github.com/gofrs/flock v0.8.1 // indirect
 	github.com/gogo/protobuf v1.3.2 // indirect
-	github.com/golang-jwt/jwt/v4 v4.4.1 // indirect
+	github.com/golang-jwt/jwt/v4 v4.5.0 // indirect
 	github.com/golang/groupcache v0.0.0-20210331224755-41bb18bfe9da // indirect
 	github.com/google/gnostic v0.6.9 // indirect
 	github.com/google/gofuzz v1.2.0 // indirect
-	github.com/googleapis/gax-go/v2 v2.2.0 // indirect
-	github.com/hashicorp/golang-lru v0.5.4 // indirect
+	github.com/google/s2a-go v0.1.2 // indirect
+	github.com/googleapis/enterprise-certificate-proxy v0.2.3 // indirect
+	github.com/googleapis/gax-go/v2 v2.8.0 // indirect
 	github.com/hashicorp/yamux v0.0.0-20180604194846-3520598351bb // indirect
 	github.com/imdario/mergo v0.3.13 // indirect
 	github.com/inconshreveable/mousetrap v1.0.0 // indirect
 	github.com/jmespath/go-jmespath v0.4.0 // indirect
 	github.com/josharian/intern v1.0.0 // indirect
 	github.com/json-iterator/go v1.1.12 // indirect
-	github.com/klauspost/compress v1.15.1 // indirect
-	github.com/klauspost/cpuid/v2 v2.0.12 // indirect
+	github.com/klauspost/compress v1.16.5 // indirect
+	github.com/klauspost/cpuid/v2 v2.2.4 // indirect
 	github.com/klauspost/pgzip v1.2.5 // indirect
-	github.com/kr/pretty v0.3.0 // indirect
+	github.com/klauspost/reedsolomon v1.11.7 // indirect
 	github.com/liggitt/tabwriter v0.0.0-20181228230101-89fcab3d43de // indirect
 	github.com/mailru/easyjson v0.7.7 // indirect
-	github.com/mattn/go-colorable v0.1.12 // indirect
+	github.com/mattn/go-colorable v0.1.13 // indirect
 	github.com/mattn/go-ieproxy v0.0.1 // indirect
-	github.com/mattn/go-isatty v0.0.14 // indirect
-	github.com/matttproud/golang_protobuf_extensions v1.0.2-0.20181231171920-c182affec369 // indirect
+	github.com/mattn/go-isatty v0.0.17 // indirect
+	github.com/matttproud/golang_protobuf_extensions v1.0.4 // indirect
 	github.com/minio/md5-simd v1.1.2 // indirect
-	github.com/minio/minio-go/v7 v7.0.23 // indirect
+	github.com/minio/minio-go/v7 v7.0.52 // indirect
 	github.com/minio/sha256-simd v1.0.0 // indirect
 	github.com/mitchellh/go-homedir v1.1.0 // indirect
 	github.com/mitchellh/go-testing-interface v1.0.0 // indirect
@@ -118,35 +127,36 @@ require (
 	github.com/oklog/run v1.0.0 // indirect
 	github.com/pierrec/lz4 v2.6.1+incompatible // indirect
 	github.com/pmezard/go-difflib v1.0.0 // indirect
-	github.com/prometheus/client_model v0.2.0 // indirect
-	github.com/prometheus/common v0.34.0 // indirect
-	github.com/prometheus/procfs v0.7.3 // indirect
-	github.com/rs/xid v1.3.0 // indirect
-	github.com/stretchr/objx v0.2.0 // indirect
+	github.com/prometheus/client_model v0.3.0 // indirect
+	github.com/prometheus/common v0.42.0 // indirect
+	github.com/prometheus/procfs v0.9.0 // indirect
+	github.com/rogpeppe/go-internal v1.9.0 // indirect
+	github.com/rs/xid v1.4.0 // indirect
+	github.com/stretchr/objx v0.5.0 // indirect
 	github.com/vladimirvivien/gexe v0.1.1 // indirect
 	github.com/zeebo/blake3 v0.2.3 // indirect
-	go.opencensus.io v0.23.0 // indirect
+	go.opencensus.io v0.24.0 // indirect
+	go.opentelemetry.io/otel v1.14.0 // indirect
+	go.opentelemetry.io/otel/trace v1.14.0 // indirect
 	go.starlark.net v0.0.0-20201006213952-227f4aabceb5 // indirect
 	go.uber.org/atomic v1.9.0 // indirect
-	go.uber.org/multierr v1.8.0 // indirect
-	go.uber.org/zap v1.21.0 // indirect
-	golang.org/x/crypto v0.0.0-20220315160706-3147a52a75dd // indirect
-	golang.org/x/exp v0.0.0-20210916165020-5cb4fee858ee // indirect
-	golang.org/x/sys v0.5.0 // indirect
-	golang.org/x/term v0.5.0 // indirect
-	golang.org/x/text v0.7.0 // indirect
+	go.uber.org/multierr v1.11.0 // indirect
+	golang.org/x/crypto v0.14.0 // indirect
+	golang.org/x/sync v0.1.0 // indirect
+	golang.org/x/sys v0.13.0 // indirect
+	golang.org/x/term v0.13.0 // indirect
 	golang.org/x/time v0.0.0-20220609170525-579cf78fd858 // indirect
-	golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1 // indirect
+	golang.org/x/xerrors v0.0.0-20220907171357-04be3eba64a2 // indirect
 	gomodules.xyz/jsonpatch/v2 v2.2.0 // indirect
 	google.golang.org/appengine v1.6.7 // indirect
-	google.golang.org/genproto v0.0.0-20220324131243-acbaeb5b85eb // indirect
+	google.golang.org/genproto v0.0.0-20230410155749-daa745c078e1 // indirect
 	gopkg.in/inf.v0 v0.9.1 // indirect
-	gopkg.in/ini.v1 v1.66.2 // indirect
+	gopkg.in/ini.v1 v1.67.0 // indirect
 	gopkg.in/tomb.v1 v1.0.0-20141024135613-dd632973f1e7 // indirect
 	gopkg.in/yaml.v2 v2.4.0 // indirect
-	gopkg.in/yaml.v3 v3.0.1 // indirect
 	k8s.io/component-base v0.24.2 // indirect
-	k8s.io/kube-openapi v0.0.0-20220614142933-1062c7ade5f8 // indirect
-	sigs.k8s.io/json v0.0.0-20220525155127-227cbc7cc124 // indirect
-	sigs.k8s.io/structured-merge-diff/v4 v4.2.1 // indirect
+	k8s.io/kube-openapi v0.0.0-20220803162953-67bda5d908f1 // indirect
+	sigs.k8s.io/structured-merge-diff/v4 v4.2.3 // indirect
 )
+
+replace github.com/kopia/kopia => github.com/project-velero/kopia v0.13.0-velero.1

go.sum

@@ -19,33 +19,24 @@ cloud.google.com/go v0.74.0/go.mod h1:VV1xSbzvo+9QJOxLDaJfTjx5e+MePCpCWwvftOeQmW
 cloud.google.com/go v0.78.0/go.mod h1:QjdrLG0uq+YwhjoVOLsS1t7TW8fs36kLs4XO5R5ECHg=
 cloud.google.com/go v0.79.0/go.mod h1:3bzgcEeQlzbuEAYu4mrWhKqWjmpprinYgKJLgKHnbb8=
 cloud.google.com/go v0.81.0/go.mod h1:mk/AM35KwGk/Nm2YSeZbxXdrNK3KZOYHmLkOqC2V6E0=
-cloud.google.com/go v0.83.0/go.mod h1:Z7MJUsANfY0pYPdw0lbnivPx4/vhy/e2FEkSkF7vAVY=
-cloud.google.com/go v0.84.0/go.mod h1:RazrYuxIK6Kb7YrzzhPoLmCVzl7Sup4NrbKPg8KHSUM=
-cloud.google.com/go v0.87.0/go.mod h1:TpDYlFy7vuLzZMMZ+B6iRiELaY7z/gJPaqbMx6mlWcY=
-cloud.google.com/go v0.90.0/go.mod h1:kRX0mNRHe0e2rC6oNakvwQqzyDmg57xJ+SZU1eT2aDQ=
-cloud.google.com/go v0.93.3/go.mod h1:8utlLll2EF5XMAV15woO4lSbWQlk8rer9aLOfLh7+YI=
-cloud.google.com/go v0.94.1/go.mod h1:qAlAugsXlC+JWO+Bke5vCtc9ONxjQT3drlTTnAplMW4=
-cloud.google.com/go v0.97.0/go.mod h1:GF7l59pYBVlXQIBLx3a761cZ41F9bBH3JUlihCt2Udc=
-cloud.google.com/go v0.99.0/go.mod h1:w0Xx2nLzqWJPuozYQX+hFfCSI8WioryfRDzkoI/Y2ZA=
-cloud.google.com/go v0.100.1/go.mod h1:fs4QogzfH5n2pBXBP9vRiU+eCny7lD2vmFZy79Iuw1U=
-cloud.google.com/go v0.100.2 h1:t9Iw5QH5v4XtlEQaCtUY7x6sCABps8sW0acw7e2WQ6Y=
-cloud.google.com/go v0.100.2/go.mod h1:4Xra9TjzAeYHrl5+oeLlzbM2k3mjVhZh4UqTZ//w99A=
+cloud.google.com/go v0.110.0 h1:Zc8gqp3+a9/Eyph2KDmcGaPtbKRIoqq4YTlL4NMD0Ys=
+cloud.google.com/go v0.110.0/go.mod h1:SJnCLqQ0FCFGSZMUNUf84MV3Aia54kn7pi8st7tMzaY=
 cloud.google.com/go/bigquery v1.0.1/go.mod h1:i/xbL2UlR5RvWAURpBYZTtm/cXjCha9lbfbpx4poX+o=
 cloud.google.com/go/bigquery v1.3.0/go.mod h1:PjpwJnslEMmckchkHFfq+HTD2DmtT67aNFKH1/VBDHE=
 cloud.google.com/go/bigquery v1.4.0/go.mod h1:S8dzgnTigyfTmLBfrtrhyYhwRxG72rYxvftPBK2Dvzc=
 cloud.google.com/go/bigquery v1.5.0/go.mod h1:snEHRnqQbz117VIFhE8bmtwIDY80NLUZUMb4Nv6dBIg=
 cloud.google.com/go/bigquery v1.7.0/go.mod h1://okPTzCYNXSlb24MZs83e2Do+h+VXtc4gLoIoXIAPc=
 cloud.google.com/go/bigquery v1.8.0/go.mod h1:J5hqkt3O0uAFnINi6JXValWIb1v0goeZM77hZzJN/fQ=
-cloud.google.com/go/compute v0.1.0/go.mod h1:GAesmwr110a34z04OlxYkATPBEfVhkymfTBXtfbBFow=
-cloud.google.com/go/compute v1.2.0/go.mod h1:xlogom/6gr8RJGBe7nT2eGsQYAFUbbv8dbC29qE3Xmw=
-cloud.google.com/go/compute v1.3.0/go.mod h1:cCZiE1NHEtai4wiufUhW8I8S1JKkAnhnQJWM7YD99wM=
-cloud.google.com/go/compute v1.5.0 h1:b1zWmYuuHz7gO9kDcM/EpHGr06UgsYNRpNJzI2kFiLM=
-cloud.google.com/go/compute v1.5.0/go.mod h1:9SMHyhJlzhlkJqrPAc839t2BZFTSk6Jdj6mkzQJeu0M=
+cloud.google.com/go/compute v1.19.1 h1:am86mquDUgjGNWxiGn+5PGLbmgiWXlE/yNWpIpNvuXY=
+cloud.google.com/go/compute v1.19.1/go.mod h1:6ylj3a05WF8leseCdIf77NK0g1ey+nj5IKd5/kvShxE=
+cloud.google.com/go/compute/metadata v0.2.3 h1:mg4jlk7mCAj6xXp9UJ4fjI9VUI5rubuGBW5aJ7UnBMY=
+cloud.google.com/go/compute/metadata v0.2.3/go.mod h1:VAV5nSsACxMJvgaAuX6Pk2AawlZn8kiOGuCv6gTkwuA=
 cloud.google.com/go/datastore v1.0.0/go.mod h1:LXYbyblFSglQ5pkeyhO+Qmw7ukd3C+pD7TKLgZqpHYE=
 cloud.google.com/go/datastore v1.1.0/go.mod h1:umbIZjpQpHh4hmRpGhH4tLFup+FVzqBi1b3c64qFpCk=
 cloud.google.com/go/firestore v1.1.0/go.mod h1:ulACoGHTpvq5r8rxGJ4ddJZBZqakUQqClKRT5SZwBmk=
-cloud.google.com/go/iam v0.1.1 h1:4CapQyNFjiksks1/x7jsvsygFPhihslYk5GptIrlX68=
-cloud.google.com/go/iam v0.1.1/go.mod h1:CKqrcnI/suGpybEHxZ7BMehL0oA4LpdyJdUlTl9jVMw=
+cloud.google.com/go/iam v0.13.0 h1:+CmB+K0J/33d0zSQ9SlFWUeCCEn5XJA0ZMZ3pHE9u8k=
+cloud.google.com/go/iam v0.13.0/go.mod h1:ljOg+rcNfzZ5d6f1nAUJ8ZIxOaZUVoS14bKCtaLZ/D0=
+cloud.google.com/go/longrunning v0.4.1 h1:v+yFJOfKC3yZdY6ZUI933pIYdhyhV8S3NpWrXWmg7jM=
 cloud.google.com/go/pubsub v1.0.1/go.mod h1:R0Gpsv3s54REJCy4fxDixWD93lHJMoZTyQ2kNxGRt3I=
 cloud.google.com/go/pubsub v1.1.0/go.mod h1:EwwdRX2sKPjnvnqCa270oGRyludottCI76h+R3AArQw=
 cloud.google.com/go/pubsub v1.2.0/go.mod h1:jhfEVHT8odbXTkndysNHCcx0awwzvfOlguIAii9o8iA=
@@ -55,21 +46,21 @@ cloud.google.com/go/storage v1.5.0/go.mod h1:tpKbwo567HUNpVclU5sGELwQWBDZ8gh0Zeo
 cloud.google.com/go/storage v1.6.0/go.mod h1:N7U0C8pVQ/+NIKOBQyamJIeKQKkZ+mxpohlUTyfDhBk=
 cloud.google.com/go/storage v1.8.0/go.mod h1:Wv1Oy7z6Yz3DshWRJFhqM/UCfaWIRTdp0RXyy7KQOVs=
 cloud.google.com/go/storage v1.10.0/go.mod h1:FLPqc6j+Ki4BU591ie1oL6qBQGu2Bl/tZ9ullr3+Kg0=
-cloud.google.com/go/storage v1.21.0 h1:HwnT2u2D309SFDHQII6m18HlrCi3jAXhUMTLOWXYH14=
-cloud.google.com/go/storage v1.21.0/go.mod h1:XmRlxkgPjlBONznT2dDUU/5XlpU2OjMnKuqnZI01LAA=
+cloud.google.com/go/storage v1.30.1 h1:uOdMxAs8HExqBlnLtnQyP0YkvbiDpdGShGKtx6U/oNM=
+cloud.google.com/go/storage v1.30.1/go.mod h1:NfxhC0UJE1aXSx7CIIbCf7y9HKT7BiccwkR7+P7gN8E=
 dmitri.shuralyov.com/gpu/mtl v0.0.0-20190408044501-666a987793e9/go.mod h1:H6x//7gZCb22OMCxBHrMx7a5I7Hp++hsVxbQ4BYO7hU=
 github.com/Azure/azure-pipeline-go v0.2.3 h1:7U9HBg1JFK3jHl5qmo4CTZKFTVgMwdFHMVtCdfBE21U=
 github.com/Azure/azure-pipeline-go v0.2.3/go.mod h1:x841ezTBIMG6O3lAcl8ATHnsOPVl2bqk7S3ta6S6u4k=
-github.com/Azure/azure-sdk-for-go v61.4.0+incompatible h1:BF2Pm3aQWIa6q9KmxyF1JYKYXtVw67vtvu2Wd54NGuY=
-github.com/Azure/azure-sdk-for-go v61.4.0+incompatible/go.mod h1:9XXNKU+eRnpl9moKnB4QOLf1HestfXbmab5FXxiDBjc=
+github.com/Azure/azure-sdk-for-go v67.2.0+incompatible h1:Uu/Ww6ernvPTrpq31kITVTIm/I5jlJ1wjtEH/bmSB2k=
+github.com/Azure/azure-sdk-for-go v67.2.0+incompatible/go.mod h1:9XXNKU+eRnpl9moKnB4QOLf1HestfXbmab5FXxiDBjc=
 github.com/Azure/azure-sdk-for-go/sdk/azcore v0.21.1 h1:qoVeMsc9/fh/yhxVaA0obYjVH/oI/ihrOoMwsLS9KSA=
 github.com/Azure/azure-sdk-for-go/sdk/azcore v0.21.1/go.mod h1:fBF9PQNqB8scdgpZ3ufzaLntG0AG7C1WjPMsiFOmfHM=
 github.com/Azure/azure-sdk-for-go/sdk/internal v0.8.3 h1:E+m3SkZCN0Bf5q7YdTs5lSm2CYY3CK4spn5OmUIiQtk=
 github.com/Azure/azure-sdk-for-go/sdk/internal v0.8.3/go.mod h1:KLF4gFr6DcKFZwSuH8w8yEK6DpFl3LP5rhdvAb7Yz5I=
 github.com/Azure/azure-sdk-for-go/sdk/storage/azblob v0.3.0 h1:Px2UA+2RvSSvv+RvJNuUB6n7rs5Wsel4dXLe90Um2n4=
 github.com/Azure/azure-sdk-for-go/sdk/storage/azblob v0.3.0/go.mod h1:tPaiy8S5bQ+S5sOiDlINkp7+Ef339+Nz5L5XO+cnOHo=
-github.com/Azure/azure-storage-blob-go v0.14.0 h1:1BCg74AmVdYwO3dlKwtFU1V0wU2PZdREkXvAmZJRUlM=
-github.com/Azure/azure-storage-blob-go v0.14.0/go.mod h1:SMqIBi+SuiQH32bvyjngEewEeXoPfKMgWlBDaYf6fck=
+github.com/Azure/azure-storage-blob-go v0.15.0 h1:rXtgp8tN1p29GvpGgfJetavIG0V7OgcSXPpwp3tx6qk=
+github.com/Azure/azure-storage-blob-go v0.15.0/go.mod h1:vbjsVbX0dlxnRc4FFMPsS9BsJWPcne7GB7onqlPvz58=
 github.com/Azure/go-ansiterm v0.0.0-20170929234023-d6e3b3328b78/go.mod h1:LmzpDX56iTiv29bbRTIsUNlaFfuhWRQBWjQdVyAevI8=
 github.com/Azure/go-ansiterm v0.0.0-20210617225240-d185dfc1b5a1/go.mod h1:xomTg63KZ2rFqZQzSB4Vz2SUXa1BpHTVz9L5PTmPC4E=
 github.com/Azure/go-autorest v14.2.0+incompatible h1:V5VMDjClD3GiElqLWO7mz2MxNAK/vTfRHdAubSIPRgs=
@@ -78,16 +69,16 @@ github.com/Azure/go-autorest/autorest v0.9.0/go.mod h1:xyHB1BMZT0cuDHU7I0+g046+B
 github.com/Azure/go-autorest/autorest v0.9.6/go.mod h1:/FALq9T/kS7b5J5qsQ+RSTUdAmGFqi0vUdVNNx8q630=
 github.com/Azure/go-autorest/autorest v0.11.17/go.mod h1:eipySxLmqSyC5s5k1CLupqet0PSENBEDP93LQ9a8QYw=
 github.com/Azure/go-autorest/autorest v0.11.18/go.mod h1:dSiJPy22c3u0OtOKDNttNgqpNFY/GeWa7GH/Pz56QRA=
-github.com/Azure/go-autorest/autorest v0.11.21 h1:w77zY/9RnUAWcIQyDC0Fc89mCvwftR8F+zsR/OH6enk=
-github.com/Azure/go-autorest/autorest v0.11.21/go.mod h1:Do/yuMSW/13ayUkcVREpsMHGG+MvV81uzSCFgYPj4tM=
+github.com/Azure/go-autorest/autorest v0.11.27 h1:F3R3q42aWytozkV8ihzcgMO4OA4cuqr3bNlsEuF6//A=
+github.com/Azure/go-autorest/autorest v0.11.27/go.mod h1:7l8ybrIdUmGqZMTD0sRtAr8NvbHjfofbf8RSP2q7w7U=
 github.com/Azure/go-autorest/autorest/adal v0.5.0/go.mod h1:8Z9fGy2MpX0PvDjB1pEgQTmVqjGhiHBW7RJJEciWzS0=
 github.com/Azure/go-autorest/autorest/adal v0.8.2/go.mod h1:ZjhuQClTqx435SRJ2iMlOxPYt3d2C/T/7TiQCVZSn3Q=
 github.com/Azure/go-autorest/autorest/adal v0.9.5/go.mod h1:B7KF7jKIeC9Mct5spmyCB/A8CG/sEz1vwIRGv/bbw7A=
 github.com/Azure/go-autorest/autorest/adal v0.9.11/go.mod h1:nBKAnTomx8gDtl+3ZCJv2v0KACFHWTB2drffI1B68Pk=
 github.com/Azure/go-autorest/autorest/adal v0.9.13/go.mod h1:W/MM4U6nLxnIskrw4UwWzlHfGjwUS50aOsc/I3yuU8M=
-github.com/Azure/go-autorest/autorest/adal v0.9.14/go.mod h1:W/MM4U6nLxnIskrw4UwWzlHfGjwUS50aOsc/I3yuU8M=
-github.com/Azure/go-autorest/autorest/adal v0.9.16 h1:P8An8Z9rH1ldbOLdFpxYorgOt2sywL9V24dAwWHPuGc=
-github.com/Azure/go-autorest/autorest/adal v0.9.16/go.mod h1:tGMin8I49Yij6AQ+rvV+Xa/zwxYQB5hmsd6DkfAx2+A=
+github.com/Azure/go-autorest/autorest/adal v0.9.18/go.mod h1:XVVeme+LZwABT8K5Lc3hA4nAe8LDBVle26gTrguhhPQ=
+github.com/Azure/go-autorest/autorest/adal v0.9.20 h1:gJ3E98kMpFB1MFqQCvA1yFab8vthOeD4VlFRQULxahg=
+github.com/Azure/go-autorest/autorest/adal v0.9.20/go.mod h1:XVVeme+LZwABT8K5Lc3hA4nAe8LDBVle26gTrguhhPQ=
 github.com/Azure/go-autorest/autorest/azure/auth v0.5.8 h1:TzPg6B6fTZ0G1zBf3T54aI7p3cAT6u//TOXGPmFMOXg=
 github.com/Azure/go-autorest/autorest/azure/auth v0.5.8/go.mod h1:kxyKZTSfKh8OVFWPAgOgQ/frrJgeYQJPyR5fLFmXko4=
 github.com/Azure/go-autorest/autorest/azure/cli v0.4.2 h1:dMOmEJfkLKW/7JsokJqkyoYSgmR08hi9KrhjZb+JALY=
@@ -99,8 +90,9 @@ github.com/Azure/go-autorest/autorest/date v0.3.0/go.mod h1:BI0uouVdmngYNUzGWeSY
 github.com/Azure/go-autorest/autorest/mocks v0.1.0/go.mod h1:OTyCOPRA2IgIlWxVYxBee2F5Gr4kF2zd2J5cFRaIDN0=
 github.com/Azure/go-autorest/autorest/mocks v0.2.0/go.mod h1:OTyCOPRA2IgIlWxVYxBee2F5Gr4kF2zd2J5cFRaIDN0=
 github.com/Azure/go-autorest/autorest/mocks v0.3.0/go.mod h1:a8FDP3DYzQ4RYfVAxAN3SVSiiO77gL2j2ronKKP0syM=
-github.com/Azure/go-autorest/autorest/mocks v0.4.1 h1:K0laFcLE6VLTOwNgSxaGbUcLPuGXlNkbVvq4cW4nIHk=
 github.com/Azure/go-autorest/autorest/mocks v0.4.1/go.mod h1:LTp+uSrOhSkaKrUy935gNZuuIPPVsHlr9DSOxSayd+k=
+github.com/Azure/go-autorest/autorest/mocks v0.4.2 h1:PGN4EDXnuQbojHbU0UWoNvmu9AGVwYHG9/fkDYhtAfw=
+github.com/Azure/go-autorest/autorest/mocks v0.4.2/go.mod h1:Vy7OitM9Kei0i1Oj+LvyAWMXJHeKH1MVlzFugfVrmyU=
 github.com/Azure/go-autorest/autorest/to v0.3.0 h1:zebkZaadz7+wIQYgC7GXaz3Wb28yKYfVkkBKwc38VF8=
 github.com/Azure/go-autorest/autorest/to v0.3.0/go.mod h1:MgwOyqaIuKdG4TL/2ywSsIWKAfJfgHDo8ObuUk3t5sA=
 github.com/Azure/go-autorest/autorest/validation v0.2.0 h1:15vMO4y76dehZSq7pAaOLQxC6dZYsSrj2GQpflyM/L4=
@@ -114,6 +106,7 @@ github.com/Azure/go-autorest/tracing v0.6.0 h1:TYi4+3m5t6K48TGI9AUdb+IzbnSxvnvUM
 github.com/Azure/go-autorest/tracing v0.6.0/go.mod h1:+vhtPC754Xsa23ID7GlGsrdKBpUA79WCAKPPZVC2DeU=
 github.com/BurntSushi/toml v0.3.1/go.mod h1:xHWCNGjB5oqiDr8zfno3MHue2Ht5sIBksp03qcyfWMU=
 github.com/BurntSushi/xgb v0.0.0-20160522181843-27f122750802/go.mod h1:IVnqGOEym/WlBOVXweHU+Q+/VP0lqqI8lqeDx9IjBqo=
+github.com/GehirnInc/crypt v0.0.0-20200316065508-bb7000b8a962 h1:KeNholpO2xKjgaaSyd+DyQRrsQjhbSeS7qe4nEw8aQw=
 github.com/NYTimes/gziphandler v0.0.0-20170623195520-56545f4a5d46/go.mod h1:3wb06e3pkSAbeQ52E9H9iFoQsEEwGN64994WTCIhntQ=
 github.com/NYTimes/gziphandler v1.1.1/go.mod h1:n/CVRwUEOgIxrgPvAQhUUr9oeUtvrhMomdKFjzJNB0c=
 github.com/OneOfOne/xxhash v1.2.2/go.mod h1:HSdplMjZKSmBqAxg5vPj2TmRDmfkzw+cTzAElWljhcU=
@@ -126,6 +119,7 @@ github.com/alecthomas/template v0.0.0-20190718012654-fb15b899a751/go.mod h1:LOuy
 github.com/alecthomas/units v0.0.0-20151022065526-2efee857e7cf/go.mod h1:ybxpYRFXyAe+OPACYpWeL0wqObRcbAqCMya13uyzqw0=
 github.com/alecthomas/units v0.0.0-20190717042225-c3de453c63f4/go.mod h1:ybxpYRFXyAe+OPACYpWeL0wqObRcbAqCMya13uyzqw0=
 github.com/alecthomas/units v0.0.0-20190924025748-f65c72e2690d/go.mod h1:rBZYJk541a8SKzHPHnH3zbiI+7dagKZ0cgpgrD7Fyho=
+github.com/alessio/shellescape v1.4.1 h1:V7yhSDDn8LP4lc4jS8pFkt0zCnzVJlG5JXy9BVKJUX0=
 github.com/antihax/optional v1.0.0/go.mod h1:uupD/76wgC+ih3iEmQUL+0Ugr19nfwCT1kdvxnR2qWY=
 github.com/antlr/antlr4/runtime/Go/antlr v0.0.0-20210826220005-b48c857c3a0e/go.mod h1:F7bn7fEU90QkQ3tnmaTx3LTKLEDqnwWODIYppRQ5hnY=
 github.com/armon/circbuf v0.0.0-20150827004946-bbbad097214e/go.mod h1:3U/XgcO3hCbHZ8TKRvWD2dDTCfh9M9ya+I9JpbB7O8o=
@@ -135,8 +129,8 @@ github.com/armon/go-radix v0.0.0-20180808171621-7fddfc383310/go.mod h1:ufUuZ+zHj
 github.com/armon/go-socks5 v0.0.0-20160902184237-e75332964ef5 h1:0CwZNZbxp69SHPdPJAN/hZIm0C4OItdklCFmMRWYpio=
 github.com/armon/go-socks5 v0.0.0-20160902184237-e75332964ef5/go.mod h1:wHh0iHkYZB8zMSxRWpUBQtwG5a7fFgvEO+odwuTv2gs=
 github.com/asaskevich/govalidator v0.0.0-20190424111038-f61b66f89f4a/go.mod h1:lB+ZfQJz7igIIfQNfa7Ml4HSf2uFQQRzpGGRXenZAgY=
-github.com/aws/aws-sdk-go v1.43.31 h1:yJZIr8nMV1hXjAvvOLUFqZRJcHV7udPQBfhJqawDzI0=
-github.com/aws/aws-sdk-go v1.43.31/go.mod h1:y4AeaBuwd2Lk+GepC1E9v0qOiTws0MIWAX4oIKwKHZo=
+github.com/aws/aws-sdk-go v1.44.253 h1:iqDd0okcH4ShfFexz2zzf4VmeDFf6NOMm07pHnEb8iY=
+github.com/aws/aws-sdk-go v1.44.253/go.mod h1:aVsgQcEevwlmQ7qHE9I3h+dtQgpqhFB+i8Phjh7fkwI=
 github.com/benbjohnson/clock v1.0.3/go.mod h1:bGMdMPoPVvcYyt1gHDf4J2KE153Yf9BuiUKYMaxlTDM=
 github.com/benbjohnson/clock v1.1.0 h1:Q92kusRqC1XV2MjkWETPvjJVqKetz1OzxZB7mHJLju8=
 github.com/benbjohnson/clock v1.1.0/go.mod h1:J11/hYXuz8f4ySSvYwY0FKfm+ezbsZBKZxNJlLklBHA=
@@ -157,8 +151,9 @@ github.com/certifi/gocertifi v0.0.0-20191021191039-0944d244cd40/go.mod h1:sGbDF6
 github.com/certifi/gocertifi v0.0.0-20200922220541-2c3bb06c6054/go.mod h1:sGbDF6GwGcLpkNXPUTkMRoywsNa/ol15pxFe6ERfguA=
 github.com/cespare/xxhash v1.1.0/go.mod h1:XrSqR1VqqWfGrhpAt58auRo0WTKS1nRRg3ghfAqPWnc=
 github.com/cespare/xxhash/v2 v2.1.1/go.mod h1:VGX0DQ3Q6kWi7AoAeZDth3/j3BFtOZR5XLFGgcrjCOs=
-github.com/cespare/xxhash/v2 v2.1.2 h1:YRXhKfTDauu4ajMg1TPgFO5jnlC2HCbmLXMcTG5cbYE=
 github.com/cespare/xxhash/v2 v2.1.2/go.mod h1:VGX0DQ3Q6kWi7AoAeZDth3/j3BFtOZR5XLFGgcrjCOs=
+github.com/cespare/xxhash/v2 v2.2.0 h1:DC2CZ1Ep5Y4k3ZQ899DldepgrayRUGE6BBZ/cd9Cj44=
+github.com/cespare/xxhash/v2 v2.2.0/go.mod h1:VGX0DQ3Q6kWi7AoAeZDth3/j3BFtOZR5XLFGgcrjCOs=
 github.com/chmduquesne/rollinghash v4.0.0+incompatible h1:hnREQO+DXjqIw3rUTzWN7/+Dpw+N5Um8zpKV0JOEgbo=
 github.com/chmduquesne/rollinghash v4.0.0+incompatible/go.mod h1:Uc2I36RRfTAf7Dge82bi3RU0OQUmXT9iweIcPqvr8A0=
 github.com/chzyer/logex v1.1.10/go.mod h1:+Ywpsq7O8HXn0nuIou7OrIPyXbp3wmkHB+jjWRnGsAI=
@@ -193,6 +188,7 @@ github.com/cpuguy83/go-md2man/v2 v2.0.1/go.mod h1:tgQtvFlXSQOSOSIRvRPT7W67SCa46t
 github.com/creack/pty v1.1.7/go.mod h1:lj5s0c3V2DBrqTV7llrYr5NG6My20zk30Fl46Y7DoTY=
 github.com/creack/pty v1.1.9/go.mod h1:oKZEueFk5CKHvIhNR5MUki03XCEU+Q6VDXinZuGJ33E=
 github.com/creack/pty v1.1.11/go.mod h1:oKZEueFk5CKHvIhNR5MUki03XCEU+Q6VDXinZuGJ33E=
+github.com/danieljoos/wincred v1.1.2 h1:QLdCxFs1/Yl4zduvBdcHB8goaYk9RARS2SgLLRuAyr0=
 github.com/davecgh/go-spew v1.1.0/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38=
 github.com/davecgh/go-spew v1.1.1 h1:vj9j/u1bqnvCEfJOwUhtlOARqs3+rkHYY13jYWTU97c=
 github.com/davecgh/go-spew v1.1.1/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38=
@@ -207,8 +203,11 @@ github.com/dnaeon/go-vcr v1.2.0/go.mod h1:R4UdLID7HZT3taECzJs4YgbbH6PIGXB6W/sc5O
 github.com/docker/spdystream v0.0.0-20160310174837-449fdfce4d96/go.mod h1:Qh8CwZgvJUkLughtfhJv5dyTYa91l1fOUCrgjqmcifM=
 github.com/docopt/docopt-go v0.0.0-20180111231733-ee0de3bc6815/go.mod h1:WwZ+bS3ebgob9U8Nd0kOddGdZWjyMGR8Wziv+TBNwSE=
 github.com/dustin/go-humanize v0.0.0-20171111073723-bb3d318650d4/go.mod h1:HtrtbFcZ19U5GC7JDqmcUSB87Iq5E25KnS6fMYU6eOk=
-github.com/dustin/go-humanize v1.0.0 h1:VSnTsYCnlFHaM2/igO1h6X3HA71jcobQuxemgkq4zYo=
 github.com/dustin/go-humanize v1.0.0/go.mod h1:HtrtbFcZ19U5GC7JDqmcUSB87Iq5E25KnS6fMYU6eOk=
+github.com/dustin/go-humanize v1.0.1 h1:GzkhY7T5VNhEkwH0PVJgjz+fX1rhBrR7pRT3mDkpeCY=
+github.com/dustin/go-humanize v1.0.1/go.mod h1:Mu1zIs6XwVuF/gI1OepvI0qD18qycQx+mFykh5fBlto=
+github.com/edsrzf/mmap-go v1.1.0 h1:6EUwBLQ/Mcr1EYLE4Tn1VdW1A4ckqCQWZBw8Hr0kjpQ=
+github.com/edsrzf/mmap-go v1.1.0/go.mod h1:19H/e8pUPLicwkyNgOykDXkJ9F0MHE+Z52B8EIth78Q=
 github.com/elazarl/goproxy v0.0.0-20180725130230-947c36da3153 h1:yUdfgN0XgIJw7foRItutHYUIhlcKzcSf5vDpdhQAKTc=
 github.com/elazarl/goproxy v0.0.0-20180725130230-947c36da3153/go.mod h1:/Zj4wYkgs4iZTTu3o/KG3Itv/qCCa8VVMlb3i9OVuzc=
 github.com/emicklei/go-restful v0.0.0-20170410110728-ff4f55a20633/go.mod h1:otzb+WCGbkyDHkqmQmT5YD2WR4BBwUdeQoFo8l/7tVs=
@@ -231,8 +230,8 @@ github.com/evanphx/json-patch v4.12.0+incompatible/go.mod h1:50XU6AFN0ol/bzJsmQL
 github.com/evanphx/json-patch v5.6.0+incompatible h1:jBYDEEiFBPxA0v50tFdvOzQQTCvpL6mnFh5mB2/l16U=
 github.com/evanphx/json-patch v5.6.0+incompatible/go.mod h1:50XU6AFN0ol/bzJsmQLiYLvXMP4fmwYFNcr97nuDLSk=
 github.com/fatih/color v1.7.0/go.mod h1:Zm6kSWBoL9eyXnKyktHP6abPY2pDugNf5KwzbycvMj4=
-github.com/fatih/color v1.13.0 h1:8LOYc1KYPPmyKMuN8QV2DNRWNbLo6LZ0iLs8+mlH53w=
-github.com/fatih/color v1.13.0/go.mod h1:kLAiJbzzSOZDVNGyDpeOxJ47H46qBXwg5ILebYFFOfk=
+github.com/fatih/color v1.15.0 h1:kOqh6YHBtK8aywxGerMG2Eq3H6Qgoqeo13Bk2Mv/nBs=
+github.com/fatih/color v1.15.0/go.mod h1:0h5ZqXfHYED7Bhv2ZJamyIOUej9KtShiJESRwBDUSsw=
 github.com/felixge/httpsnoop v1.0.1/go.mod h1:m8KPJKqk1gH5J9DgRY2ASl2lWCfGKXixSwevea8zH2U=
 github.com/flowstack/go-jsonschema v0.1.1/go.mod h1:yL7fNggx1o8rm9RlgXv7hTBWxdBM0rVwpMwimd3F3N0=
 github.com/form3tech-oss/jwt-go v3.2.2+incompatible/go.mod h1:pbq4aXjuKjdthFRnoDwaVPLA+WlJuPGy+QneDUgJi2k=
@@ -254,17 +253,18 @@ github.com/go-gl/glfw/v3.3/glfw v0.0.0-20200222043503-6f7a984d4dc4/go.mod h1:tQ2
 github.com/go-kit/kit v0.8.0/go.mod h1:xBxKIO96dXMWWy0MnWVtmwkA9/13aqxPnvrjFYMA2as=
 github.com/go-kit/kit v0.9.0/go.mod h1:xBxKIO96dXMWWy0MnWVtmwkA9/13aqxPnvrjFYMA2as=
 github.com/go-kit/log v0.1.0/go.mod h1:zbhenjAZHb184qTLMA9ZjW7ThYL0H2mk7Q6pNt4vbaY=
-github.com/go-kit/log v0.2.0/go.mod h1:NwTd00d/i8cPZ3xOwwiv2PO5MOcx78fFErGNcVmBjv0=
 github.com/go-logfmt/logfmt v0.3.0/go.mod h1:Qt1PoO58o5twSAckw1HlFXLmHsOX5/0LbT9GBnD5lWE=
 github.com/go-logfmt/logfmt v0.4.0/go.mod h1:3RMwSq7FuexP4Kalkev3ejPJsZTpXXBr9+V4qmtdjCk=
 github.com/go-logfmt/logfmt v0.5.0/go.mod h1:wCYkCAKZfumFQihp8CzCvQ3paCTfi41vtzG1KdI/P7A=
-github.com/go-logfmt/logfmt v0.5.1/go.mod h1:WYhtIu8zTZfxdn5+rREduYbwxfcBr/Vr6KEVveWlfTs=
 github.com/go-logr/logr v0.1.0/go.mod h1:ixOQHD9gLJUVQQ2ZOR7zLEifBX6tGkNJF4QyIY7sIas=
 github.com/go-logr/logr v0.2.0/go.mod h1:z6/tIYblkpsD+a4lm/fGIIU9mZ+XfAiaFtq7xTgseGU=
 github.com/go-logr/logr v0.4.0/go.mod h1:z6/tIYblkpsD+a4lm/fGIIU9mZ+XfAiaFtq7xTgseGU=
 github.com/go-logr/logr v1.2.0/go.mod h1:jdQByPbusPIv2/zmleS9BjJVeZ6kBagPoEUsqbVz/1A=
+github.com/go-logr/logr v1.2.2/go.mod h1:jdQByPbusPIv2/zmleS9BjJVeZ6kBagPoEUsqbVz/1A=
 github.com/go-logr/logr v1.2.3 h1:2DntVwHkVopvECVRSlL5PSo9eG+cAkDCuckLubN+rq0=
 github.com/go-logr/logr v1.2.3/go.mod h1:jdQByPbusPIv2/zmleS9BjJVeZ6kBagPoEUsqbVz/1A=
+github.com/go-logr/stdr v1.2.2 h1:hSWxHoqTgW2S2qGc0LTAI563KZ5YKYRhT3MFKZMbjag=
+github.com/go-logr/stdr v1.2.2/go.mod h1:mMo/vtBO5dYbehREoey6XUKy/eSumjCCveDpRre4VKE=
 github.com/go-logr/zapr v1.2.0 h1:n4JnPI1T3Qq1SFEi/F8rwLrZERp2bso19PJZDB9dayk=
 github.com/go-logr/zapr v1.2.0/go.mod h1:Qa4Bsj2Vb+FAVeAKsLD8RLQ+YRJB8YDmOAKxaBQf7Ro=
 github.com/go-openapi/jsonpointer v0.0.0-20160704185906-46af16f9f7b1/go.mod h1:+35s3my2LFTysnkMfxsJBAMHj/DoqoB9knIWoYG/Vk0=
@@ -291,6 +291,7 @@ github.com/go-task/slim-sprig v0.0.0-20210107165309-348f09dbbbc0/go.mod h1:fyg78
 github.com/gobwas/glob v0.2.3 h1:A4xDbljILXROh+kObIiy5kIaPYD8e96x1tgBhUI5J+Y=
 github.com/gobwas/glob v0.2.3/go.mod h1:d3Ez4x06l9bZtSvzIay5+Yzi0fmZzPgnTbPcKjJAkT8=
 github.com/godbus/dbus/v5 v5.0.4/go.mod h1:xhWf0FNVPg57R7Z0UbKHbJfkEywrmjJnf7w5xrFpKfA=
+github.com/godbus/dbus/v5 v5.1.0 h1:4KLkAxT3aOY8Li4FRJe/KvhoNFFxo0m6fNuFUO8QJUk=
 github.com/gofrs/flock v0.8.1 h1:+gYjHKf32LDeiEEFhQaotPbLuUXjY5ZqxKgXy7n59aw=
 github.com/gofrs/flock v0.8.1/go.mod h1:F1TvTiK9OcQqauNUHlbJvyl9Qa1QvF/gOUDKA14jxHU=
 github.com/gogo/protobuf v1.1.1/go.mod h1:r8qH/GZQm5c6nD/R0oafs1akxWv10x8SbQlK7atdtwQ=
@@ -299,8 +300,9 @@ github.com/gogo/protobuf v1.3.1/go.mod h1:SlYgWuQ5SjCEi6WLHjHCa1yvBfUnHcTbrrZtXP
 github.com/gogo/protobuf v1.3.2 h1:Ov1cvc58UF3b5XjBnZv7+opcTcQFZebYjWzi34vdm4Q=
 github.com/gogo/protobuf v1.3.2/go.mod h1:P1XiOD3dCwIKUDQYPy72D8LYyHL2YPYrpS2s69NZV8Q=
 github.com/golang-jwt/jwt/v4 v4.0.0/go.mod h1:/xlHOz8bRuivTWchD4jCa+NbatV+wEUSzwAxVc6locg=
-github.com/golang-jwt/jwt/v4 v4.4.1 h1:pC5DB52sCeK48Wlb9oPcdhnjkz1TKt1D/P7WKJ0kUcQ=
-github.com/golang-jwt/jwt/v4 v4.4.1/go.mod h1:m21LjoU+eqJr34lmDMbreY2eSTRJ1cv77w39/MY0Ch0=
+github.com/golang-jwt/jwt/v4 v4.2.0/go.mod h1:/xlHOz8bRuivTWchD4jCa+NbatV+wEUSzwAxVc6locg=
+github.com/golang-jwt/jwt/v4 v4.5.0 h1:7cYmW1XlMY7h7ii7UhUyChSgS5wUJEnm9uZVTGqOWzg=
+github.com/golang-jwt/jwt/v4 v4.5.0/go.mod h1:m21LjoU+eqJr34lmDMbreY2eSTRJ1cv77w39/MY0Ch0=
 github.com/golang/glog v0.0.0-20160126235308-23def4e6c14b/go.mod h1:SBH7ygxi8pfUlaOkMMuAQtPIUF8ecWP5IEl/CR7VP2Q=
 github.com/golang/glog v1.0.0/go.mod h1:EWib/APOK0SL3dFbYqvxE3UYd8E6s1ouQ7iEp/0LWV4=
 github.com/golang/groupcache v0.0.0-20160516000752-02826c3e7903/go.mod h1:cIg4eruTrX1D+g88fzRXU5OdNfaM+9IcxsU14FzY7Hc=
@@ -318,7 +320,6 @@ github.com/golang/mock v1.4.1/go.mod h1:UOMv5ysSaYNkG+OFQykRIcU/QvvxJf3p21QfJ2Bt
 github.com/golang/mock v1.4.3/go.mod h1:UOMv5ysSaYNkG+OFQykRIcU/QvvxJf3p21QfJ2Bt3cw=
 github.com/golang/mock v1.4.4/go.mod h1:l3mdAwkq5BuhzHwde/uurv3sEJeZMXNpwsxVWU71h+4=
 github.com/golang/mock v1.5.0/go.mod h1:CWnOUgYIOo4TcNZ0wHX3YZCqsaM1I1Jvs6v3mP3KVu8=
-github.com/golang/mock v1.6.0/go.mod h1:p6yTPP+5HYm5mzsMV8JkE6ZKdX+/wYM6Hr+LicevLPs=
 github.com/golang/protobuf v1.2.0/go.mod h1:6lQm79b+lXiMfvg/cZm0SGofjICqVBUtrP5yJMmIC1U=
 github.com/golang/protobuf v1.3.1/go.mod h1:6lQm79b+lXiMfvg/cZm0SGofjICqVBUtrP5yJMmIC1U=
 github.com/golang/protobuf v1.3.2/go.mod h1:6lQm79b+lXiMfvg/cZm0SGofjICqVBUtrP5yJMmIC1U=
@@ -335,9 +336,9 @@ github.com/golang/protobuf v1.4.2/go.mod h1:oDoupMAO8OvCJWAcko0GGGIgR6R6ocIYbsSw
 github.com/golang/protobuf v1.4.3/go.mod h1:oDoupMAO8OvCJWAcko0GGGIgR6R6ocIYbsSw735rRwI=
 github.com/golang/protobuf v1.5.0/go.mod h1:FsONVRAS9T7sI+LIUmWTfcYkHO4aIWwzhcaSAoJOfIk=
 github.com/golang/protobuf v1.5.1/go.mod h1:DopwsBzvsk0Fs44TXzsVbJyPhcCPeIwnvohx4u74HPM=
-github.com/golang/protobuf v1.5.2 h1:ROPKBNFfQgOUMifHyP+KYbvpjbdoFNs+aK7DXlji0Tw=
 github.com/golang/protobuf v1.5.2/go.mod h1:XVQd3VNwM+JqD3oG2Ue2ip4fOMUkwXdXDdiuN0vRsmY=
-github.com/golang/snappy v0.0.3/go.mod h1:/XxbfmMg8lxefKM7IXC3fBNl/7bRcc72aCRzEWrmP2Q=
+github.com/golang/protobuf v1.5.3 h1:KhyjKVUg7Usr/dYsdSqoFveMYd5ko72D+zANwlG1mmg=
+github.com/golang/protobuf v1.5.3/go.mod h1:XVQd3VNwM+JqD3oG2Ue2ip4fOMUkwXdXDdiuN0vRsmY=
 github.com/google/btree v0.0.0-20180813153112-4030bb1f1f0c/go.mod h1:lNA+9X1NB3Zf8V7Ke586lFgjr2dZNuvo3lPJSGZ5JPQ=
 github.com/google/btree v1.0.0/go.mod h1:lNA+9X1NB3Zf8V7Ke586lFgjr2dZNuvo3lPJSGZ5JPQ=
 github.com/google/btree v1.0.1/go.mod h1:xXMiIv4Fb/0kKde4SpL7qlzvu5cMJDRkFDxJfI9uaxA=
@@ -358,9 +359,8 @@ github.com/google/go-cmp v0.5.3/go.mod h1:v8dTdLbMG2kIc/vJvl+f65V22dbkXbowE6jgT/
 github.com/google/go-cmp v0.5.4/go.mod h1:v8dTdLbMG2kIc/vJvl+f65V22dbkXbowE6jgT/gNBxE=
 github.com/google/go-cmp v0.5.5/go.mod h1:v8dTdLbMG2kIc/vJvl+f65V22dbkXbowE6jgT/gNBxE=
 github.com/google/go-cmp v0.5.6/go.mod h1:v8dTdLbMG2kIc/vJvl+f65V22dbkXbowE6jgT/gNBxE=
-github.com/google/go-cmp v0.5.7/go.mod h1:n+brtR0CgQNWTVd5ZUFpTBC8YFBDLK/h/bpaJ8/DtOE=
-github.com/google/go-cmp v0.5.8 h1:e6P7q2lk1O+qJJb4BtCQXlK8vWEO8V1ZeuEdJNOqZyg=
-github.com/google/go-cmp v0.5.8/go.mod h1:17dUlkBOakJ0+DkrSSNjCkIjxS6bF9zb3elmeNGIjoY=
+github.com/google/go-cmp v0.5.9 h1:O2Tfq5qg4qc4AmwVlvv0oLiVAGB7enBSJ2x2DqQFi38=
+github.com/google/go-cmp v0.5.9/go.mod h1:17dUlkBOakJ0+DkrSSNjCkIjxS6bF9zb3elmeNGIjoY=
 github.com/google/gofuzz v1.0.0/go.mod h1:dBl0BpW6vV/+mYPU4Po3pmUjxk6FQPldtuIdl/M65Eg=
 github.com/google/gofuzz v1.1.0/go.mod h1:dBl0BpW6vV/+mYPU4Po3pmUjxk6FQPldtuIdl/M65Eg=
 github.com/google/gofuzz v1.2.0 h1:xRy4A+RhZaiKjJ1bPfwQ8sedCA+YS2YcCHW6ec7JMi0=
@@ -369,8 +369,7 @@ github.com/google/martian v2.1.0+incompatible h1:/CP5g8u/VJHijgedC/Legn3BAbAaWPg
 github.com/google/martian v2.1.0+incompatible/go.mod h1:9I4somxYTbIHy5NJKHRl3wXiIaQGbYVAs8BPL6v8lEs=
 github.com/google/martian/v3 v3.0.0/go.mod h1:y5Zk1BBys9G+gd6Jrk0W3cC1+ELVxBWuIGO+w/tUAp0=
 github.com/google/martian/v3 v3.1.0/go.mod h1:y5Zk1BBys9G+gd6Jrk0W3cC1+ELVxBWuIGO+w/tUAp0=
-github.com/google/martian/v3 v3.2.1 h1:d8MncMlErDFTwQGBK1xhv026j9kqhvw1Qv9IbWT1VLQ=
-github.com/google/martian/v3 v3.2.1/go.mod h1:oBOf6HBosgwRXnUGWUB05QECsc6uvmMiJ3+6W4l/CUk=
+github.com/google/martian/v3 v3.3.2 h1:IqNFLAmvJOgVlpdEBiQbDc2EwKW77amAycfTuWKdfvw=
 github.com/google/pprof v0.0.0-20181206194817-3ea8567a2e57/go.mod h1:zfwlbNMJ+OItoe0UupaVj+oy1omPYYDuagoSzA8v9mc=
 github.com/google/pprof v0.0.0-20190515194954-54271f7e092f/go.mod h1:zfwlbNMJ+OItoe0UupaVj+oy1omPYYDuagoSzA8v9mc=
 github.com/google/pprof v0.0.0-20191218002539-d4f498aebedc/go.mod h1:ZgVRPoUq/hfqzAqh7sHMqb3I9Rq5C59dIz2SbBwJ4eM=
@@ -382,11 +381,9 @@ github.com/google/pprof v0.0.0-20201023163331-3e6fc7fc9c4c/go.mod h1:kpwsk12EmLe
 github.com/google/pprof v0.0.0-20201203190320-1bf35d6f28c2/go.mod h1:kpwsk12EmLew5upagYY7GY0pfYCcupk39gWOCRROcvE=
 github.com/google/pprof v0.0.0-20210122040257-d980be63207e/go.mod h1:kpwsk12EmLew5upagYY7GY0pfYCcupk39gWOCRROcvE=
 github.com/google/pprof v0.0.0-20210226084205-cbba55b83ad5/go.mod h1:kpwsk12EmLew5upagYY7GY0pfYCcupk39gWOCRROcvE=
-github.com/google/pprof v0.0.0-20210407192527-94a9f03dee38/go.mod h1:kpwsk12EmLew5upagYY7GY0pfYCcupk39gWOCRROcvE=
-github.com/google/pprof v0.0.0-20210601050228-01bbb1931b22/go.mod h1:kpwsk12EmLew5upagYY7GY0pfYCcupk39gWOCRROcvE=
-github.com/google/pprof v0.0.0-20210609004039-a478d1d731e9/go.mod h1:kpwsk12EmLew5upagYY7GY0pfYCcupk39gWOCRROcvE=
-github.com/google/pprof v0.0.0-20210720184732-4bb14d4b1be1/go.mod h1:kpwsk12EmLew5upagYY7GY0pfYCcupk39gWOCRROcvE=
 github.com/google/renameio v0.1.0/go.mod h1:KWCgfxg9yswjAJkECMjeO8J8rahYeXnNhOm40UhjYkI=
+github.com/google/s2a-go v0.1.2 h1:WVtYAYuYxKeYajAmThMRYWP6K3wXkcqbGHeUgeubUHY=
+github.com/google/s2a-go v0.1.2/go.mod h1:OJpEgntRZo8ugHpF9hkoLJbS5dSI20XZeXJ9JVywLlM=
 github.com/google/shlex v0.0.0-20191202100458-e7afc7fbc510/go.mod h1:pupxD2MaaD3pAXIBCelhxNneeOaAeabZDe5s4K6zSpQ=
 github.com/google/uuid v1.0.0/go.mod h1:TIyPZe4MgqvfeYDBFedMoGGpEw/LqOeaOT+nhxU+yHo=
 github.com/google/uuid v1.1.1/go.mod h1:TIyPZe4MgqvfeYDBFedMoGGpEw/LqOeaOT+nhxU+yHo=
@@ -394,16 +391,17 @@ github.com/google/uuid v1.1.2/go.mod h1:TIyPZe4MgqvfeYDBFedMoGGpEw/LqOeaOT+nhxU+
 github.com/google/uuid v1.2.0/go.mod h1:TIyPZe4MgqvfeYDBFedMoGGpEw/LqOeaOT+nhxU+yHo=
 github.com/google/uuid v1.3.0 h1:t6JiXgmwXMjEs8VusXIJk2BXHsn+wx8BZdTaoZ5fu7I=
 github.com/google/uuid v1.3.0/go.mod h1:TIyPZe4MgqvfeYDBFedMoGGpEw/LqOeaOT+nhxU+yHo=
+github.com/googleapis/enterprise-certificate-proxy v0.2.3 h1:yk9/cqRKtT9wXZSsRH9aurXEpJX+U6FLtpYTdC3R06k=
+github.com/googleapis/enterprise-certificate-proxy v0.2.3/go.mod h1:AwSRAtLfXpU5Nm3pW+v7rGDHp09LsPtGY9MduiEsR9k=
 github.com/googleapis/gax-go/v2 v2.0.4/go.mod h1:0Wqv26UfaUD9n4G6kQubkQ+KchISgw+vpHVxEJEs9eg=
 github.com/googleapis/gax-go/v2 v2.0.5/go.mod h1:DWXyrwAJ9X0FpwwEdw+IPEYBICEFu5mhpdKc/us6bOk=
-github.com/googleapis/gax-go/v2 v2.1.0/go.mod h1:Q3nei7sK6ybPYH7twZdmQpAd1MKb7pfu6SK+H1/DsU0=
-github.com/googleapis/gax-go/v2 v2.1.1/go.mod h1:hddJymUZASv3XPyGkUpKj8pPO47Rmb0eJc8R6ouapiM=
-github.com/googleapis/gax-go/v2 v2.2.0 h1:s7jOdKSaksJVOxE0Y/S32otcfiP+UQ0cL8/GTKaONwE=
-github.com/googleapis/gax-go/v2 v2.2.0/go.mod h1:as02EH8zWkzwUoLbBaFeQ+arQaj/OthfcblKl4IGNaM=
+github.com/googleapis/gax-go/v2 v2.8.0 h1:UBtEZqx1bjXtOQ5BVTkuYghXrr3N4V123VKJK67vJZc=
+github.com/googleapis/gax-go/v2 v2.8.0/go.mod h1:4orTrqY6hXxxaUL4LHIPl6lGo8vAE38/qKbhSAKP6QI=
 github.com/googleapis/gnostic v0.4.1/go.mod h1:LRhVm6pbyptWbWbuZ38d1eyptfvIytN3ir6b65WBswg=
 github.com/googleapis/gnostic v0.5.1/go.mod h1:6U4PtQXGIEt/Z3h5MAT7FNofLnw9vXk2cUuW7uA/OeU=
 github.com/googleapis/gnostic v0.5.5/go.mod h1:7+EbHbldMins07ALC74bsA81Ovc97DwqyJO1AENw9kA=
 github.com/gopherjs/gopherjs v0.0.0-20181017120253-0766667cb4d1/go.mod h1:wJfORRmW1u3UXTncJ5qlYoELFm8eSnnEO6hX4iZ3EWY=
+github.com/gorilla/mux v1.8.0 h1:i40aqfkR1h2SlN9hojwV5ZA91wcXFOvkdNIeFDP5koI=
 github.com/gorilla/mux v1.8.0/go.mod h1:DVbg23sWSpFRCP0SfiEN6jmj59UnW/n46BH5rLB71So=
 github.com/gorilla/websocket v0.0.0-20170926233335-4201258b820c/go.mod h1:E7qHFY5m1UJ88s3WnNqhKjPHQ0heANvMoAMk2YaljkQ=
 github.com/gorilla/websocket v1.4.0/go.mod h1:E7qHFY5m1UJ88s3WnNqhKjPHQ0heANvMoAMk2YaljkQ=
@@ -416,6 +414,7 @@ github.com/grpc-ecosystem/go-grpc-prometheus v1.2.0/go.mod h1:8NvIoxWQoOIhqOTXgf
 github.com/grpc-ecosystem/grpc-gateway v1.9.0/go.mod h1:vNeuVxBJEsws4ogUvrchl83t/GYV9WGTSLVdBhOQFDY=
 github.com/grpc-ecosystem/grpc-gateway v1.9.5/go.mod h1:vNeuVxBJEsws4ogUvrchl83t/GYV9WGTSLVdBhOQFDY=
 github.com/grpc-ecosystem/grpc-gateway v1.16.0/go.mod h1:BDjrQk3hbvj6Nolgz8mAMFbcEtjT1g+wF4CSlocrBnw=
+github.com/hanwen/go-fuse/v2 v2.3.0 h1:t5ivNIH2PK+zw4OBul/iJjsoG9K6kXo4nMDoBpciC8A=
 github.com/hashicorp/consul/api v1.1.0/go.mod h1:VmuI/Lkw1nC05EYQWNKwWGbkg+FbDBtguAZLlVdkD9Q=
 github.com/hashicorp/consul/sdk v0.1.1/go.mod h1:VKf9jXwCTEY1QZP2MOLRhb5i/I/ssyNV1vwHyQBF0x8=
 github.com/hashicorp/errwrap v1.0.0/go.mod h1:YH+1FKiLXxHSkmPseP+kNlulaMuP3n2brvKWEqk/Jc4=
@@ -435,8 +434,6 @@ github.com/hashicorp/go-uuid v1.0.1/go.mod h1:6SBZvOh/SIDV7/2o3Jml5SYk/TvGqwFJ/b
 github.com/hashicorp/go.net v0.0.1/go.mod h1:hjKkEWcCURg++eb33jQU7oqQcI9XDCnUzHA0oac0k90=
 github.com/hashicorp/golang-lru v0.5.0/go.mod h1:/m3WP610KZHVQ1SGc6re/UDhFvYD7pJ4Ao+sR/qLZy8=
 github.com/hashicorp/golang-lru v0.5.1/go.mod h1:/m3WP610KZHVQ1SGc6re/UDhFvYD7pJ4Ao+sR/qLZy8=
-github.com/hashicorp/golang-lru v0.5.4 h1:YDjusn29QI/Das2iO9M0BHnIbxPeyuCHsjMW+lJfyTc=
-github.com/hashicorp/golang-lru v0.5.4/go.mod h1:iADmTwqILo4mZ8BN3D2Q6+9jd8WM5uGBxy+E8yxSoD4=
 github.com/hashicorp/hcl v1.0.0/go.mod h1:E5yfLk+7swimpb2L/Alb/PJmXilQ/rhwaUYs4T20WEQ=
 github.com/hashicorp/logutils v1.0.0/go.mod h1:QIAnNjmIWmVIIkWDTG1z5v++HQmx9WQRO+LraFDTW64=
 github.com/hashicorp/mdns v1.0.0/go.mod h1:tL+uN++7HEJ6SQLQ2/p+z2pH24WQKWjBPkE0mNTz8vQ=
@@ -482,25 +479,26 @@ github.com/kisielk/errcheck v1.1.0/go.mod h1:EZBBE59ingxPouuu3KfxchcWSUPOHkagtvW
 github.com/kisielk/errcheck v1.2.0/go.mod h1:/BMXB+zMLi60iA8Vv6Ksmxu/1UDYcXs4uQLJ+jE2L00=
 github.com/kisielk/errcheck v1.5.0/go.mod h1:pFxgyoBC7bSaBwPgfKdkLd5X25qrDl4LWUI2bnpBCr8=
 github.com/kisielk/gotool v1.0.0/go.mod h1:XhKaO+MFFWcvkIS/tQcRk01m1F5IRFswLeQ+oQHNcck=
-github.com/klauspost/compress v1.15.1 h1:y9FcTHGyrebwfP0ZZqFiaxTaiDnUrGkJkI+f583BL1A=
-github.com/klauspost/compress v1.15.1/go.mod h1:/3/Vjq9QcHkK5uEr5lBEmyoZ1iFhe47etQ6QUkpK6sk=
+github.com/klauspost/compress v1.16.5 h1:IFV2oUNUzZaz+XyusxpLzpzS8Pt5rh0Z16For/djlyI=
+github.com/klauspost/compress v1.16.5/go.mod h1:ntbaceVETuRiXiv4DpjP66DpAtAGkEQskQzEyD//IeE=
 github.com/klauspost/cpuid/v2 v2.0.1/go.mod h1:FInQzS24/EEf25PyTYn52gqo7WaD8xa0213Md/qVLRg=
 github.com/klauspost/cpuid/v2 v2.0.4/go.mod h1:FInQzS24/EEf25PyTYn52gqo7WaD8xa0213Md/qVLRg=
-github.com/klauspost/cpuid/v2 v2.0.12 h1:p9dKCg8i4gmOxtv35DvrYoWqYzQrvEVdjQ762Y0OqZE=
 github.com/klauspost/cpuid/v2 v2.0.12/go.mod h1:g2LTdtYhdyuGPqyWyv7qRAmj1WBqxuObKfj5c0PQa7c=
+github.com/klauspost/cpuid/v2 v2.2.4 h1:acbojRNwl3o09bUq+yDCtZFc1aiwaAAxtcn8YkZXnvk=
+github.com/klauspost/cpuid/v2 v2.2.4/go.mod h1:RVVoqg1df56z8g3pUjL/3lE5UfnlrJX8tyFgg4nqhuY=
 github.com/klauspost/pgzip v1.2.5 h1:qnWYvvKqedOF2ulHpMG72XQol4ILEJ8k2wwRl/Km8oE=
 github.com/klauspost/pgzip v1.2.5/go.mod h1:Ch1tH69qFZu15pkjo5kYi6mth2Zzwzt50oCQKQE9RUs=
+github.com/klauspost/reedsolomon v1.11.7 h1:9uaHU0slncktTEEg4+7Vl7q7XUNMBUOK4R9gnKhMjAU=
+github.com/klauspost/reedsolomon v1.11.7/go.mod h1:4bXRN+cVzMdml6ti7qLouuYi32KHJ5MGv0Qd8a47h6A=
 github.com/konsorten/go-windows-terminal-sequences v1.0.1/go.mod h1:T0+1ngSBFLxvqU3pZ+m/2kptfBszLMUkC4ZK/EgS/cQ=
 github.com/konsorten/go-windows-terminal-sequences v1.0.3/go.mod h1:T0+1ngSBFLxvqU3pZ+m/2kptfBszLMUkC4ZK/EgS/cQ=
-github.com/kopia/kopia v0.10.7 h1:6s0ZIZW3Ge2ozzefddASy7CIUadp/5tF9yCDKQfAKKI=
-github.com/kopia/kopia v0.10.7/go.mod h1:0d9THPD+jwomPcXvPbCdmLyX6phQVP7AqcCcDEajfNA=
+github.com/kopia/htmluibuild v0.0.0-20230326183719-f482ef17e2c9 h1:s5Wa89s8RlPjuwqd8K8kuf+T9Kz4+NsbKwR/pJ3PAT0=
 github.com/kr/fs v0.1.0/go.mod h1:FFnZGqtBN9Gxj7eW1uZ42v5BccTP0vu6NEaFoC2HwRg=
 github.com/kr/logfmt v0.0.0-20140226030751-b84e30acd515/go.mod h1:+0opPa2QZZtGFBFZlji/RkVcI2GknAs/DXo4wKdlNEc=
 github.com/kr/pretty v0.1.0/go.mod h1:dAy3ld7l9f0ibDNOQOHHMYYIIbhfbHSm3C4ZsoJORNo=
 github.com/kr/pretty v0.2.0/go.mod h1:ipq/a2n7PKx3OHsz4KJII5eveXtPO4qwEXGdVfWzfnI=
 github.com/kr/pretty v0.2.1/go.mod h1:ipq/a2n7PKx3OHsz4KJII5eveXtPO4qwEXGdVfWzfnI=
-github.com/kr/pretty v0.3.0 h1:WgNl7dwNpEZ6jJ9k1snq4pZsg7DOEN8hP9Xw0Tsjwk0=
-github.com/kr/pretty v0.3.0/go.mod h1:640gp4NfQd8pI5XOwp5fnNeVWj67G7CFk/SaSQn7NBk=
+github.com/kr/pretty v0.3.1 h1:flRD4NNwYAUpkphVc1HcthR4KEIFJ65n8Mw5qdRn3LE=
 github.com/kr/pty v1.1.1/go.mod h1:pFQYn66WHrOpPYNljwOMqo10TkYh1fy3cYio2l3bCsQ=
 github.com/kr/pty v1.1.5/go.mod h1:9r2w37qlBe7rQ6e1fg1S/9xpWHSnaqNdHD3WcMdbPDA=
 github.com/kr/text v0.1.0/go.mod h1:4Jbv+DJW3UT/LiOwJeYQe1efqtUx/iVham/4vfdArNI=
@@ -523,27 +521,27 @@ github.com/mailru/easyjson v0.7.7 h1:UGYAvKxe3sBsEDzO8ZeWOSlIQfWFlxbzLZe7hwFURr0
 github.com/mailru/easyjson v0.7.7/go.mod h1:xzfreul335JAWq5oZzymOObrkdz5UnU4kGfJJLY9Nlc=
 github.com/mattn/go-colorable v0.0.9/go.mod h1:9vuHe8Xs5qXnSaW/c/ABM9alt+Vo+STaOChaDxuIBZU=
 github.com/mattn/go-colorable v0.1.4/go.mod h1:U0ppj6V5qS13XJ6of8GYAs25YV2eR4EVcfRqFIhoBtE=
-github.com/mattn/go-colorable v0.1.9/go.mod h1:u6P/XSegPjTcexA+o6vUJrdnUu04hMope9wVRipJSqc=
-github.com/mattn/go-colorable v0.1.12 h1:jF+Du6AlPIjs2BiUiQlKOX0rt3SujHxPnksPKZbaA40=
-github.com/mattn/go-colorable v0.1.12/go.mod h1:u5H1YNBxpqRaxsYJYSkiCWKzEfiAb1Gb520KVy5xxl4=
+github.com/mattn/go-colorable v0.1.13 h1:fFA4WZxdEF4tXPZVKMLwD8oUnCTTo08duU7wxecdEvA=
+github.com/mattn/go-colorable v0.1.13/go.mod h1:7S9/ev0klgBDR4GtXTXX8a3vIGJpMovkB8vQcUbaXHg=
 github.com/mattn/go-ieproxy v0.0.1 h1:qiyop7gCflfhwCzGyeT0gro3sF9AIg9HU98JORTkqfI=
 github.com/mattn/go-ieproxy v0.0.1/go.mod h1:pYabZ6IHcRpFh7vIaLfK7rdcWgFEb3SFJ6/gNWuh88E=
 github.com/mattn/go-isatty v0.0.3/go.mod h1:M+lRXTBqGeGNdLjl/ufCoiOlB5xdOkqRJdNxMWT7Zi4=
 github.com/mattn/go-isatty v0.0.4/go.mod h1:M+lRXTBqGeGNdLjl/ufCoiOlB5xdOkqRJdNxMWT7Zi4=
 github.com/mattn/go-isatty v0.0.8/go.mod h1:Iq45c/XA43vh69/j3iqttzPXn0bhXyGjM0Hdxcsrc5s=
 github.com/mattn/go-isatty v0.0.10/go.mod h1:qgIWMr58cqv1PHHyhnkY9lrL7etaEgOFcMEpPG5Rm84=
-github.com/mattn/go-isatty v0.0.12/go.mod h1:cbi8OIDigv2wuxKPP5vlRcQ1OAZbq2CE4Kysco4FUpU=
-github.com/mattn/go-isatty v0.0.14 h1:yVuAays6BHfxijgZPzw+3Zlu5yQgKGP2/hcQbHb7S9Y=
-github.com/mattn/go-isatty v0.0.14/go.mod h1:7GGIvUiUoEMVVmxf/4nioHXj79iQHKdU27kJ6hsGG94=
+github.com/mattn/go-isatty v0.0.16/go.mod h1:kYGgaQfpe5nmfYZH+SKPsOc2e4SrIfOl2e/yFXSvRLM=
+github.com/mattn/go-isatty v0.0.17 h1:BTarxUcIeDqL27Mc+vyvdWYSL28zpIhv3RoTdsLMPng=
+github.com/mattn/go-isatty v0.0.17/go.mod h1:kYGgaQfpe5nmfYZH+SKPsOc2e4SrIfOl2e/yFXSvRLM=
 github.com/mattn/go-runewidth v0.0.2/go.mod h1:LwmH8dsx7+W8Uxz3IHJYH5QSwggIsqBzpuz5H//U1FU=
 github.com/matttproud/golang_protobuf_extensions v1.0.1/go.mod h1:D8He9yQNgCq6Z5Ld7szi9bcBfOoFv/3dc6xSMkL2PC0=
-github.com/matttproud/golang_protobuf_extensions v1.0.2-0.20181231171920-c182affec369 h1:I0XW9+e1XWDxdcEniV4rQAIOPUGDq67JSCiRCgGCZLI=
 github.com/matttproud/golang_protobuf_extensions v1.0.2-0.20181231171920-c182affec369/go.mod h1:BSXmuO+STAnVfrANrmjBb36TMTDstsz7MSK+HVaYKv4=
+github.com/matttproud/golang_protobuf_extensions v1.0.4 h1:mmDVorXM7PCGKw94cs5zkfA9PSy5pEvNWRP0ET0TIVo=
+github.com/matttproud/golang_protobuf_extensions v1.0.4/go.mod h1:BSXmuO+STAnVfrANrmjBb36TMTDstsz7MSK+HVaYKv4=
 github.com/miekg/dns v1.0.14/go.mod h1:W1PPwlIAgtquWBMBEV9nkV9Cazfe8ScdGz/Lj7v3Nrg=
 github.com/minio/md5-simd v1.1.2 h1:Gdi1DZK69+ZVMoNHRXJyNcxrMA4dSxoYHZSQbirFg34=
 github.com/minio/md5-simd v1.1.2/go.mod h1:MzdKDxYpY2BT9XQFocsiZf/NKVtR7nkE4RoEpN+20RM=
-github.com/minio/minio-go/v7 v7.0.23 h1:NleyGQvAn9VQMU+YHVrgV4CX+EPtxPt/78lHOOTncy4=
-github.com/minio/minio-go/v7 v7.0.23/go.mod h1:ei5JjmxwHaMrgsMrn4U/+Nmg+d8MKS1U2DAn1ou4+Do=
+github.com/minio/minio-go/v7 v7.0.52 h1:8XhG36F6oKQUDDSuz6dY3rioMzovKjW40W6ANuN0Dps=
+github.com/minio/minio-go/v7 v7.0.52/go.mod h1:IbbodHyjUAguneyucUaahv+VMNs/EOTV9du7A7/Z3HU=
 github.com/minio/sha256-simd v1.0.0 h1:v1ta+49hkWZyvaKwrQB8elexRqm6Y0aMLjCNsrYxo6g=
 github.com/minio/sha256-simd v1.0.0/go.mod h1:OuYzVNI5vcoYIAmbIvHPl3N3jUzVedXbKy5RFepssQM=
 github.com/mitchellh/cli v1.0.0/go.mod h1:hNIlj7HEI86fIcpObd7a0FcrxTWetlwJDGcceTlRvqc=
@@ -592,18 +590,15 @@ github.com/onsi/ginkgo v1.6.0/go.mod h1:lLunBs/Ym6LB5Z9jYTR76FiuTmxDTDusOGeTQH+W
 github.com/onsi/ginkgo v1.11.0/go.mod h1:lLunBs/Ym6LB5Z9jYTR76FiuTmxDTDusOGeTQH+WWjE=
 github.com/onsi/ginkgo v1.12.1/go.mod h1:zj2OWP4+oCPe1qIXoGWkgMRwljMUYCdkwsT2108oapk=
 github.com/onsi/ginkgo v1.14.0/go.mod h1:iSB4RoI2tjJc9BBv4NKIKWKya62Rps+oPG/Lv9klQyY=
-github.com/onsi/ginkgo v1.16.4/go.mod h1:dX+/inL/fNMqNlz0e9LfyB9TswhZpCVdJM/Z6Vvnwo0=
 github.com/onsi/ginkgo v1.16.5 h1:8xi0RTUf59SOSfEtZMvwTvXYMzG4gV23XVHOZiXNtnE=
 github.com/onsi/ginkgo v1.16.5/go.mod h1:+E8gABHa3K6zRBolWtd+ROzc/U5bkGt0FwiG042wbpU=
-github.com/onsi/ginkgo/v2 v2.0.0 h1:CcuG/HvWNkkaqCUpJifQY8z7qEMBJya6aLPx6ftGyjQ=
-github.com/onsi/ginkgo/v2 v2.0.0/go.mod h1:vw5CSIxN1JObi/U8gcbwft7ZxR2dgaR70JSE3/PpL4c=
+github.com/onsi/ginkgo/v2 v2.1.6 h1:Fx2POJZfKRQcM1pH49qSZiYeu319wji004qX+GDovrU=
 github.com/onsi/gomega v0.0.0-20170829124025-dcabb60a477c/go.mod h1:C1qb7wdrVGGVU+Z6iS04AVkA3Q65CEZX59MT0QO5uiA=
 github.com/onsi/gomega v1.7.0/go.mod h1:ex+gbHU/CVuBBDIJjb2X0qEXbFg53c61hWP/1CpauHY=
 github.com/onsi/gomega v1.7.1/go.mod h1:XdKZgCCFLUoM/7CFJVPcG8C1xQ1AJ0vpAezJrB7JYyY=
 github.com/onsi/gomega v1.10.1/go.mod h1:iN09h71vgCQne3DLsj+A5owkum+a2tYe+TOCB1ybHNo=
-github.com/onsi/gomega v1.17.0/go.mod h1:HnhC7FXeEQY45zxNK3PPoIUhzk/80Xly9PcubAlGdZY=
-github.com/onsi/gomega v1.18.1 h1:M1GfJqGRrBrrGGsbxzV5dqM2U2ApXefZCQpkukxYRLE=
-github.com/onsi/gomega v1.18.1/go.mod h1:0q+aL8jAiMXy9hbwj2mr5GziHiwhAIQpFmmtT5hitRs=
+github.com/onsi/gomega v1.20.1 h1:PA/3qinGoukvymdIDV8pii6tiZgC8kbmJO6Z5+b002Q=
+github.com/onsi/gomega v1.20.1/go.mod h1:DtrZpjmvpn2mPm4YWQa0/ALMDj9v4YxLgojwPeREyVo=
 github.com/opentracing/opentracing-go v1.1.0/go.mod h1:UkNAQd3GIcIGf0SeVgPpRdFStlNbqXla1AfSYxPUl2o=
 github.com/pascaldekloe/goe v0.0.0-20180627143212-57f6aae5913c/go.mod h1:lzWF7FIEvWOWxwDKqyGYQf6ZUaNfKdP144TG7ZOy1lc=
 github.com/pelletier/go-toml v1.2.0/go.mod h1:5z9KED0ma1S8pY6P1sdut58dfprrGBbd/94hg7ilaic=
@@ -620,44 +615,48 @@ github.com/pmezard/go-difflib v1.0.0 h1:4DBwDE0NGyQoBHbLQYPwSUPoCMWR5BEzIk/f1lZb
 github.com/pmezard/go-difflib v1.0.0/go.mod h1:iKH77koFhYxTK1pcRnkKkqfTogsbg7gZNVY4sRDYZ/4=
 github.com/posener/complete v1.1.1/go.mod h1:em0nMJCgc9GFtwrmVmEMR/ZL6WyhyjMBndrE9hABlRI=
 github.com/pquerna/cachecontrol v0.0.0-20171018203845-0dec1b30a021/go.mod h1:prYjPmNq4d1NPVmpShWobRqXY3q7Vp+80DqgxxUrUIA=
+github.com/project-velero/kopia v0.13.0-velero.1 h1:rjiP7os4Eaek/gbyIKqzwkp2XLbJHl0NkczSgJ7AOEo=
+github.com/project-velero/kopia v0.13.0-velero.1/go.mod h1:Iic7CcKhsq+A7MLR9hh6VJfgpcJhLx3Kn+BgjY+azvI=
 github.com/prometheus/client_golang v0.9.1/go.mod h1:7SWBe2y4D6OKWSNQJUaRYU/AaXPKyh/dDVn+NZz0KFw=
 github.com/prometheus/client_golang v0.9.3/go.mod h1:/TN21ttK/J9q6uSwhBd54HahCDft0ttaMvbicHlPoso=
 github.com/prometheus/client_golang v1.0.0/go.mod h1:db9x61etRT2tGnBNRi70OPL5FsnadC4Ky3P0J6CfImo=
 github.com/prometheus/client_golang v1.7.1/go.mod h1:PY5Wy2awLA44sXw4AOSfFBetzPP4j5+D6mVACh+pe2M=
 github.com/prometheus/client_golang v1.11.0/go.mod h1:Z6t4BnS23TR94PD6BsDNk8yVqroYurpAkEiz0P2BEV0=
 github.com/prometheus/client_golang v1.12.1/go.mod h1:3Z9XVyYiZYEO+YQWt3RD2R3jrbd179Rt297l4aS6nDY=
-github.com/prometheus/client_golang v1.12.2 h1:51L9cDoUHVrXx4zWYlcLQIZ+d+VXHgqnYKkIuq4g/34=
-github.com/prometheus/client_golang v1.12.2/go.mod h1:3Z9XVyYiZYEO+YQWt3RD2R3jrbd179Rt297l4aS6nDY=
+github.com/prometheus/client_golang v1.15.0 h1:5fCgGYogn0hFdhyhLbw7hEsWxufKtY9klyvdNfFlFhM=
+github.com/prometheus/client_golang v1.15.0/go.mod h1:e9yaBhRPU2pPNsZwE+JdQl0KEt1N9XgF6zxWmaC0xOk=
 github.com/prometheus/client_model v0.0.0-20180712105110-5c3871d89910/go.mod h1:MbSGuTsp3dbXC40dX6PRTWyKYBIrTGTE9sqQNg2J8bo=
 github.com/prometheus/client_model v0.0.0-20190129233127-fd36f4220a90/go.mod h1:xMI15A0UPsDsEKsMN9yxemIoYk6Tm2C1GtYGdfGttqA=
 github.com/prometheus/client_model v0.0.0-20190812154241-14fe0d1b01d4/go.mod h1:xMI15A0UPsDsEKsMN9yxemIoYk6Tm2C1GtYGdfGttqA=
-github.com/prometheus/client_model v0.2.0 h1:uq5h0d+GuxiXLJLNABMgp2qUWDPiLvgCzz2dUR+/W/M=
 github.com/prometheus/client_model v0.2.0/go.mod h1:xMI15A0UPsDsEKsMN9yxemIoYk6Tm2C1GtYGdfGttqA=
+github.com/prometheus/client_model v0.3.0 h1:UBgGFHqYdG/TPFD1B1ogZywDqEkwp3fBMvqdiQ7Xew4=
+github.com/prometheus/client_model v0.3.0/go.mod h1:LDGWKZIo7rky3hgvBe+caln+Dr3dPggB5dvjtD7w9+w=
 github.com/prometheus/common v0.0.0-20181113130724-41aa239b4cce/go.mod h1:daVV7qP5qjZbuso7PdcryaAu0sAZbrN9i7WWcTMWvro=
 github.com/prometheus/common v0.4.0/go.mod h1:TNfzLD0ON7rHzMJeJkieUDPYmFC7Snx/y86RQel1bk4=
 github.com/prometheus/common v0.4.1/go.mod h1:TNfzLD0ON7rHzMJeJkieUDPYmFC7Snx/y86RQel1bk4=
 github.com/prometheus/common v0.10.0/go.mod h1:Tlit/dnDKsSWFlCLTWaA1cyBgKHSMdTB80sz/V91rCo=
 github.com/prometheus/common v0.26.0/go.mod h1:M7rCNAaPfAosfx8veZJCuw84e35h3Cfd9VFqTh1DIvc=
 github.com/prometheus/common v0.32.1/go.mod h1:vu+V0TpY+O6vW9J44gczi3Ap/oXXR10b+M/gUGO4Hls=
-github.com/prometheus/common v0.34.0 h1:RBmGO9d/FVjqHT0yUGQwBJhkwKV+wPCn7KGpvfab0uE=
-github.com/prometheus/common v0.34.0/go.mod h1:gB3sOl7P0TvJabZpLY5uQMpUqRCPPCyRLCZYc7JZTNE=
+github.com/prometheus/common v0.42.0 h1:EKsfXEYo4JpWMHH5cg+KOUWeuJSov1Id8zGR8eeI1YM=
+github.com/prometheus/common v0.42.0/go.mod h1:xBwqVerjNdUDjgODMpudtOMwlOwf2SaTr1yjz4b7Zbc=
 github.com/prometheus/procfs v0.0.0-20181005140218-185b4288413d/go.mod h1:c3At6R/oaqEKCNdg8wHV1ftS6bRYblBhIjjI8uT2IGk=
 github.com/prometheus/procfs v0.0.0-20190507164030-5867b95ac084/go.mod h1:TjEm7ze935MbeOT/UhFTIMYKhuLP4wbCsTZCD3I8kEA=
 github.com/prometheus/procfs v0.0.2/go.mod h1:TjEm7ze935MbeOT/UhFTIMYKhuLP4wbCsTZCD3I8kEA=
 github.com/prometheus/procfs v0.1.3/go.mod h1:lV6e/gmhEcM9IjHGsFOCxxuZ+z1YqCvr4OA4YeYWdaU=
 github.com/prometheus/procfs v0.6.0/go.mod h1:cz+aTbrPOrUb4q7XlbU9ygM+/jj0fzG6c1xBZuNvfVA=
-github.com/prometheus/procfs v0.7.3 h1:4jVXhlkAyzOScmCkXBTOLRLTz8EeU+eyjrwB/EPq0VU=
 github.com/prometheus/procfs v0.7.3/go.mod h1:cz+aTbrPOrUb4q7XlbU9ygM+/jj0fzG6c1xBZuNvfVA=
+github.com/prometheus/procfs v0.9.0 h1:wzCHvIvM5SxWqYvwgVL7yJY8Lz3PKn49KQtpgMYJfhI=
+github.com/prometheus/procfs v0.9.0/go.mod h1:+pB4zwohETzFnmlpe6yd2lSc+0/46IYZRB/chUwxUZY=
 github.com/prometheus/tsdb v0.7.1/go.mod h1:qhTCs0VvXwvX/y3TZrWD7rabWM+ijKTux40TwIPHuXU=
 github.com/robfig/cron v1.1.0 h1:jk4/Hud3TTdcrJgUOBgsqrZBarcxl6ADIjSC2iniwLY=
 github.com/robfig/cron v1.1.0/go.mod h1:JGuDeoQd7Z6yL4zQhZ3OPEVHB7fL6Ka6skscFHfmt2k=
 github.com/rogpeppe/fastuuid v0.0.0-20150106093220-6724a57986af/go.mod h1:XWv6SoW27p1b0cqNHllgS5HIMJraePCO15w5zCzIWYg=
 github.com/rogpeppe/fastuuid v1.2.0/go.mod h1:jVj6XXZzXRy/MSR5jhDC/2q6DgLz+nrA6LYCDYWNEvQ=
 github.com/rogpeppe/go-internal v1.3.0/go.mod h1:M8bDsm7K2OlrFYOpmOWEs/qY81heoFRclV5y23lUDJ4=
-github.com/rogpeppe/go-internal v1.6.1 h1:/FiVV8dS/e+YqF2JvO3yXRFbBLTIuSDkuC7aBOAvL+k=
-github.com/rogpeppe/go-internal v1.6.1/go.mod h1:xXDCJY+GAPziupqXw64V24skbSoqbTEfhy4qGm1nDQc=
-github.com/rs/xid v1.3.0 h1:6NjYksEUlhurdVehpc7S7dk6DAmcKv8V9gG0FsVN2U4=
-github.com/rs/xid v1.3.0/go.mod h1:trrq9SKmegXys3aeAKXMUTdJsYXVwGY3RLcfgqegfbg=
+github.com/rogpeppe/go-internal v1.9.0 h1:73kH8U+JUqXU8lRuOHeVHaa/SZPifC7BkcraZVejAe8=
+github.com/rogpeppe/go-internal v1.9.0/go.mod h1:WtVeX8xhTBvf0smdhujwtBcq4Qrzq/fJaraNFVN+nFs=
+github.com/rs/xid v1.4.0 h1:qd7wPTDkN6KQx2VmMBLrpHkiyQwgFXRnkOLacUiaSNY=
+github.com/rs/xid v1.4.0/go.mod h1:trrq9SKmegXys3aeAKXMUTdJsYXVwGY3RLcfgqegfbg=
 github.com/russross/blackfriday/v2 v2.0.1/go.mod h1:+Rmxgy9KzJVeS9/2gXHxylqXiyQDYRxCVz55jmeOWTM=
 github.com/russross/blackfriday/v2 v2.1.0/go.mod h1:+Rmxgy9KzJVeS9/2gXHxylqXiyQDYRxCVz55jmeOWTM=
 github.com/ryanuber/columnize v0.0.0-20160712163229-9b3edd62028f/go.mod h1:sm1tb6uqfes/u+d4ooFouqFdy9/2g9QGwK3SQygK0Ts=
@@ -668,8 +667,9 @@ github.com/sirupsen/logrus v1.2.0/go.mod h1:LxeOpSwHxABJmUn/MG1IvRgCAasNZTLOkJPx
 github.com/sirupsen/logrus v1.4.2/go.mod h1:tLMulIdttU9McNUspp0xgXVQah82FyeX6MwdIuYE2rE=
 github.com/sirupsen/logrus v1.6.0/go.mod h1:7uNnSEd1DgxDLC74fIahvMZmmYsHGZGEOFrfsX/uA88=
 github.com/sirupsen/logrus v1.7.0/go.mod h1:yWOB1SBYBC5VeMP7gHvWumXLIWorT60ONWic61uBYv0=
-github.com/sirupsen/logrus v1.8.1 h1:dJKuHgqk1NNQlqoA6BTlM1Wf9DOH3NBjQyu0h9+AZZE=
 github.com/sirupsen/logrus v1.8.1/go.mod h1:yWOB1SBYBC5VeMP7gHvWumXLIWorT60ONWic61uBYv0=
+github.com/sirupsen/logrus v1.9.0 h1:trlNQbNUG3OdDrDil03MCb1H2o9nJ1x4/5LYw7byDE0=
+github.com/sirupsen/logrus v1.9.0/go.mod h1:naHLuLoDiP4jHNo9R0sCBMtWGeIprob74mVsIT4qYEQ=
 github.com/smartystreets/assertions v0.0.0-20180927180507-b2de0cb4f26d/go.mod h1:OnSkiWE9lh6wB0YB77sQom3nweQdgAjqCqsofrRNTgc=
 github.com/smartystreets/goconvey v1.6.4/go.mod h1:syvi0/a8iFYH4r/RixwvyeAJjdLS9QV7WQ/tjFTllLA=
 github.com/soheilhy/cmux v0.1.4/go.mod h1:IM3LyeVVIOuxMH7sFAkER9+bJ4dT7Ms6E4xg4kGIyLM=
@@ -700,17 +700,23 @@ github.com/spf13/viper v1.8.1/go.mod h1:o0Pch8wJ9BVSWGQMbra6iw0oQ5oktSIBaujf1rJH
 github.com/stoewer/go-strcase v1.2.0/go.mod h1:IBiWB2sKIp3wVVQ3Y035++gc+knqhUQag1KpM8ahLw8=
 github.com/stretchr/objx v0.1.0/go.mod h1:HFkY916IF+rwdDfMAkV7OtwuqBVzrE8GR6GFx+wExME=
 github.com/stretchr/objx v0.1.1/go.mod h1:HFkY916IF+rwdDfMAkV7OtwuqBVzrE8GR6GFx+wExME=
-github.com/stretchr/objx v0.2.0 h1:Hbg2NidpLE8veEBkEZTL3CvlkUIVzuU9jDplZO54c48=
 github.com/stretchr/objx v0.2.0/go.mod h1:qt09Ya8vawLte6SNmTgCsAVtYtaKzEcn8ATUoHMkEqE=
+github.com/stretchr/objx v0.4.0/go.mod h1:YvHI0jy2hoMjB+UWwv71VJQ9isScKT/TqJzVSSt89Yw=
+github.com/stretchr/objx v0.5.0 h1:1zr/of2m5FGMsad5YfcqgdqdWrIhu+EBEJRhR1U7z/c=
+github.com/stretchr/objx v0.5.0/go.mod h1:Yh+to48EsGEfYuaHDzXPcE3xhTkx73EhmCGUpEOglKo=
 github.com/stretchr/testify v1.2.2/go.mod h1:a8OnRcib4nhh0OaRAV+Yts87kKdq0PP7pXfy6kDkUVs=
 github.com/stretchr/testify v1.3.0/go.mod h1:M5WIy9Dh21IEIfnGCwXGc5bZfKNJtfHm1UVUgZn+9EI=
 github.com/stretchr/testify v1.4.0/go.mod h1:j7eGeouHqKxXV5pUuKE4zz7dFj8WfuZ+81PSLYec5m4=
 github.com/stretchr/testify v1.5.1/go.mod h1:5W2xD1RspED5o8YsWQXVCued0rvSQ+mT+I5cxcmMvtA=
 github.com/stretchr/testify v1.6.1/go.mod h1:6Fq8oRcR53rry900zMqJjRRixrwX3KX962/h/Wwjteg=
 github.com/stretchr/testify v1.7.0/go.mod h1:6Fq8oRcR53rry900zMqJjRRixrwX3KX962/h/Wwjteg=
-github.com/stretchr/testify v1.7.1 h1:5TQK59W5E3v0r2duFAb7P95B6hEeOyEnHRa8MjYSMTY=
 github.com/stretchr/testify v1.7.1/go.mod h1:6Fq8oRcR53rry900zMqJjRRixrwX3KX962/h/Wwjteg=
+github.com/stretchr/testify v1.8.0/go.mod h1:yNjHg4UonilssWZ8iaSj1OCr/vHnekPRkoO+kdMU+MU=
+github.com/stretchr/testify v1.8.1/go.mod h1:w2LPCIKwWwSfY2zedu0+kehJoqGctiVI29o6fzry7u4=
+github.com/stretchr/testify v1.8.2 h1:+h33VjcLVPDHtOdpUCuF+7gSuG3yGIftsP1YvFihtJ8=
+github.com/stretchr/testify v1.8.2/go.mod h1:w2LPCIKwWwSfY2zedu0+kehJoqGctiVI29o6fzry7u4=
 github.com/subosito/gotenv v1.2.0/go.mod h1:N0PQaV/YGNqwC0u51sEeR/aUtSLEXKX9iv69rRypqCw=
+github.com/tg123/go-htpasswd v1.2.1 h1:i4wfsX1KvvkyoMiHZzjS0VzbAPWfxzI8INcZAKtutoU=
 github.com/tmc/grpc-websocket-proxy v0.0.0-20170815181823-89b8d40f7ca8/go.mod h1:ncp9v5uamzpCO7NfCPTXjqaC+bZgJeR0sMTm6dMHP7U=
 github.com/tmc/grpc-websocket-proxy v0.0.0-20190109142713-0ad062ec5ee5/go.mod h1:ncp9v5uamzpCO7NfCPTXjqaC+bZgJeR0sMTm6dMHP7U=
 github.com/tmc/grpc-websocket-proxy v0.0.0-20201229170055-e5319fda7802/go.mod h1:ncp9v5uamzpCO7NfCPTXjqaC+bZgJeR0sMTm6dMHP7U=
@@ -732,6 +738,8 @@ github.com/yuin/goldmark v1.1.32/go.mod h1:3hX8gzYuyVAZsxl0MRgGTJEmQBFcNTphYh9de
 github.com/yuin/goldmark v1.2.1/go.mod h1:3hX8gzYuyVAZsxl0MRgGTJEmQBFcNTphYh9decYSb74=
 github.com/yuin/goldmark v1.3.5/go.mod h1:mwnBkeHKe2W/ZEtQ+71ViKU8L12m81fl3OWwC1Zlc8k=
 github.com/yuin/goldmark v1.4.1/go.mod h1:mwnBkeHKe2W/ZEtQ+71ViKU8L12m81fl3OWwC1Zlc8k=
+github.com/yuin/goldmark v1.4.13/go.mod h1:6yULJ656Px+3vBD8DxQVa3kxgyrAnzto9xy5taEt/CY=
+github.com/zalando/go-keyring v0.2.2 h1:f0xmpYiSrHtSNAVgwip93Cg8tuF45HJM6rHq/A5RI/4=
 github.com/zeebo/assert v1.1.0 h1:hU1L1vLTHsnO8x8c9KAR5GmM5QscxHg5RNU5z5qbUWY=
 github.com/zeebo/assert v1.1.0/go.mod h1:Pq9JiuJQpG8JLJdtkwrJESF0Foym2/D9XMU5ciN/wJ0=
 github.com/zeebo/blake3 v0.2.3 h1:TFoLXsjeXqRNFxSbk35Dk4YtszE/MQQGK10BH4ptoTg=
@@ -759,12 +767,15 @@ go.opencensus.io v0.22.2/go.mod h1:yxeiOL68Rb0Xd1ddK5vPZ/oVn4vY4Ynel7k9FzqtOIw=
 go.opencensus.io v0.22.3/go.mod h1:yxeiOL68Rb0Xd1ddK5vPZ/oVn4vY4Ynel7k9FzqtOIw=
 go.opencensus.io v0.22.4/go.mod h1:yxeiOL68Rb0Xd1ddK5vPZ/oVn4vY4Ynel7k9FzqtOIw=
 go.opencensus.io v0.22.5/go.mod h1:5pWMHQbX5EPX2/62yrJeAkowc+lfs/XD7Uxpq3pI6kk=
-go.opencensus.io v0.23.0 h1:gqCw0LfLxScz8irSi8exQc7fyQ0fKQU/qnC/X8+V/1M=
 go.opencensus.io v0.23.0/go.mod h1:XItmlyltB5F7CS4xOC1DcqMoFqwtC6OG2xF7mCv7P7E=
+go.opencensus.io v0.24.0 h1:y73uSU6J157QMP2kn2r30vwW1A2W2WFwSCGnAVxeaD0=
+go.opencensus.io v0.24.0/go.mod h1:vNK8G9p7aAivkbmorf4v+7Hgx+Zs0yY+0fOtgBfjQKo=
 go.opentelemetry.io/contrib v0.20.0/go.mod h1:G/EtFaa6qaN7+LxqfIAT3GiZa7Wv5DTBUzl5H4LY0Kc=
 go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc v0.20.0/go.mod h1:oVGt1LRbBOBq1A5BQLlUg9UaU/54aiHw8cgjV3aWZ/E=
 go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp v0.20.0/go.mod h1:2AboqHi0CiIZU0qwhtUfCYD1GeUzvvIXWNkhDt7ZMG4=
 go.opentelemetry.io/otel v0.20.0/go.mod h1:Y3ugLH2oa81t5QO+Lty+zXf8zC9L26ax4Nzoxm/dooo=
+go.opentelemetry.io/otel v1.14.0 h1:/79Huy8wbf5DnIPhemGB+zEPVwnN6fuQybr/SRXa6hM=
+go.opentelemetry.io/otel v1.14.0/go.mod h1:o4buv+dJzx8rohcUeRmWUZhqupFvzWis188WlggnNeU=
 go.opentelemetry.io/otel/exporters/otlp v0.20.0/go.mod h1:YIieizyaN77rtLJra0buKiNBOm9XQfkPEKBeuhoMwAM=
 go.opentelemetry.io/otel/metric v0.20.0/go.mod h1:598I5tYlH1vzBjn+BTuhzTCSb/9debfNp6R3s7Pr1eU=
 go.opentelemetry.io/otel/oteltest v0.20.0/go.mod h1:L7bgKf9ZB7qCwT9Up7i9/pn0PWIa9FqQ2IQ8LoxiGnw=
@@ -772,6 +783,8 @@ go.opentelemetry.io/otel/sdk v0.20.0/go.mod h1:g/IcepuwNsoiX5Byy2nNV0ySUF1em498m
 go.opentelemetry.io/otel/sdk/export/metric v0.20.0/go.mod h1:h7RBNMsDJ5pmI1zExLi+bJK+Dr8NQCh0qGhm1KDnNlE=
 go.opentelemetry.io/otel/sdk/metric v0.20.0/go.mod h1:knxiS8Xd4E/N+ZqKmUPf3gTTZ4/0TjTXukfxjzSTpHE=
 go.opentelemetry.io/otel/trace v0.20.0/go.mod h1:6GjCW8zgDjwGHGa6GkyeB8+/5vjT16gUEi0Nf1iBdgw=
+go.opentelemetry.io/otel/trace v1.14.0 h1:wp2Mmvj41tDsyAJXiWDWpfNsOiIyd38fy85pyKcFq/M=
+go.opentelemetry.io/otel/trace v1.14.0/go.mod h1:8avnQLK+CG77yNLUae4ea2JDQ6iT+gozhnZjy/rw9G8=
 go.opentelemetry.io/proto/otlp v0.7.0/go.mod h1:PqfVotwruBrMGOCsRd/89rSnXhoiJIqeYNgFYFoEGnI=
 go.starlark.net v0.0.0-20200306205701-8dd3e2ee1dd5/go.mod h1:nmDLcffg48OtT/PSW0Hg7FvpRQsQh5OSqIylirxKC7o=
 go.starlark.net v0.0.0-20201006213952-227f4aabceb5 h1:ApvY/1gw+Yiqb/FKeks3KnVPWpkR3xzij82XPKLjJVw=
@@ -782,17 +795,16 @@ go.uber.org/atomic v1.7.0/go.mod h1:fEN4uk6kAWBTFdckzkM89CLk9XfWZrxpCo0nPH17wJc=
 go.uber.org/atomic v1.9.0 h1:ECmE8Bn/WFTYwEW/bpKD3M8VtR/zQVbavAoalC1PYyE=
 go.uber.org/atomic v1.9.0/go.mod h1:fEN4uk6kAWBTFdckzkM89CLk9XfWZrxpCo0nPH17wJc=
 go.uber.org/goleak v1.1.10/go.mod h1:8a7PlsEVH3e/a/GLqe5IIrQx6GzcnRmZEufDUTk4A7A=
-go.uber.org/goleak v1.1.11/go.mod h1:cwTWslyiVhfpKIDGSZEM2HlOvcqm+tG4zioyIeLoqMQ=
 go.uber.org/goleak v1.1.12 h1:gZAh5/EyT/HQwlpkCy6wTpqfH9H8Lz8zbm3dZh+OyzA=
 go.uber.org/multierr v1.1.0/go.mod h1:wR5kodmAFQ0UK8QlbwjlSNy0Z68gJhDJUG5sjR94q/0=
 go.uber.org/multierr v1.6.0/go.mod h1:cdWPpRnG4AhwMwsgIHip0KRBQjJy5kYEpYjJxpXp9iU=
-go.uber.org/multierr v1.8.0 h1:dg6GjLku4EH+249NNmoIciG9N/jURbDG+pFlTkhzIC8=
-go.uber.org/multierr v1.8.0/go.mod h1:7EAYxJLBy9rStEaz58O2t4Uvip6FSURkq8/ppBp95ak=
+go.uber.org/multierr v1.11.0 h1:blXXJkSxSSfBVBlC76pxqeO+LN3aDfLQo+309xJstO0=
+go.uber.org/multierr v1.11.0/go.mod h1:20+QtiLqy0Nd6FdQB9TLXag12DsQkrbs3htMFfDN80Y=
 go.uber.org/zap v1.10.0/go.mod h1:vwi/ZaCAaUcBkycHslxD9B2zi4UTXhF60s6SWpuDF0Q=
 go.uber.org/zap v1.17.0/go.mod h1:MXVU+bhUf/A7Xi2HNOnopQOrmycQ5Ih87HtOu4q5SSo=
 go.uber.org/zap v1.19.0/go.mod h1:xg/QME4nWcxGxrpdeYfq7UvYrLh66cuVKdrbD1XF/NI=
-go.uber.org/zap v1.21.0 h1:WefMeulhovoZ2sYXz7st6K0sLj7bBhpiFaud4r4zST8=
-go.uber.org/zap v1.21.0/go.mod h1:wjWOCqI0f2ZZrJF/UufIOkiC8ii6tm1iqIsLo76RfJw=
+go.uber.org/zap v1.24.0 h1:FiJd5l1UOLj0wCgbSE0rwwXHzEdAZS6hiiSnxJN/D60=
+go.uber.org/zap v1.24.0/go.mod h1:2kMP+WWQ8aoFoedH3T2sq6iJ2yDWpHbP0f6MQbS9Gkg=
 golang.org/x/crypto v0.0.0-20180904163835-0709b304e793/go.mod h1:6SG95UA2DQfeDnfUPMdvaQW0Q7yPrPDi9nlGo2tz2b4=
 golang.org/x/crypto v0.0.0-20181029021203-45a5f77698d3/go.mod h1:6SG95UA2DQfeDnfUPMdvaQW0Q7yPrPDi9nlGo2tz2b4=
 golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2/go.mod h1:djNgcEr1/C05ACkg1iLfiJU5Ep61QUkGW8qpdssI0+w=
@@ -804,12 +816,14 @@ golang.org/x/crypto v0.0.0-20191011191535-87dc89f01550/go.mod h1:yigFU9vqHzYiE8U
 golang.org/x/crypto v0.0.0-20191206172530-e9b2fee46413/go.mod h1:LzIPMQfyMNhhGPhUkYOs5KpL4U8rLKemX1yGLhDgUto=
 golang.org/x/crypto v0.0.0-20200622213623-75b288015ac9/go.mod h1:LzIPMQfyMNhhGPhUkYOs5KpL4U8rLKemX1yGLhDgUto=
 golang.org/x/crypto v0.0.0-20201002170205-7f63de1d35b0/go.mod h1:LzIPMQfyMNhhGPhUkYOs5KpL4U8rLKemX1yGLhDgUto=
+golang.org/x/crypto v0.0.0-20201016220609-9e8e0b390897/go.mod h1:LzIPMQfyMNhhGPhUkYOs5KpL4U8rLKemX1yGLhDgUto=
 golang.org/x/crypto v0.0.0-20210220033148-5ea612d1eb83/go.mod h1:jdWPYTVW3xRLrWPugEBEK3UY2ZEsg3UU495nc5E+M+I=
 golang.org/x/crypto v0.0.0-20210513164829-c07d793c2f9a/go.mod h1:P+XmwS30IXTQdn5tA2iutPOUgjI07+tq3H3K9MVA1s8=
 golang.org/x/crypto v0.0.0-20210921155107-089bfa567519/go.mod h1:GvvjBRRGRdwPK5ydBHafDWAxML/pGHZbMvKqRZ5+Abc=
+golang.org/x/crypto v0.0.0-20211215153901-e495a2d5b3d3/go.mod h1:IxCIyHEi3zRg3s0A5j5BB6A9Jmi73HwBIUl50j+osU4=
 golang.org/x/crypto v0.0.0-20220214200702-86341886e292/go.mod h1:IxCIyHEi3zRg3s0A5j5BB6A9Jmi73HwBIUl50j+osU4=
-golang.org/x/crypto v0.0.0-20220315160706-3147a52a75dd h1:XcWmESyNjXJMLahc3mqVQJcgSTDxFxhETVlfk9uGc38=
-golang.org/x/crypto v0.0.0-20220315160706-3147a52a75dd/go.mod h1:IxCIyHEi3zRg3s0A5j5BB6A9Jmi73HwBIUl50j+osU4=
+golang.org/x/crypto v0.14.0 h1:wBqGXzWJW6m1XrIKlAH0Hs1JJ7+9KBwnIO8v66Q9cHc=
+golang.org/x/crypto v0.14.0/go.mod h1:MVFd36DqK4CsrnJYDkBA3VC4m2GkXAM0PvzMCn4JQf4=
 golang.org/x/exp v0.0.0-20190121172915-509febef88a4/go.mod h1:CJ0aWSM057203Lf6IL+f9T1iT9GByDxfZKAQTCR3kQA=
 golang.org/x/exp v0.0.0-20190306152737-a1d7652674e8/go.mod h1:CJ0aWSM057203Lf6IL+f9T1iT9GByDxfZKAQTCR3kQA=
 golang.org/x/exp v0.0.0-20190510132918-efd6b22b2522/go.mod h1:ZjyILWgesfNpC6sMxTJOJm9Kp84zZh5NQWvqDGG3Qr8=
@@ -820,8 +834,8 @@ golang.org/x/exp v0.0.0-20191227195350-da58074b4299/go.mod h1:2RIsYlXP63K8oxa1u0
 golang.org/x/exp v0.0.0-20200119233911-0405dc783f0a/go.mod h1:2RIsYlXP63K8oxa1u096TMicItID8zy7Y6sNkU49FU4=
 golang.org/x/exp v0.0.0-20200207192155-f17229e696bd/go.mod h1:J/WKrq2StrnmMY6+EHIKF9dgMWnmCNThgcyBT1FY9mM=
 golang.org/x/exp v0.0.0-20200224162631-6cc2880d07d6/go.mod h1:3jZMyOhIsHpP37uCMkUooju7aAi5cS1Q23tOzKc+0MU=
-golang.org/x/exp v0.0.0-20210916165020-5cb4fee858ee h1:qlrAyYdKz4o7rWVUjiKqQJMa4PEpd55fqBU8jpsl4Iw=
-golang.org/x/exp v0.0.0-20210916165020-5cb4fee858ee/go.mod h1:a3o/VtDNHN+dCVLEpzjjUHOzR+Ln3DHX056ZPzoZGGA=
+golang.org/x/exp v0.0.0-20221028150844-83b7d23a625f h1:Al51T6tzvuh3oiwX11vex3QgJ2XTedFPGmbEVh8cdoc=
+golang.org/x/exp v0.0.0-20221028150844-83b7d23a625f/go.mod h1:CxIveKay+FTh1D0yPZemJVgC/95VzuuOLq5Qi4xnoYc=
 golang.org/x/image v0.0.0-20190227222117-0694c2d4d067/go.mod h1:kZ7UVZpmo3dzQBMxlp+ypCbDeSB+sBbTgSJuh5dn5js=
 golang.org/x/image v0.0.0-20190802002840-cff245a6509b/go.mod h1:FeLwcggjj3mMvU+oOTbSwawSJRM1uh48EjtB4UJZlP0=
 golang.org/x/lint v0.0.0-20181026193005-c67002cb31c3/go.mod h1:UVdnD1Gm6xHRNCYTkRU2/jEulfH38KcIWyp/GAMgvoE=
@@ -848,8 +862,9 @@ golang.org/x/mod v0.4.0/go.mod h1:s0Qsj1ACt9ePp/hMypM3fl4fZqREWJwdYDEqhRiZZUA=
 golang.org/x/mod v0.4.1/go.mod h1:s0Qsj1ACt9ePp/hMypM3fl4fZqREWJwdYDEqhRiZZUA=
 golang.org/x/mod v0.4.2/go.mod h1:s0Qsj1ACt9ePp/hMypM3fl4fZqREWJwdYDEqhRiZZUA=
 golang.org/x/mod v0.6.0-dev.0.20220106191415-9b9b3d81d5e3/go.mod h1:3p9vT2HGsQu2K1YbXdKPJLVgG5VJdoTa1poYQBtP1AY=
-golang.org/x/mod v0.6.0-dev.0.20220419223038-86c51ed26bb4 h1:6zppjxzCulZykYSLyVDYbneBfbaBIQPYMevg0bEwv2s=
 golang.org/x/mod v0.6.0-dev.0.20220419223038-86c51ed26bb4/go.mod h1:jJ57K6gSWd91VN4djpZkiMVwK6gcyfeH4XE8wZrZaV4=
+golang.org/x/mod v0.10.0 h1:lFO9qtOdlre5W1jxS3r/4szv2/6iXxScdzjoBMXNhYk=
+golang.org/x/mod v0.10.0/go.mod h1:iBbtSCu2XBx23ZKBPSOrRkjjQPZFPuis4dIYUhu/chs=
 golang.org/x/net v0.0.0-20180530234432-1e491301e022/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4=
 golang.org/x/net v0.0.0-20180724234803-3673e40ba225/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4=
 golang.org/x/net v0.0.0-20180826012351-8a410e7b638d/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4=
@@ -898,8 +913,6 @@ golang.org/x/net v0.0.0-20210119194325-5f4716e94777/go.mod h1:m0MpNAwzfU5UDzcl9v
 golang.org/x/net v0.0.0-20210226172049-e18ecbb05110/go.mod h1:m0MpNAwzfU5UDzcl9v0D8zg8gWTRqZa9RBIspLL5mdg=
 golang.org/x/net v0.0.0-20210316092652-d523dce5a7f4/go.mod h1:RBQZq4jEuRlivfhVLdyRGr576XBO4/greRjx4P4O3yc=
 golang.org/x/net v0.0.0-20210405180319-a5a99cb37ef4/go.mod h1:p54w0d4576C0XHj96bSt6lcn1PtDYWL6XObtHCRCNQM=
-golang.org/x/net v0.0.0-20210428140749-89ef3d95e781/go.mod h1:OJAsFXCWl8Ukc7SiCT/9KSuxbyM7479/AVlXFRxuMCk=
-golang.org/x/net v0.0.0-20210503060351-7fd8e65b6420/go.mod h1:9nx3DQGgdP8bBQD5qxJ1jj9UTztislL4KSBs9R2vV5Y=
 golang.org/x/net v0.0.0-20210520170846-37e1c6afe023/go.mod h1:9nx3DQGgdP8bBQD5qxJ1jj9UTztislL4KSBs9R2vV5Y=
 golang.org/x/net v0.0.0-20210525063256-abc453219eb5/go.mod h1:9nx3DQGgdP8bBQD5qxJ1jj9UTztislL4KSBs9R2vV5Y=
 golang.org/x/net v0.0.0-20210610132358-84b48f89b13b/go.mod h1:9nx3DQGgdP8bBQD5qxJ1jj9UTztislL4KSBs9R2vV5Y=
@@ -908,10 +921,10 @@ golang.org/x/net v0.0.0-20210825183410-e898025ed96a/go.mod h1:9nx3DQGgdP8bBQD5qx
 golang.org/x/net v0.0.0-20211015210444-4f30a5c0130f/go.mod h1:9nx3DQGgdP8bBQD5qxJ1jj9UTztislL4KSBs9R2vV5Y=
 golang.org/x/net v0.0.0-20211112202133-69e39bad7dc2/go.mod h1:9nx3DQGgdP8bBQD5qxJ1jj9UTztislL4KSBs9R2vV5Y=
 golang.org/x/net v0.0.0-20220127200216-cd36cc0744dd/go.mod h1:CfG3xpIq0wQ8r1q4Su4UZFWDARRcnwPjda9FqA0JpMk=
-golang.org/x/net v0.0.0-20220225172249-27dd8689420f/go.mod h1:CfG3xpIq0wQ8r1q4Su4UZFWDARRcnwPjda9FqA0JpMk=
-golang.org/x/net v0.0.0-20220325170049-de3da57026de/go.mod h1:CfG3xpIq0wQ8r1q4Su4UZFWDARRcnwPjda9FqA0JpMk=
-golang.org/x/net v0.7.0 h1:rJrUqqhjsgNp7KqAIc25s9pZnjU7TUcSY7HcVZjdn1g=
-golang.org/x/net v0.7.0/go.mod h1:2Tu9+aMcznHK/AK1HMvgo6xiTLG5rD5rZLDS+rp2Bjs=
+golang.org/x/net v0.0.0-20220722155237-a158d28d115b/go.mod h1:XRhObCWvk6IyKnWLug+ECip1KBveYUHfp+8e9klMJ9c=
+golang.org/x/net v0.1.0/go.mod h1:Cx3nUiGt4eDBEyega/BKRp+/AlGL8hYe7U9odMt2Cco=
+golang.org/x/net v0.17.0 h1:pVaXccu2ozPjCXewfr1S7xza/zcXTity9cCdXQYSjIM=
+golang.org/x/net v0.17.0/go.mod h1:NxSsAGuq816PNPmqtQdLE42eU2Fs7NoRIZrHJAlaCOE=
 golang.org/x/oauth2 v0.0.0-20180821212333-d2e6202438be/go.mod h1:N/0e6XlmueqKjAGxoOufVs8QHGRruUQn6yWY3a++T0U=
 golang.org/x/oauth2 v0.0.0-20190226205417-e64efc72b421/go.mod h1:gOpvHmFTYa4IltrdGE7lF6nIHvwfUNPOp7c8zoXwtLw=
 golang.org/x/oauth2 v0.0.0-20190604053449-0f29369cfe45/go.mod h1:gOpvHmFTYa4IltrdGE7lF6nIHvwfUNPOp7c8zoXwtLw=
@@ -925,14 +938,10 @@ golang.org/x/oauth2 v0.0.0-20210220000619-9bb904979d93/go.mod h1:KelEdhl1UZF7XfJ
 golang.org/x/oauth2 v0.0.0-20210313182246-cd4f82c27b84/go.mod h1:KelEdhl1UZF7XfJ4dDtk6s++YSgaE7mD/BuKKDLBl4A=
 golang.org/x/oauth2 v0.0.0-20210402161424-2e8d93401602/go.mod h1:KelEdhl1UZF7XfJ4dDtk6s++YSgaE7mD/BuKKDLBl4A=
 golang.org/x/oauth2 v0.0.0-20210514164344-f6687ab2804c/go.mod h1:KelEdhl1UZF7XfJ4dDtk6s++YSgaE7mD/BuKKDLBl4A=
-golang.org/x/oauth2 v0.0.0-20210628180205-a41e5a781914/go.mod h1:KelEdhl1UZF7XfJ4dDtk6s++YSgaE7mD/BuKKDLBl4A=
-golang.org/x/oauth2 v0.0.0-20210805134026-6f1e6394065a/go.mod h1:KelEdhl1UZF7XfJ4dDtk6s++YSgaE7mD/BuKKDLBl4A=
 golang.org/x/oauth2 v0.0.0-20210819190943-2bc19b11175f/go.mod h1:KelEdhl1UZF7XfJ4dDtk6s++YSgaE7mD/BuKKDLBl4A=
 golang.org/x/oauth2 v0.0.0-20211104180415-d3ed0bb246c8/go.mod h1:KelEdhl1UZF7XfJ4dDtk6s++YSgaE7mD/BuKKDLBl4A=
-golang.org/x/oauth2 v0.0.0-20220223155221-ee480838109b/go.mod h1:DAh4E804XQdzx2j+YRIaUnCqCV2RuMz24cGBJ5QYIrc=
-golang.org/x/oauth2 v0.0.0-20220309155454-6242fa91716a/go.mod h1:DAh4E804XQdzx2j+YRIaUnCqCV2RuMz24cGBJ5QYIrc=
-golang.org/x/oauth2 v0.0.0-20220608161450-d0670ef3b1eb h1:8tDJ3aechhddbdPAxpycgXHJRMLpk/Ab+aa4OgdN5/g=
-golang.org/x/oauth2 v0.0.0-20220608161450-d0670ef3b1eb/go.mod h1:jaDAt6Dkxork7LmZnYtzbRWj0W47D86a3TGe0YHBvmE=
+golang.org/x/oauth2 v0.7.0 h1:qe6s0zUXlPX80/dITx3440hWZ7GwMwgDDyrSGTPJG/g=
+golang.org/x/oauth2 v0.7.0/go.mod h1:hPLQkd9LyjfXTiRohC/41GhcFqxisoUQ99sCUOHO9x4=
 golang.org/x/sync v0.0.0-20180314180146-1d60e4601c6f/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
 golang.org/x/sync v0.0.0-20181108010431-42b317875d0f/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
 golang.org/x/sync v0.0.0-20181221193216-37e7f081c4d4/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
@@ -943,8 +952,10 @@ golang.org/x/sync v0.0.0-20200317015054-43a5402ce75a/go.mod h1:RxMgew5VJxzue5/jJ
 golang.org/x/sync v0.0.0-20200625203802-6e8e738ad208/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
 golang.org/x/sync v0.0.0-20201020160332-67f06af15bc9/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
 golang.org/x/sync v0.0.0-20201207232520-09787c993a3a/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
-golang.org/x/sync v0.0.0-20210220032951-036812b2e83c h1:5KslGYwFpkhGh+Q16bwMP3cOontH8FOep7tGV86Y7SQ=
 golang.org/x/sync v0.0.0-20210220032951-036812b2e83c/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
+golang.org/x/sync v0.0.0-20220722155255-886fb9371eb4/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
+golang.org/x/sync v0.1.0 h1:wsuoTGHzEhffawBOhz5CYhcrV4IdKZbEyZjBMuTp12o=
+golang.org/x/sync v0.1.0/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
 golang.org/x/sys v0.0.0-20180823144017-11551d06cbcc/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
 golang.org/x/sys v0.0.0-20180830151530-49385e6e1522/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
 golang.org/x/sys v0.0.0-20180905080454-ebe1bf3edb33/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
@@ -976,7 +987,6 @@ golang.org/x/sys v0.0.0-20191204072324-ce4227a45e2e/go.mod h1:h1NjWce9XRLGQEsW7w
 golang.org/x/sys v0.0.0-20191228213918-04cbcbbfeed8/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
 golang.org/x/sys v0.0.0-20200106162015-b016eb3dc98e/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
 golang.org/x/sys v0.0.0-20200113162924-86b910548bc1/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
-golang.org/x/sys v0.0.0-20200116001909-b77594299b42/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
 golang.org/x/sys v0.0.0-20200122134326-e047566fdf82/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
 golang.org/x/sys v0.0.0-20200202164722-d101bd2416d5/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
 golang.org/x/sys v0.0.0-20200212091648-12a6c2dcc1e4/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
@@ -993,7 +1003,6 @@ golang.org/x/sys v0.0.0-20200615200032-f1bc736245b1/go.mod h1:h1NjWce9XRLGQEsW7w
 golang.org/x/sys v0.0.0-20200622214017-ed371f2e16b4/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
 golang.org/x/sys v0.0.0-20200625212154-ddb9806d33ae/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
 golang.org/x/sys v0.0.0-20200803210538-64077c9b5642/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
-golang.org/x/sys v0.0.0-20200828194041-157a740278f4/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
 golang.org/x/sys v0.0.0-20200905004654-be1d3432aa8f/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
 golang.org/x/sys v0.0.0-20200923182605-d9f96fdee20d/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
 golang.org/x/sys v0.0.0-20200930185726-fdedc70b468f/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
@@ -1012,35 +1021,31 @@ golang.org/x/sys v0.0.0-20210330210617-4fbd30eecc44/go.mod h1:h1NjWce9XRLGQEsW7w
 golang.org/x/sys v0.0.0-20210403161142-5e06dd20ab57/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
 golang.org/x/sys v0.0.0-20210423082822-04245dca01da/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
 golang.org/x/sys v0.0.0-20210510120138-977fb7262007/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
-golang.org/x/sys v0.0.0-20210514084401-e8d321eab015/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
 golang.org/x/sys v0.0.0-20210603081109-ebe580a85c40/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
-golang.org/x/sys v0.0.0-20210603125802-9665404d3644/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
 golang.org/x/sys v0.0.0-20210615035016-665e8c7367d1/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
 golang.org/x/sys v0.0.0-20210616094352-59db8d763f22/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
 golang.org/x/sys v0.0.0-20210630005230-0f9fa26af87c/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
-golang.org/x/sys v0.0.0-20210806184541-e5e7981a1069/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
-golang.org/x/sys v0.0.0-20210823070655-63515b42dcdf/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
 golang.org/x/sys v0.0.0-20210831042530-f4d43177bf5e/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
-golang.org/x/sys v0.0.0-20210908233432-aa78b53d3365/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
-golang.org/x/sys v0.0.0-20210927094055-39ccf1dd6fa6/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
 golang.org/x/sys v0.0.0-20211019181941-9d821ace8654/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
-golang.org/x/sys v0.0.0-20211124211545-fe61309f8881/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
-golang.org/x/sys v0.0.0-20211210111614-af8b64212486/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
 golang.org/x/sys v0.0.0-20211216021012-1d35b9e2eb4e/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
 golang.org/x/sys v0.0.0-20220114195835-da31bd327af9/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
-golang.org/x/sys v0.0.0-20220128215802-99c3d69c2c27/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
 golang.org/x/sys v0.0.0-20220209214540-3681064d5158/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
-golang.org/x/sys v0.0.0-20220227234510-4e6760a101f9/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
-golang.org/x/sys v0.0.0-20220328115105-d36c6a25d886/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
 golang.org/x/sys v0.0.0-20220412211240-33da011f77ad/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
-golang.org/x/sys v0.5.0 h1:MUK/U/4lj1t1oPg0HfuXDN/Z1wv31ZJ/YcPiGccS4DU=
-golang.org/x/sys v0.5.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
+golang.org/x/sys v0.0.0-20220520151302-bc2c85ada10a/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
+golang.org/x/sys v0.0.0-20220704084225-05e143d24a9e/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
+golang.org/x/sys v0.0.0-20220715151400-c0bba94af5f8/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
+golang.org/x/sys v0.0.0-20220722155257-8c9f86f7a55f/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
+golang.org/x/sys v0.0.0-20220811171246-fbc7d0a398ab/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
+golang.org/x/sys v0.1.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
+golang.org/x/sys v0.13.0 h1:Af8nKPmuFypiUBjVoU9V20FiaFXOcuZI21p0ycVYYGE=
+golang.org/x/sys v0.13.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
 golang.org/x/term v0.0.0-20201117132131-f5c789dd3221/go.mod h1:Nr5EML6q2oocZ2LXRh80K7BxOlk5/8JxuGnuhpl+muw=
 golang.org/x/term v0.0.0-20201126162022-7de9c90e9dd1/go.mod h1:bj7SfCRtBDWHUb9snDiAeCFNEtKQo2Wmx5Cou7ajbmo=
 golang.org/x/term v0.0.0-20210220032956-6a3ed077a48d/go.mod h1:bj7SfCRtBDWHUb9snDiAeCFNEtKQo2Wmx5Cou7ajbmo=
 golang.org/x/term v0.0.0-20210927222741-03fcf44c2211/go.mod h1:jbD1KX2456YbFQfuXm/mYQcufACuNUgVhRMnK/tPxf8=
-golang.org/x/term v0.5.0 h1:n2a8QNdAb0sZNpU9R1ALUXBbY+w51fCQDN+7EdxNBsY=
-golang.org/x/term v0.5.0/go.mod h1:jMB1sMXY+tzblOD4FWmEbocvup2/aLOaQEp7JmGp78k=
+golang.org/x/term v0.1.0/go.mod h1:jbD1KX2456YbFQfuXm/mYQcufACuNUgVhRMnK/tPxf8=
+golang.org/x/term v0.13.0 h1:bb+I9cTfFazGW51MZqBVmZy7+JEJMouUHTUSKVQLBek=
+golang.org/x/term v0.13.0/go.mod h1:LTmsnFJwVN6bCy1rVCoS+qHT1HhALEFxKncY3WNNh4U=
 golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ=
 golang.org/x/text v0.3.0/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ=
 golang.org/x/text v0.3.1-0.20180807135948-17ff2d5776d2/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ=
@@ -1050,8 +1055,9 @@ golang.org/x/text v0.3.4/go.mod h1:5Zoc/QRtKVWzQhOtBMvqHzDpF6irO9z98xDceosuGiQ=
 golang.org/x/text v0.3.5/go.mod h1:5Zoc/QRtKVWzQhOtBMvqHzDpF6irO9z98xDceosuGiQ=
 golang.org/x/text v0.3.6/go.mod h1:5Zoc/QRtKVWzQhOtBMvqHzDpF6irO9z98xDceosuGiQ=
 golang.org/x/text v0.3.7/go.mod h1:u+2+/6zg+i71rQMx5EYifcz6MCKuco9NR6JIITiCfzQ=
-golang.org/x/text v0.7.0 h1:4BRB4x83lYWy72KwLD/qYDuTu7q9PjSagHvijDw7cLo=
-golang.org/x/text v0.7.0/go.mod h1:mrYo+phRRbMaCq/xk9113O4dZlRixOauAjOtrjsXDZ8=
+golang.org/x/text v0.4.0/go.mod h1:mrYo+phRRbMaCq/xk9113O4dZlRixOauAjOtrjsXDZ8=
+golang.org/x/text v0.13.0 h1:ablQoSUd0tRdKxZewP80B+BaqeKJuVhuRxj/dkrun3k=
+golang.org/x/text v0.13.0/go.mod h1:TvPlkZtksWOMsz7fbANvkp4WM8x/WCo/om8BMLbz+aE=
 golang.org/x/time v0.0.0-20180412165947-fbb02b2291d2/go.mod h1:tRJNPiyCQ0inRvYxbN9jk5I+vvW/OXSQhTDSoE431IQ=
 golang.org/x/time v0.0.0-20181108054448-85acf8d2951c/go.mod h1:tRJNPiyCQ0inRvYxbN9jk5I+vvW/OXSQhTDSoE431IQ=
 golang.org/x/time v0.0.0-20190308202827-9d24e82272b4/go.mod h1:tRJNPiyCQ0inRvYxbN9jk5I+vvW/OXSQhTDSoE431IQ=
@@ -1121,17 +1127,16 @@ golang.org/x/tools v0.0.0-20201224043029-2b0845dc783e/go.mod h1:emZCQorbCU4vsT4f
 golang.org/x/tools v0.0.0-20210105154028-b0ab187a4818/go.mod h1:emZCQorbCU4vsT4fOWvOPXz4eW1wZW4PmDk9uLelYpA=
 golang.org/x/tools v0.0.0-20210106214847-113979e3529a/go.mod h1:emZCQorbCU4vsT4fOWvOPXz4eW1wZW4PmDk9uLelYpA=
 golang.org/x/tools v0.1.0/go.mod h1:xkSsbof2nBLbhDlRMhhhyNLN/zl3eTqcnHD5viDpcZ0=
-golang.org/x/tools v0.1.1/go.mod h1:o0xws9oXOQQZyjljx8fwUC0k7L1pTE6eaCbjGeHmOkk=
 golang.org/x/tools v0.1.2/go.mod h1:o0xws9oXOQQZyjljx8fwUC0k7L1pTE6eaCbjGeHmOkk=
-golang.org/x/tools v0.1.3/go.mod h1:o0xws9oXOQQZyjljx8fwUC0k7L1pTE6eaCbjGeHmOkk=
-golang.org/x/tools v0.1.4/go.mod h1:o0xws9oXOQQZyjljx8fwUC0k7L1pTE6eaCbjGeHmOkk=
 golang.org/x/tools v0.1.5/go.mod h1:o0xws9oXOQQZyjljx8fwUC0k7L1pTE6eaCbjGeHmOkk=
 golang.org/x/tools v0.1.10-0.20220218145154-897bd77cd717/go.mod h1:Uh6Zz+xoGYZom868N8YTex3t7RhtHDBrE8Gzo9bV56E=
+golang.org/x/tools v0.1.12/go.mod h1:hNGJHUnrk76NpqgfD5Aqm5Crs+Hm0VOH/i9J2+nxYbc=
 golang.org/x/xerrors v0.0.0-20190717185122-a985d3407aa7/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0=
 golang.org/x/xerrors v0.0.0-20191011141410-1b5146add898/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0=
 golang.org/x/xerrors v0.0.0-20191204190536-9bdfabe68543/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0=
-golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1 h1:go1bK/D/BFZV2I8cIQd1NKEZ+0owSTG1fDTci4IqFcE=
 golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0=
+golang.org/x/xerrors v0.0.0-20220907171357-04be3eba64a2 h1:H2TDz8ibqkAF6YGhCdN3jS9O0/s90v0rJh3X/OLHEUk=
+golang.org/x/xerrors v0.0.0-20220907171357-04be3eba64a2/go.mod h1:K8+ghG5WaK9qNqU5K3HdILfMLy1f3aNYFI/wnl100a8=
 gomodules.xyz/jsonpatch/v2 v2.2.0 h1:4pT439QV83L+G9FkcCriY6EkpcK6r6bK+A5FBUMI7qY=
 gomodules.xyz/jsonpatch/v2 v2.2.0/go.mod h1:WXp+iVDkoLQqPudfQ9GBlwB2eZ5DKOnjQZCYdOS8GPY=
 google.golang.org/api v0.4.0/go.mod h1:8k5glujaEP+g9n7WNsDg8QP6cUVNI86fCNMcbazEtwE=
@@ -1156,24 +1161,8 @@ google.golang.org/api v0.40.0/go.mod h1:fYKFpnQN0DsDSKRVRcQSDQNtqWPfM9i+zNPxepjR
 google.golang.org/api v0.41.0/go.mod h1:RkxM5lITDfTzmyKFPt+wGrCJbVfniCr2ool8kTBzRTU=
 google.golang.org/api v0.43.0/go.mod h1:nQsDGjRXMo4lvh5hP0TKqF244gqhGcr/YSIykhUk/94=
 google.golang.org/api v0.44.0/go.mod h1:EBOGZqzyhtvMDoxwS97ctnh0zUmYY6CxqXsc1AvkYD8=
-google.golang.org/api v0.47.0/go.mod h1:Wbvgpq1HddcWVtzsVLyfLp8lDg6AA241LmgIL59tHXo=
-google.golang.org/api v0.48.0/go.mod h1:71Pr1vy+TAZRPkPs/xlCf5SsU8WjuAWv1Pfjbtukyy4=
-google.golang.org/api v0.50.0/go.mod h1:4bNT5pAuq5ji4SRZm+5QIkjny9JAyVD/3gaSihNefaw=
-google.golang.org/api v0.51.0/go.mod h1:t4HdrdoNgyN5cbEfm7Lum0lcLDLiise1F8qDKX00sOU=
-google.golang.org/api v0.54.0/go.mod h1:7C4bFFOvVDGXjfDTAsgGwDgAxRDeQ4X8NvUedIt6z3k=
-google.golang.org/api v0.55.0/go.mod h1:38yMfeP1kfjsl8isn0tliTjIb1rJXcQi4UXlbqivdVE=
-google.golang.org/api v0.56.0/go.mod h1:38yMfeP1kfjsl8isn0tliTjIb1rJXcQi4UXlbqivdVE=
-google.golang.org/api v0.57.0/go.mod h1:dVPlbZyBo2/OjBpmvNdpn2GRm6rPy75jyU7bmhdrMgI=
-google.golang.org/api v0.61.0/go.mod h1:xQRti5UdCmoCEqFxcz93fTl338AVqDgyaDRuOZ3hg9I=
-google.golang.org/api v0.63.0/go.mod h1:gs4ij2ffTRXwuzzgJl/56BdwJaA194ijkfn++9tDuPo=
-google.golang.org/api v0.64.0/go.mod h1:931CdxA8Rm4t6zqTFGSsgwbAEZ2+GMYurbndwSimebM=
-google.golang.org/api v0.66.0/go.mod h1:I1dmXYpX7HGwz/ejRxwQp2qj5bFAz93HiCU1C1oYd9M=
-google.golang.org/api v0.67.0/go.mod h1:ShHKP8E60yPsKNw/w8w+VYaj9H6buA5UqDp8dhbQZ6g=
-google.golang.org/api v0.69.0/go.mod h1:boanBiw+h5c3s+tBPgEzLDRHfFLWV0qXxRHz3ws7C80=
-google.golang.org/api v0.70.0/go.mod h1:Bs4ZM2HGifEvXwd50TtW70ovgJffJYw2oRCOFU/SkfA=
-google.golang.org/api v0.71.0/go.mod h1:4PyU6e6JogV1f9eA4voyrTY2batOLdgZ5qZ5HOCc4j8=
-google.golang.org/api v0.74.0 h1:ExR2D+5TYIrMphWgs5JCgwRhEDlPDXXrLwHHMgPHTXE=
-google.golang.org/api v0.74.0/go.mod h1:ZpfMZOVRMywNyvJFeqL9HRWBgAuRfSjJFpe9QtRRyDs=
+google.golang.org/api v0.120.0 h1:TTmhTei0mkR+kiBSW2UzZmAbkTaBfUUzfchyXnzG9Hs=
+google.golang.org/api v0.120.0/go.mod h1:CrSvlNEFCFLae9ZUtL1z+61+rEBD7J/aCYwVYKZoWFU=
 google.golang.org/appengine v1.1.0/go.mod h1:EbEs0AVv82hx2wNQdGPgUI5lhzA/G0D9YwlJXL52JkM=
 google.golang.org/appengine v1.4.0/go.mod h1:xpcJRLb0r/rnEns0DIKYYv+WjYCduHsrkT7/EB5XEv4=
 google.golang.org/appengine v1.5.0/go.mod h1:xpcJRLb0r/rnEns0DIKYYv+WjYCduHsrkT7/EB5XEv4=
@@ -1226,41 +1215,11 @@ google.golang.org/genproto v0.0.0-20210303154014-9728d6b83eeb/go.mod h1:FWY/as6D
 google.golang.org/genproto v0.0.0-20210310155132-4ce2db91004e/go.mod h1:FWY/as6DDZQgahTzZj3fqbO1CbirC29ZNUFHwi0/+no=
 google.golang.org/genproto v0.0.0-20210319143718-93e7006c17a6/go.mod h1:FWY/as6DDZQgahTzZj3fqbO1CbirC29ZNUFHwi0/+no=
 google.golang.org/genproto v0.0.0-20210402141018-6c239bbf2bb1/go.mod h1:9lPAdzaEmUacj36I+k7YKbEc5CXzPIeORRgDAUOu28A=
-google.golang.org/genproto v0.0.0-20210513213006-bf773b8c8384/go.mod h1:P3QM42oQyzQSnHPnZ/vqoCdDmzH28fzWByN9asMeM8A=
 google.golang.org/genproto v0.0.0-20210602131652-f16073e35f0c/go.mod h1:UODoCrxHCcBojKKwX1terBiRUaqAsFqJiF615XL43r0=
-google.golang.org/genproto v0.0.0-20210604141403-392c879c8b08/go.mod h1:UODoCrxHCcBojKKwX1terBiRUaqAsFqJiF615XL43r0=
-google.golang.org/genproto v0.0.0-20210608205507-b6d2f5bf0d7d/go.mod h1:UODoCrxHCcBojKKwX1terBiRUaqAsFqJiF615XL43r0=
-google.golang.org/genproto v0.0.0-20210624195500-8bfb893ecb84/go.mod h1:SzzZ/N+nwJDaO1kznhnlzqS8ocJICar6hYhVyhi++24=
-google.golang.org/genproto v0.0.0-20210713002101-d411969a0d9a/go.mod h1:AxrInvYm1dci+enl5hChSFPOmmUF1+uAa/UsgNRWd7k=
-google.golang.org/genproto v0.0.0-20210716133855-ce7ef5c701ea/go.mod h1:AxrInvYm1dci+enl5hChSFPOmmUF1+uAa/UsgNRWd7k=
-google.golang.org/genproto v0.0.0-20210728212813-7823e685a01f/go.mod h1:ob2IJxKrgPT52GcgX759i1sleT07tiKowYBGbczaW48=
-google.golang.org/genproto v0.0.0-20210805201207-89edb61ffb67/go.mod h1:ob2IJxKrgPT52GcgX759i1sleT07tiKowYBGbczaW48=
-google.golang.org/genproto v0.0.0-20210813162853-db860fec028c/go.mod h1:cFeNkxwySK631ADgubI+/XFU/xp8FD5KIVV4rj8UC5w=
-google.golang.org/genproto v0.0.0-20210821163610-241b8fcbd6c8/go.mod h1:eFjDcFEctNawg4eG61bRv87N7iHBWyVhJu7u1kqDUXY=
-google.golang.org/genproto v0.0.0-20210828152312-66f60bf46e71/go.mod h1:eFjDcFEctNawg4eG61bRv87N7iHBWyVhJu7u1kqDUXY=
 google.golang.org/genproto v0.0.0-20210831024726-fe130286e0e2/go.mod h1:eFjDcFEctNawg4eG61bRv87N7iHBWyVhJu7u1kqDUXY=
-google.golang.org/genproto v0.0.0-20210903162649-d08c68adba83/go.mod h1:eFjDcFEctNawg4eG61bRv87N7iHBWyVhJu7u1kqDUXY=
-google.golang.org/genproto v0.0.0-20210909211513-a8c4777a87af/go.mod h1:eFjDcFEctNawg4eG61bRv87N7iHBWyVhJu7u1kqDUXY=
-google.golang.org/genproto v0.0.0-20210924002016-3dee208752a0/go.mod h1:5CzLGKJ67TSI2B9POpiiyGha0AjJvZIUgRMt1dSmuhc=
-google.golang.org/genproto v0.0.0-20211118181313-81c1377c94b1/go.mod h1:5CzLGKJ67TSI2B9POpiiyGha0AjJvZIUgRMt1dSmuhc=
-google.golang.org/genproto v0.0.0-20211206160659-862468c7d6e0/go.mod h1:5CzLGKJ67TSI2B9POpiiyGha0AjJvZIUgRMt1dSmuhc=
-google.golang.org/genproto v0.0.0-20211208223120-3a66f561d7aa/go.mod h1:5CzLGKJ67TSI2B9POpiiyGha0AjJvZIUgRMt1dSmuhc=
-google.golang.org/genproto v0.0.0-20211221195035-429b39de9b1c/go.mod h1:5CzLGKJ67TSI2B9POpiiyGha0AjJvZIUgRMt1dSmuhc=
-google.golang.org/genproto v0.0.0-20211223182754-3ac035c7e7cb/go.mod h1:5CzLGKJ67TSI2B9POpiiyGha0AjJvZIUgRMt1dSmuhc=
 google.golang.org/genproto v0.0.0-20220107163113-42d7afdf6368/go.mod h1:5CzLGKJ67TSI2B9POpiiyGha0AjJvZIUgRMt1dSmuhc=
-google.golang.org/genproto v0.0.0-20220111164026-67b88f271998/go.mod h1:5CzLGKJ67TSI2B9POpiiyGha0AjJvZIUgRMt1dSmuhc=
-google.golang.org/genproto v0.0.0-20220114231437-d2e6a121cae0/go.mod h1:5CzLGKJ67TSI2B9POpiiyGha0AjJvZIUgRMt1dSmuhc=
-google.golang.org/genproto v0.0.0-20220126215142-9970aeb2e350/go.mod h1:5CzLGKJ67TSI2B9POpiiyGha0AjJvZIUgRMt1dSmuhc=
-google.golang.org/genproto v0.0.0-20220201184016-50beb8ab5c44/go.mod h1:5CzLGKJ67TSI2B9POpiiyGha0AjJvZIUgRMt1dSmuhc=
-google.golang.org/genproto v0.0.0-20220207164111-0872dc986b00/go.mod h1:5CzLGKJ67TSI2B9POpiiyGha0AjJvZIUgRMt1dSmuhc=
-google.golang.org/genproto v0.0.0-20220211171837-173942840c17/go.mod h1:kGP+zUP2Ddo0ayMi4YuN7C3WZyJvGLZRh8Z5wnAqvEI=
-google.golang.org/genproto v0.0.0-20220216160803-4663080d8bc8/go.mod h1:kGP+zUP2Ddo0ayMi4YuN7C3WZyJvGLZRh8Z5wnAqvEI=
-google.golang.org/genproto v0.0.0-20220218161850-94dd64e39d7c/go.mod h1:kGP+zUP2Ddo0ayMi4YuN7C3WZyJvGLZRh8Z5wnAqvEI=
-google.golang.org/genproto v0.0.0-20220222213610-43724f9ea8cf/go.mod h1:kGP+zUP2Ddo0ayMi4YuN7C3WZyJvGLZRh8Z5wnAqvEI=
-google.golang.org/genproto v0.0.0-20220304144024-325a89244dc8/go.mod h1:kGP+zUP2Ddo0ayMi4YuN7C3WZyJvGLZRh8Z5wnAqvEI=
-google.golang.org/genproto v0.0.0-20220310185008-1973136f34c6/go.mod h1:kGP+zUP2Ddo0ayMi4YuN7C3WZyJvGLZRh8Z5wnAqvEI=
-google.golang.org/genproto v0.0.0-20220324131243-acbaeb5b85eb h1:0m9wktIpOxGw+SSKmydXWB3Z3GTfcPP6+q75HCQa6HI=
-google.golang.org/genproto v0.0.0-20220324131243-acbaeb5b85eb/go.mod h1:hAL49I2IFola2sVEjAn7MEwsja0xp51I0tlGAf9hz4E=
+google.golang.org/genproto v0.0.0-20230410155749-daa745c078e1 h1:KpwkzHKEF7B9Zxg18WzOa7djJ+Ha5DzthMyZYQfEn2A=
+google.golang.org/genproto v0.0.0-20230410155749-daa745c078e1/go.mod h1:nKE/iIaLqn2bQwXBg8f1g2Ylh6r5MN5CmZvuzZCgsCU=
 google.golang.org/grpc v1.8.0/go.mod h1:yo6s7OP7yaDglbqo1J04qKzAhqBH6lvTonzMVmEdcZw=
 google.golang.org/grpc v1.19.0/go.mod h1:mqu4LbDTu4XGKhr4mRzUsmM4RtVoemTSY81AxZiDr8c=
 google.golang.org/grpc v1.20.1/go.mod h1:10oTOabMzJvdu6/UiuZezV6QK5dSlG84ov/aaiqXj38=
@@ -1283,16 +1242,11 @@ google.golang.org/grpc v1.35.0/go.mod h1:qjiiYl8FncCW8feJPdyg3v6XW24KsRHe+dy9BAG
 google.golang.org/grpc v1.36.0/go.mod h1:qjiiYl8FncCW8feJPdyg3v6XW24KsRHe+dy9BAGRRjU=
 google.golang.org/grpc v1.36.1/go.mod h1:qjiiYl8FncCW8feJPdyg3v6XW24KsRHe+dy9BAGRRjU=
 google.golang.org/grpc v1.37.0/go.mod h1:NREThFqKR1f3iQ6oBuvc5LadQuXVGo9rkm5ZGrQdJfM=
-google.golang.org/grpc v1.37.1/go.mod h1:NREThFqKR1f3iQ6oBuvc5LadQuXVGo9rkm5ZGrQdJfM=
 google.golang.org/grpc v1.38.0/go.mod h1:NREThFqKR1f3iQ6oBuvc5LadQuXVGo9rkm5ZGrQdJfM=
-google.golang.org/grpc v1.39.0/go.mod h1:PImNr+rS9TWYb2O4/emRugxiyHZ5JyHW5F+RPnDzfrE=
-google.golang.org/grpc v1.39.1/go.mod h1:PImNr+rS9TWYb2O4/emRugxiyHZ5JyHW5F+RPnDzfrE=
 google.golang.org/grpc v1.40.0/go.mod h1:ogyxbiOoUXAkP+4+xa6PZSE9DZgIHtSpzjDTB9KAK34=
-google.golang.org/grpc v1.40.1/go.mod h1:ogyxbiOoUXAkP+4+xa6PZSE9DZgIHtSpzjDTB9KAK34=
-google.golang.org/grpc v1.44.0/go.mod h1:k+4IHHFw41K8+bbowsex27ge2rCb65oeWqe4jJ590SU=
-google.golang.org/grpc v1.45.0 h1:NEpgUqV3Z+ZjkqMsxMg11IaDrXY4RY6CQukSGK0uI1M=
 google.golang.org/grpc v1.45.0/go.mod h1:lN7owxKUQEqMfSyQikvvk5tf/6zMPsrK+ONuO11+0rQ=
-google.golang.org/grpc/cmd/protoc-gen-go-grpc v1.1.0/go.mod h1:6Kw0yEErY5E/yWrBtf03jp27GLLJujG4z/JK95pnjjw=
+google.golang.org/grpc v1.56.3 h1:8I4C0Yq1EjstUzUJzpcRVbuYA2mODtEmpWiQoN/b2nc=
+google.golang.org/grpc v1.56.3/go.mod h1:I9bI3vqKfayGqPUAwGdOSu7kt6oIJLixfffKrpXqQ9s=
 google.golang.org/protobuf v0.0.0-20200109180630-ec00e32a8dfd/go.mod h1:DFci5gLYBciE7Vtevhsrf46CRTquxDuWsQurQQe4oz8=
 google.golang.org/protobuf v0.0.0-20200221191635-4d8936d0db64/go.mod h1:kwYJMbMJ01Woi6D6+Kah6886xMZcty6N08ah7+eCXa0=
 google.golang.org/protobuf v0.0.0-20200228230310-ab0ca4ff8a60/go.mod h1:cfTl7dwQJ+fmap5saPgwCLgHXTUD7jkjRqWcaiX5VyM=
@@ -1306,8 +1260,8 @@ google.golang.org/protobuf v1.25.0/go.mod h1:9JNX74DMeImyA3h4bdi1ymwjUzf21/xIlba
 google.golang.org/protobuf v1.26.0-rc.1/go.mod h1:jlhhOSvTdKEhbULTjvd4ARK9grFBp09yW+WbY/TyQbw=
 google.golang.org/protobuf v1.26.0/go.mod h1:9q0QmTI4eRPtz6boOQmLYwt+qCgq0jsYwAQnmE0givc=
 google.golang.org/protobuf v1.27.1/go.mod h1:9q0QmTI4eRPtz6boOQmLYwt+qCgq0jsYwAQnmE0givc=
-google.golang.org/protobuf v1.28.0 h1:w43yiav+6bVFTBQFZX0r7ipe9JQ1QsbMgHwbBziscLw=
-google.golang.org/protobuf v1.28.0/go.mod h1:HV8QOd/L58Z+nl8r43ehVNZIU/HEI6OcFqwMG9pJV4I=
+google.golang.org/protobuf v1.30.0 h1:kPPoIgf3TsEvrm0PFe15JQ+570QVxYzEvvHqChK+cng=
+google.golang.org/protobuf v1.30.0/go.mod h1:HV8QOd/L58Z+nl8r43ehVNZIU/HEI6OcFqwMG9pJV4I=
 gopkg.in/alecthomas/kingpin.v2 v2.2.6/go.mod h1:FMv+mEhP44yOT+4EoQTLFTRgOQ1FBLkstjWtayDeSgw=
 gopkg.in/check.v1 v0.0.0-20161208181325-20d25e280405/go.mod h1:Co6ibVJAznAaIkqp8huTwlJQCZ016jof/cbN4VW5Yz0=
 gopkg.in/check.v1 v1.0.0-20180628173108-788fd7840127/go.mod h1:Co6ibVJAznAaIkqp8huTwlJQCZ016jof/cbN4VW5Yz0=
@@ -1322,8 +1276,8 @@ gopkg.in/inf.v0 v0.9.1 h1:73M5CoZyi3ZLMOyDlQh031Cx6N9NDJ2Vvfl76EDAgDc=
 gopkg.in/inf.v0 v0.9.1/go.mod h1:cWUDdTG/fYaXco+Dcufb5Vnc6Gp2YChqWtbxRZE0mXw=
 gopkg.in/ini.v1 v1.51.0/go.mod h1:pNLf8WUiyNEtQjuu5G5vTm06TEv9tsIgeAvK8hOrP4k=
 gopkg.in/ini.v1 v1.62.0/go.mod h1:pNLf8WUiyNEtQjuu5G5vTm06TEv9tsIgeAvK8hOrP4k=
-gopkg.in/ini.v1 v1.66.2 h1:XfR1dOYubytKy4Shzc2LHrrGhU0lDCfDGG1yLPmpgsI=
-gopkg.in/ini.v1 v1.66.2/go.mod h1:pNLf8WUiyNEtQjuu5G5vTm06TEv9tsIgeAvK8hOrP4k=
+gopkg.in/ini.v1 v1.67.0 h1:Dgnx+6+nfE+IfzjUEISNeydPJh9AXNNsWbGP9KzCsOA=
+gopkg.in/ini.v1 v1.67.0/go.mod h1:pNLf8WUiyNEtQjuu5G5vTm06TEv9tsIgeAvK8hOrP4k=
 gopkg.in/natefinch/lumberjack.v2 v2.0.0/go.mod h1:l0ndWWf7gzL7RNwBG7wST/UCcT4T24xpD6X8LsfU/+k=
 gopkg.in/resty.v1 v1.12.0/go.mod h1:mDo4pnntr5jdWRML875a/NmxYqAlA73dVijT2AXvQQo=
 gopkg.in/square/go-jose.v2 v2.2.2/go.mod h1:M9dMgbHiYLoDGQrXy7OpJDJWiKiU//h+vD76mk0e1AI=
@@ -1359,16 +1313,18 @@ k8s.io/api v0.19.0/go.mod h1:I1K45XlvTrDjmj5LoM5LuP/KYrhWbjUKT/SoPG0qTjw=
 k8s.io/api v0.19.12/go.mod h1:EK+KvSq2urA6+CjVdZyAHEphXoLq2K2eW6lxOzTKSaY=
 k8s.io/api v0.22.2/go.mod h1:y3ydYpLJAaDI+BbSe2xmGcqxiWHmWjkEeIbiwHvnPR8=
 k8s.io/api v0.24.0/go.mod h1:5Jl90IUrJHUJYEMANRURMiVvJ0g7Ax7r3R1bqO8zx8I=
-k8s.io/api v0.24.2 h1:g518dPU/L7VRLxWfcadQn2OnsiGWVOadTLpdnqgY2OI=
 k8s.io/api v0.24.2/go.mod h1:AHqbSkTm6YrQ0ObxjO3Pmp/ubFF/KuM7jU+3khoBsOg=
+k8s.io/api v0.25.6 h1:LwDY2H6kD/3R8TekJYYaJWOdekNdXDO44eVpX6sNtJA=
+k8s.io/api v0.25.6/go.mod h1:bVp01KUcl8VUHFBTJMOknWNo7XvR0cMbeTTuFg1zCUs=
 k8s.io/apiextensions-apiserver v0.24.2 h1:/4NEQHKlEz1MlaK/wHT5KMKC9UKYz6NZz6JE6ov4G6k=
 k8s.io/apiextensions-apiserver v0.24.2/go.mod h1:e5t2GMFVngUEHUd0wuCJzw8YDwZoqZfJiGOW6mm2hLQ=
 k8s.io/apimachinery v0.19.0/go.mod h1:DnPGDnARWFvYa3pMHgSxtbZb7gpzzAZ1pTfaUNDVlmA=
 k8s.io/apimachinery v0.19.12/go.mod h1:9eb44nUQSsz9QZiilFRuMj3ZbTmoWolU8S2gnXoRMjo=
 k8s.io/apimachinery v0.22.2/go.mod h1:O3oNtNadZdeOMxHFVxOreoznohCpy0z6mocxbZr7oJ0=
 k8s.io/apimachinery v0.24.0/go.mod h1:82Bi4sCzVBdpYjyI4jY6aHX+YCUchUIrZrXKedjd2UM=
-k8s.io/apimachinery v0.24.2 h1:5QlH9SL2C8KMcrNJPor+LbXVTaZRReml7svPEh4OKDM=
 k8s.io/apimachinery v0.24.2/go.mod h1:82Bi4sCzVBdpYjyI4jY6aHX+YCUchUIrZrXKedjd2UM=
+k8s.io/apimachinery v0.25.6 h1:r6KIF2AHwLqFfZ0LcOA3I11SF62YZK83dxj1fn14NOQ=
+k8s.io/apimachinery v0.25.6/go.mod h1:1S2i1QHkmxc8+EZCIxe/fX5hpldVXk4gvnJInMEb8D4=
 k8s.io/apiserver v0.19.12/go.mod h1:ldZAZTNIKfMMv/UUEhk6UyTXC0/34iRdNFHo+MJOPc4=
 k8s.io/apiserver v0.24.2/go.mod h1:pSuKzr3zV+L+MWqsEo0kHHYwCo77AT5qXbFXP2jbvFI=
 k8s.io/cli-runtime v0.22.2/go.mod h1:tkm2YeORFpbgQHEK/igqttvPTRIHFRz5kATlw53zlMI=
@@ -1378,8 +1334,9 @@ k8s.io/client-go v0.19.0/go.mod h1:H9E/VT95blcFQnlyShFgnFT9ZnJOAceiUHM3MlRC+mU=
 k8s.io/client-go v0.19.12/go.mod h1:BAGKQraZ6fDmXhT46pGXWZQQqN7P4E0BJux0+9O6Gt0=
 k8s.io/client-go v0.22.2/go.mod h1:sAlhrkVDf50ZHx6z4K0S40wISNTarf1r800F+RlCF6U=
 k8s.io/client-go v0.24.0/go.mod h1:VFPQET+cAFpYxh6Bq6f4xyMY80G6jKKktU6G0m00VDw=
-k8s.io/client-go v0.24.2 h1:CoXFSf8if+bLEbinDqN9ePIDGzcLtqhfd6jpfnwGOFA=
 k8s.io/client-go v0.24.2/go.mod h1:zg4Xaoo+umDsfCWr4fCnmLEtQXyCNXCvJuSsglNcV30=
+k8s.io/client-go v0.25.6 h1:CHxACHi0DijmlYyUR7ooZoXnD5P8jYLgBHcxp775x/U=
+k8s.io/client-go v0.25.6/go.mod h1:s9mMAGFYiH3Z66j7BESzu0GEradT9GQ2LjFf/YRrnyc=
 k8s.io/code-generator v0.19.0/go.mod h1:moqLn7w0t9cMs4+5CQyxnfA/HV8MF6aAVENF+WZZhgk=
 k8s.io/code-generator v0.19.12/go.mod h1:ADrDvaUQWGn4a8lX0ONtzb7uFmDRQOMSYIMk1qWIAx8=
 k8s.io/code-generator v0.24.2/go.mod h1:dpVhs00hTuTdTY6jvVxvTFCk6gSMrtfRydbhZwHI15w=
@@ -1393,20 +1350,24 @@ k8s.io/gengo v0.0.0-20211129171323-c02415ce4185/go.mod h1:FiNAH4ZV3gBg2Kwh89tzAE
 k8s.io/klog/v2 v2.0.0/go.mod h1:PBfzABfn139FHAV07az/IF9Wp1bkk3vpT2XSJ76fSDE=
 k8s.io/klog/v2 v2.2.0/go.mod h1:Od+F08eJP+W3HUb4pSrPpgp9DGU4GzlpG/TmITuYh/Y=
 k8s.io/klog/v2 v2.9.0/go.mod h1:hy9LJ/NvuK+iVyP4Ehqva4HxZG/oXyIS3n3Jmire4Ec=
-k8s.io/klog/v2 v2.60.1 h1:VW25q3bZx9uE3vvdL6M8ezOX79vA2Aq1nEWLqNQclHc=
 k8s.io/klog/v2 v2.60.1/go.mod h1:y1WjHnz7Dj687irZUWR/WLkLc5N1YHtjLdmgWjndZn0=
+k8s.io/klog/v2 v2.70.1 h1:7aaoSdahviPmR+XkS7FyxlkkXs6tHISSG03RxleQAVQ=
+k8s.io/klog/v2 v2.70.1/go.mod h1:y1WjHnz7Dj687irZUWR/WLkLc5N1YHtjLdmgWjndZn0=
 k8s.io/kube-aggregator v0.19.12 h1:OwyNUe/7/gxzEnaLd3sC9Yrpx0fZAERzvFslX5Qq5g8=
 k8s.io/kube-aggregator v0.19.12/go.mod h1:K76wPd03pSHEmS1FgJOcpryac5C3va4cbCvSu+4EmE0=
 k8s.io/kube-openapi v0.0.0-20200805222855-6aeccd4b50c6/go.mod h1:UuqjUnNftUyPE5H64/qeyjQoUZhGpeFDVdxjTeEVN2o=
 k8s.io/kube-openapi v0.0.0-20210421082810-95288971da7e/go.mod h1:vHXdDvt9+2spS2Rx9ql3I8tycm3H9FDfdUoIuKCefvw=
 k8s.io/kube-openapi v0.0.0-20220328201542-3ee0da9b0b42/go.mod h1:Z/45zLw8lUo4wdiUkI+v/ImEGAvu3WatcZl3lPMR4Rk=
-k8s.io/kube-openapi v0.0.0-20220614142933-1062c7ade5f8 h1:IyQ1DifCBk589JD4Cm2CT2poIdO3lfPzz3WwVh1Ugf8=
-k8s.io/kube-openapi v0.0.0-20220614142933-1062c7ade5f8/go.mod h1:guXtiQW/y/AWAfPSOaI/1eY0TGBAmL5OygiIyUOKDRc=
+k8s.io/kube-openapi v0.0.0-20220803162953-67bda5d908f1 h1:MQ8BAZPZlWk3S9K4a9NCkIFQtZShWqoha7snGixVgEA=
+k8s.io/kube-openapi v0.0.0-20220803162953-67bda5d908f1/go.mod h1:C/N6wCaBHeBHkHUesQOQy2/MZqGgMAFPqGsGQLdbZBU=
+k8s.io/metrics v0.25.6 h1:EezfQTfTsSW/Cs9oHJXAftRlbL0fnHfDh02ObTOs/34=
+k8s.io/metrics v0.25.6/go.mod h1:LGcsjMsQQvt/4vrvQzqOIHv9/sIVov1ZE7HtQxc8d9w=
 k8s.io/utils v0.0.0-20200729134348-d5654de09c73/go.mod h1:jPW/WVKK9YHAvNhRxK0md/EJ228hCsBRufyofKtW8HA=
 k8s.io/utils v0.0.0-20210802155522-efc7438f0176/go.mod h1:jPW/WVKK9YHAvNhRxK0md/EJ228hCsBRufyofKtW8HA=
 k8s.io/utils v0.0.0-20210819203725-bdf08cb9a70a/go.mod h1:jPW/WVKK9YHAvNhRxK0md/EJ228hCsBRufyofKtW8HA=
-k8s.io/utils v0.0.0-20220210201930-3a6ce19ff2f9 h1:HNSDgDCrr/6Ly3WEGKZftiE7IY19Vz2GdbOCyI4qqhc=
 k8s.io/utils v0.0.0-20220210201930-3a6ce19ff2f9/go.mod h1:jPW/WVKK9YHAvNhRxK0md/EJ228hCsBRufyofKtW8HA=
+k8s.io/utils v0.0.0-20220728103510-ee6ede2d64ed h1:jAne/RjBTyawwAy0utX5eqigAwz/lQhTmy+Hr/Cpue4=
+k8s.io/utils v0.0.0-20220728103510-ee6ede2d64ed/go.mod h1:jPW/WVKK9YHAvNhRxK0md/EJ228hCsBRufyofKtW8HA=
 rsc.io/binaryregexp v0.2.0/go.mod h1:qTv7/COck+e2FymRvadv62gMdZztPaShugOCi3I+8D8=
 rsc.io/quote/v3 v3.1.0/go.mod h1:yEA65RcK8LyAZtP9Kv3t0HmxON59tX3rD+tICJqUlj0=
 rsc.io/sampler v1.3.0/go.mod h1:T1hPZKmBbMNahiBKFy5HrXp6adAjACjK9JXDnKaTXpA=
@@ -1415,8 +1376,8 @@ sigs.k8s.io/apiserver-network-proxy/konnectivity-client v0.0.30/go.mod h1:fEO7lR
 sigs.k8s.io/controller-runtime v0.12.2 h1:nqV02cvhbAj7tbt21bpPpTByrXGn2INHRsi39lXy9sE=
 sigs.k8s.io/controller-runtime v0.12.2/go.mod h1:qKsk4WE6zW2Hfj0G4v10EnNB2jMG1C+NTb8h+DwCoU0=
 sigs.k8s.io/json v0.0.0-20211208200746-9f7c6b3444d2/go.mod h1:B+TnT182UBxE84DiCz4CVE26eOSDAeYCpfDnC2kdKMY=
-sigs.k8s.io/json v0.0.0-20220525155127-227cbc7cc124 h1:2sgAQQcY0dEW2SsQwTXhQV4vO6+rSslYx8K3XmM5hqQ=
-sigs.k8s.io/json v0.0.0-20220525155127-227cbc7cc124/go.mod h1:B+TnT182UBxE84DiCz4CVE26eOSDAeYCpfDnC2kdKMY=
+sigs.k8s.io/json v0.0.0-20221116044647-bc3834ca7abd h1:EDPBXCAspyGV4jQlpZSudPeMmr1bNJefnuqLsRAsHZo=
+sigs.k8s.io/json v0.0.0-20221116044647-bc3834ca7abd/go.mod h1:B8JuhiUyNFVKdsE8h686QcCxMaH6HrOAZj4vswFpcB0=
 sigs.k8s.io/kustomize/api v0.8.11/go.mod h1:a77Ls36JdfCWojpUqR6m60pdGY1AYFix4AH83nJtY1g=
 sigs.k8s.io/kustomize/api v0.11.4/go.mod h1:k+8RsqYbgpkIrJ4p9jcdPqe8DprLxFUUO0yNOq8C+xI=
 sigs.k8s.io/kustomize/kyaml v0.11.0/go.mod h1:GNMwjim4Ypgp/MueD3zXHLRJEjz7RvtPae0AwlvEMFM=
@@ -1425,8 +1386,9 @@ sigs.k8s.io/structured-merge-diff/v4 v4.0.1/go.mod h1:bJZC9H9iH24zzfZ/41RGcq60oK
 sigs.k8s.io/structured-merge-diff/v4 v4.0.2/go.mod h1:bJZC9H9iH24zzfZ/41RGcq60oK1F7G282QMXDPYydCw=
 sigs.k8s.io/structured-merge-diff/v4 v4.0.3/go.mod h1:bJZC9H9iH24zzfZ/41RGcq60oK1F7G282QMXDPYydCw=
 sigs.k8s.io/structured-merge-diff/v4 v4.1.2/go.mod h1:j/nl6xW8vLS49O8YvXW1ocPhZawJtm+Yrr7PPRQ0Vg4=
-sigs.k8s.io/structured-merge-diff/v4 v4.2.1 h1:bKCqE9GvQ5tiVHn5rfn1r+yao3aLQEaLzkkmAkf+A6Y=
 sigs.k8s.io/structured-merge-diff/v4 v4.2.1/go.mod h1:j/nl6xW8vLS49O8YvXW1ocPhZawJtm+Yrr7PPRQ0Vg4=
+sigs.k8s.io/structured-merge-diff/v4 v4.2.3 h1:PRbqxJClWWYMNV1dhaG4NsibJbArud9kFxnAMREiWFE=
+sigs.k8s.io/structured-merge-diff/v4 v4.2.3/go.mod h1:qjx8mGObPmV2aSZepjQjbmb2ihdVs8cGKBraizNC69E=
 sigs.k8s.io/yaml v1.1.0/go.mod h1:UJmg0vDUVViEyp3mgSv9WPwZCDxu4rQW1olrI1uml+o=
 sigs.k8s.io/yaml v1.2.0/go.mod h1:yfXDCHCao9+ENCvLSE62v9VSji2MKu5jeNfTrofGhJc=
 sigs.k8s.io/yaml v1.3.0 h1:a2VclLzOGrwOHDiV8EfBGhvjHvP46CtW5j6POvhYGGo=

golangci.yaml

@@ -7,18 +7,11 @@ run:
   concurrency: 4
 
   # timeout for analysis, e.g. 30s, 5m, default is 1m
-  timeout: 5m
+  timeout: 20m
 
   # exit code when at least one issue was found, default is 1
   issues-exit-code: 1
 
-  # include test files or not, default is true
-  tests: true
-
-  # list of build tags, all linters use it. Default is empty list.
-  #build-tags:
-  #  - mytag
-
   # which dirs to skip: issues from them won't be reported;
   # can use regexp here: generated.*, regexp is applied on full path;
   # default value is empty list, but default dirs are skipped independently
@@ -26,7 +19,8 @@ run:
   # "/" will be replaced by current OS file path separator to properly work
   # on Windows.
   skip-dirs:
-    - test/e2e/*
+    - test/*
+    - pkg/plugin/generated/*
   #  - autogenerated_by_my_lib
 
   # default is true. Enables skipping of directories:
@@ -188,7 +182,7 @@ linters-settings:
         #     reason: "testing if blocked version constraint works."  # Reason why the version constraint exists. (Optional)
   govet:
     # report about shadowed variables
-    check-shadowing: true
+    # check-shadowing: true
 
     # settings per analyzer
     settings:
@@ -207,12 +201,12 @@ linters-settings:
       - shadow
     disable-all: false
   depguard:
-    list-type: blacklist
+    list-type: blacklist # Velero.io word list : ignore
     include-go-root: false
     packages:
       - github.com/sirupsen/logrus
     packages-with-error-message:
-      # specify an error message to output when a blacklisted package is used
+      # specify an error message to output when a denylisted package is used
       - github.com/sirupsen/logrus: "logging is allowed only by logutils.Log"
   lll:
     # max line length, lines longer will be reported. Default is 120.
@@ -253,6 +247,11 @@ linters-settings:
     require-explanation: true
     # Enable to require nolint directives to mention the specific linter being suppressed. Default is false.
     require-specific: true
+  revive:
+    rules:
+      - name: unexported-return
+        disabled: true
+    
   rowserrcheck:
     packages:
       - github.com/jmoiron/sqlx
@@ -294,76 +293,53 @@ linters-settings:
     # Allow leading comments to be separated with empty liens
     allow-separated-leading-comment: false
 
-  # The custom section can be used to define linter plugins to be loaded at runtime. See README doc
-  #  for more info.
-  # custom:
-    # Each custom linter should have a unique name.
-    #  example:
-      # The path to the plugin *.so. Can be absolute or local. Required for each custom linter
-      # path: /path/to/example.so
-      # The description of the linter. Optional, just for documentation purposes.
-      # description: This is an example usage of a plugin linter.
-      # Intended to point to the repo location of the linter. Optional, just for documentation purposes.
-      # original-url: github.com/golangci/example-linter
-
 linters:
-#  enable:
-#    - megacheck
-#    - govet
-# disable:
-#    - maligned
-#    - prealloc
   disable-all: true
-  presets:
-#    - bugs
-#    - unused
+  enable:
+    - asasalint
+    - asciicheck
+    - bidichk
+    - bodyclose
+    - dogsled
+    - durationcheck
+    - errcheck
+    - exportloopref
+    - goconst
+    - gofmt
+    - goheader
+    - goimports
+    - goprintffuncname
+    - gosec
+    - gosimple
+    - govet
+    - importas
+    - ineffassign
+    - misspell
+    - nakedret
+    - nosprintfhostport
+    - staticcheck
+    - stylecheck
+    - revive
+    - typecheck
+    - unconvert
+    - unparam
+    - unused
+    - usestdlibvars
+    - whitespace
   fast: false
 
 
 issues:
-#  # List of regexps of issue texts to exclude, empty list by default.
-#  # But independently from this option we use default exclude patterns,
-#  # it can be disabled by `exclude-use-default: false`. To list all
-#  # excluded by default patterns execute `golangci-lint run --help`
-#  exclude:
-#    - abcdef
-#
-#  # Excluding configuration per-path, per-linter, per-text and per-source
-#  exclude-rules:
-#    # Exclude some linters from running on tests files.
-#    - path: _test\.go
-#      linters:
-#        - gocyclo
-#        - errcheck
-#        - dupl
-#        - gosec
-#
-#    # Exclude known linters from partially hard-vendored code,
-#    # which is impossible to exclude via "nolint" comments.
-#    - path: internal/hmac/
-#      text: "weak cryptographic primitive"
-#      linters:
-#        - gosec
-#
-#    # Exclude some staticcheck messages
-#    - linters:
-#        - staticcheck
-#      text: "SA9003:"
-#
-#    # Exclude lll issues for long lines with go:generate
-#    - linters:
-#        - lll
-#      source: "^//go:generate "
-
-  # Independently from option `exclude` we use default exclude patterns,
-  # it can be disabled by this option. To list all
-  # excluded by default patterns execute `golangci-lint run --help`.
-  # Default value for this option is true.
-  exclude-use-default: true
-
-  # The default value is false. If set to true exclude and exclude-rules
-  # regular expressions become case sensitive.
-  exclude-case-sensitive: false
+  exclude-rules:
+    - linters:
+        - staticcheck
+      text: "github.com/golang/protobuf/proto" # grpc-go still uses github.com/golang/protobuf/proto.
+    - linters:
+        - staticcheck
+      text: "github.com/Azure/azure-sdk-for-go/services/storage/mgmt/2019-06-01/storage" # Kopia still depends on this.
+    - linters:
+        - staticcheck
+      text: "DefaultVolumesToRestic" # No need to report deprecate for DefaultVolumesToRestic.
 
   # The list of ids of default excludes to include or disable. By default it's empty.
   include:
@@ -375,19 +351,8 @@ issues:
   # Maximum count of issues with the same text. Set to 0 to disable. Default is 3.
   max-same-issues: 0
 
-  # Show only new issues: if there are unstaged changes or untracked files,
-  # only those changes are analyzed, else only changes in HEAD~ are analyzed.
-  # It's a super-useful option for integration of golangci-lint into existing
-  # large codebase. It's not practical to fix all existing issues at the moment
-  # of integration: much better don't allow issues in new code.
-  # Default is false.
-  new: false
-
   # Show only new issues created after git revision `REV`
-  new-from-rev: REV
-
-  # Show only new issues created in git patch with set file path.
-  new-from-patch: path/to/patch/file
+  # new-from-rev: origin/main
 
 severity:
   # Default value is empty string.
@@ -412,4 +377,4 @@ severity:
   rules:
     - linters:
       - dupl
-      severity: info
+      severity: info

hack/build-image/Dockerfile

@@ -12,7 +12,7 @@
 # See the License for the specific language governing permissions and
 # limitations under the License.
 
-FROM --platform=linux/amd64 golang:1.20.3-bullseye
+FROM --platform=linux/amd64 golang:1.20.10-bullseye
 
 ARG GOPROXY
 
@@ -30,7 +30,7 @@ RUN wget --quiet https://github.com/kubernetes-sigs/kubebuilder/releases/downloa
     chmod +x /usr/local/kubebuilder/bin/kubebuilder
 
 # get controller-tools
-RUN go install sigs.k8s.io/controller-tools/cmd/controller-gen@v0.7.0
+RUN go install sigs.k8s.io/controller-tools/cmd/controller-gen@v0.12.0
 
 # get goimports (the revision is pinned so we don't indiscriminately update, but the particular commit
 # is not important)
@@ -42,11 +42,15 @@ RUN apt-get update && apt-get install -y unzip
 RUN wget --quiet https://github.com/protocolbuffers/protobuf/releases/download/v3.14.0/protoc-3.14.0-linux-x86_64.zip && \
     unzip protoc-3.14.0-linux-x86_64.zip && \
     mv bin/protoc /usr/bin/protoc && \
+    mv include/google /usr/include && \
+    chmod a+x  /usr/include/google && \
+    chmod a+x  /usr/include/google/protobuf && \
+    chmod a+r -R /usr/include/google && \
     chmod +x /usr/bin/protoc
 RUN go install github.com/golang/protobuf/protoc-gen-go@v1.4.3
 
 # get goreleaser
-RUN wget --quiet https://github.com/goreleaser/goreleaser/releases/download/v0.120.8/goreleaser_Linux_x86_64.tar.gz && \
+RUN wget --quiet https://github.com/goreleaser/goreleaser/releases/download/v1.15.2/goreleaser_Linux_x86_64.tar.gz && \
     tar xvf goreleaser_Linux_x86_64.tar.gz && \
     mv goreleaser /usr/bin/goreleaser && \
     chmod +x /usr/bin/goreleaser

hack/crd-gen/v1/main.go

@@ -14,8 +14,7 @@ See the License for the specific language governing permissions and
 limitations under the License.
 */
 
-// This code embeds the CRD manifests in config/crd/v1/bases in
-// config/crd/v1/crds/crds.go.
+// This code embeds the CRD manifests in ../bases in ../crds/crds.go
 
 package main
 
@@ -24,7 +23,6 @@ import (
 	"compress/gzip"
 	"fmt"
 	"io"
-	"io/ioutil"
 	"log"
 	"os"
 	"text/template"
@@ -41,7 +39,7 @@ package crds
 import (
 	"bytes"
 	"compress/gzip"
-	"io/ioutil"
+	"io"
 
 	apiextinstall "k8s.io/apiextensions-apiserver/pkg/apis/apiextensions/install"
 	apiextv1 "k8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1"
@@ -65,7 +63,7 @@ func crds() []*apiextv1.CustomResourceDefinition {
 		if err != nil {
 			panic(err)
 		}
-		bytes, err := ioutil.ReadAll(gzr)
+		bytes, err := io.ReadAll(gzr)
 		if err != nil {
 			panic(err)
 		}
@@ -87,7 +85,7 @@ type templateData struct {
 }
 
 func main() {
-	headerBytes, err := ioutil.ReadFile(goHeaderFile)
+	headerBytes, err := os.ReadFile(goHeaderFile)
 	if err != nil {
 		log.Fatalln(err)
 	}
@@ -97,7 +95,7 @@ func main() {
 	}
 
 	// This is relative to config/crd/crds
-	manifests, err := ioutil.ReadDir("../bases")
+	manifests, err := os.ReadDir("../bases")
 	if err != nil {
 		log.Fatalln(err)
 	}

hack/docker-push.sh

@@ -89,7 +89,7 @@ else
 fi
 
 if [[ -z "$BUILDX_PLATFORMS" ]]; then
-    BUILDX_PLATFORMS="linux/amd64,linux/arm64,linux/arm/v7,linux/ppc64le"
+    BUILDX_PLATFORMS="linux/amd64,linux/arm64"
 fi
 
 # Debugging info

hack/fix_restic_cve.txt

@@ -1,36 +1,49 @@
 diff --git a/go.mod b/go.mod
-index 5f939c481..6f281b45d 100644
+index 5f939c481..3f5ea4096 100644
 --- a/go.mod
 +++ b/go.mod
-@@ -25,12 +25,12 @@ require (
+@@ -24,13 +24,13 @@ require (
+ 	github.com/restic/chunker v0.4.0
  	github.com/spf13/cobra v1.6.1
  	github.com/spf13/pflag v1.0.5
- 	golang.org/x/crypto v0.5.0
+-	golang.org/x/crypto v0.5.0
 -	golang.org/x/net v0.5.0
-+	golang.org/x/net v0.7.0
++	golang.org/x/crypto v0.14.0
++	golang.org/x/net v0.17.0
  	golang.org/x/oauth2 v0.4.0
  	golang.org/x/sync v0.1.0
 -	golang.org/x/sys v0.4.0
 -	golang.org/x/term v0.4.0
 -	golang.org/x/text v0.6.0
-+	golang.org/x/sys v0.5.0
-+	golang.org/x/term v0.5.0
-+	golang.org/x/text v0.7.0
++	golang.org/x/sys v0.13.0
++	golang.org/x/term v0.13.0
++	golang.org/x/text v0.13.0
  	google.golang.org/api v0.106.0
  )
  
 diff --git a/go.sum b/go.sum
-index 026e1d2fa..da35b7a6c 100644
+index 026e1d2fa..f24fef5b8 100644
 --- a/go.sum
 +++ b/go.sum
+@@ -172,8 +172,8 @@ golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2/go.mod h1:djNgcEr1/C05ACk
+ golang.org/x/crypto v0.0.0-20191011191535-87dc89f01550/go.mod h1:yigFU9vqHzYiE8UmvKecakEJjdnWj3jj499lnFckfCI=
+ golang.org/x/crypto v0.0.0-20200622213623-75b288015ac9/go.mod h1:LzIPMQfyMNhhGPhUkYOs5KpL4U8rLKemX1yGLhDgUto=
+ golang.org/x/crypto v0.0.0-20211215153901-e495a2d5b3d3/go.mod h1:IxCIyHEi3zRg3s0A5j5BB6A9Jmi73HwBIUl50j+osU4=
+-golang.org/x/crypto v0.5.0 h1:U/0M97KRkSFvyD/3FSmdP5W5swImpNgle/EHFhOsQPE=
+-golang.org/x/crypto v0.5.0/go.mod h1:NK/OQwhpMQP3MwtdjgLlYHnH9ebylxKWv3e0fK+mkQU=
++golang.org/x/crypto v0.14.0 h1:wBqGXzWJW6m1XrIKlAH0Hs1JJ7+9KBwnIO8v66Q9cHc=
++golang.org/x/crypto v0.14.0/go.mod h1:MVFd36DqK4CsrnJYDkBA3VC4m2GkXAM0PvzMCn4JQf4=
+ golang.org/x/exp v0.0.0-20190121172915-509febef88a4/go.mod h1:CJ0aWSM057203Lf6IL+f9T1iT9GByDxfZKAQTCR3kQA=
+ golang.org/x/lint v0.0.0-20181026193005-c67002cb31c3/go.mod h1:UVdnD1Gm6xHRNCYTkRU2/jEulfH38KcIWyp/GAMgvoE=
+ golang.org/x/lint v0.0.0-20190227174305-5b3e6a55c961/go.mod h1:wehouNa3lNwaWXcvxsM5YxQ5yQlVC4a0KAMCusXpPoU=
 @@ -189,8 +189,8 @@ golang.org/x/net v0.0.0-20190620200207-3b0461eec859/go.mod h1:z5CRVTTTmAJ677TzLL
  golang.org/x/net v0.0.0-20200226121028-0de0cce0169b/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s=
  golang.org/x/net v0.0.0-20201110031124-69a78807bb2b/go.mod h1:sp8m0HH+o8qH0wwXwYZr8TS3Oi6o0r6Gce1SSxlDquU=
  golang.org/x/net v0.0.0-20211112202133-69e39bad7dc2/go.mod h1:9nx3DQGgdP8bBQD5qxJ1jj9UTztislL4KSBs9R2vV5Y=
 -golang.org/x/net v0.5.0 h1:GyT4nK/YDHSqa1c4753ouYCDajOYKTja9Xb/OHtgvSw=
 -golang.org/x/net v0.5.0/go.mod h1:DivGGAXEgPSlEBzxGzZI+ZLohi+xUj054jfeKui00ws=
-+golang.org/x/net v0.7.0 h1:rJrUqqhjsgNp7KqAIc25s9pZnjU7TUcSY7HcVZjdn1g=
-+golang.org/x/net v0.7.0/go.mod h1:2Tu9+aMcznHK/AK1HMvgo6xiTLG5rD5rZLDS+rp2Bjs=
++golang.org/x/net v0.17.0 h1:pVaXccu2ozPjCXewfr1S7xza/zcXTity9cCdXQYSjIM=
++golang.org/x/net v0.17.0/go.mod h1:NxSsAGuq816PNPmqtQdLE42eU2Fs7NoRIZrHJAlaCOE=
  golang.org/x/oauth2 v0.0.0-20180821212333-d2e6202438be/go.mod h1:N/0e6XlmueqKjAGxoOufVs8QHGRruUQn6yWY3a++T0U=
  golang.org/x/oauth2 v0.4.0 h1:NF0gk8LVPg1Ml7SSbGyySuoxdsXitj7TvgvuRxIMc/M=
  golang.org/x/oauth2 v0.4.0/go.mod h1:RznEsdpjGAINPTOF0UH/t+xJ75L18YO3Ho6Pyn+uRec=
@@ -40,21 +53,21 @@ index 026e1d2fa..da35b7a6c 100644
  golang.org/x/sys v0.0.0-20220715151400-c0bba94af5f8/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
 -golang.org/x/sys v0.4.0 h1:Zr2JFtRQNX3BCZ8YtxRE9hNJYC8J6I1MVbMg6owUp18=
 -golang.org/x/sys v0.4.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
-+golang.org/x/sys v0.5.0 h1:MUK/U/4lj1t1oPg0HfuXDN/Z1wv31ZJ/YcPiGccS4DU=
-+golang.org/x/sys v0.5.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
++golang.org/x/sys v0.13.0 h1:Af8nKPmuFypiUBjVoU9V20FiaFXOcuZI21p0ycVYYGE=
++golang.org/x/sys v0.13.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
  golang.org/x/term v0.0.0-20201126162022-7de9c90e9dd1/go.mod h1:bj7SfCRtBDWHUb9snDiAeCFNEtKQo2Wmx5Cou7ajbmo=
 -golang.org/x/term v0.4.0 h1:O7UWfv5+A2qiuulQk30kVinPoMtoIPeVaKLEgLpVkvg=
 -golang.org/x/term v0.4.0/go.mod h1:9P2UbLfCdcvo3p/nzKvsmas4TnlujnuoV9hGgYzW1lQ=
-+golang.org/x/term v0.5.0 h1:n2a8QNdAb0sZNpU9R1ALUXBbY+w51fCQDN+7EdxNBsY=
-+golang.org/x/term v0.5.0/go.mod h1:jMB1sMXY+tzblOD4FWmEbocvup2/aLOaQEp7JmGp78k=
++golang.org/x/term v0.13.0 h1:bb+I9cTfFazGW51MZqBVmZy7+JEJMouUHTUSKVQLBek=
++golang.org/x/term v0.13.0/go.mod h1:LTmsnFJwVN6bCy1rVCoS+qHT1HhALEFxKncY3WNNh4U=
  golang.org/x/text v0.3.0/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ=
  golang.org/x/text v0.3.2/go.mod h1:bEr9sfX3Q8Zfm5fL9x+3itogRgK3+ptLWKqgva+5dAk=
  golang.org/x/text v0.3.3/go.mod h1:5Zoc/QRtKVWzQhOtBMvqHzDpF6irO9z98xDceosuGiQ=
  golang.org/x/text v0.3.6/go.mod h1:5Zoc/QRtKVWzQhOtBMvqHzDpF6irO9z98xDceosuGiQ=
 -golang.org/x/text v0.6.0 h1:3XmdazWV+ubf7QgHSTWeykHOci5oeekaGJBLkrkaw4k=
 -golang.org/x/text v0.6.0/go.mod h1:mrYo+phRRbMaCq/xk9113O4dZlRixOauAjOtrjsXDZ8=
-+golang.org/x/text v0.7.0 h1:4BRB4x83lYWy72KwLD/qYDuTu7q9PjSagHvijDw7cLo=
-+golang.org/x/text v0.7.0/go.mod h1:mrYo+phRRbMaCq/xk9113O4dZlRixOauAjOtrjsXDZ8=
++golang.org/x/text v0.13.0 h1:ablQoSUd0tRdKxZewP80B+BaqeKJuVhuRxj/dkrun3k=
++golang.org/x/text v0.13.0/go.mod h1:TvPlkZtksWOMsz7fbANvkp4WM8x/WCo/om8BMLbz+aE=
  golang.org/x/tools v0.0.0-20180917221912-90fa682c2a6e/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ=
  golang.org/x/tools v0.0.0-20190114222345-bf090417da8b/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ=
  golang.org/x/tools v0.0.0-20190226205152-f727befe758c/go.mod h1:9Yl7xja0Znq3iFh3HoIrodX9oNMXvdceNzlUR8zjMvY=

hack/lint.sh

@@ -14,23 +14,14 @@
 # See the License for the specific language governing permissions and
 # limitations under the License.
 
-LINTERS=${1:-"gosec,goconst,gofmt,goimports,unparam"}
-ALL=${2:-false}
-
 HACK_DIR=$(dirname "${BASH_SOURCE[0]}")
 
 # Printing out cache status
 golangci-lint cache status
 
-if [[ $ALL == true ]] ; then
-  action=""
-else
-  action="-n"
-fi
-
 # Enable GL_DEBUG line below for debug messages for golangci-lint
 # export GL_DEBUG=loader,gocritic,env
-CMD="golangci-lint run -E ${LINTERS} $action -c  $HACK_DIR/../golangci.yaml"
+CMD="golangci-lint run -c $HACK_DIR/../golangci.yaml"
 echo "Running $CMD"
 
 eval $CMD

hack/release-tools/chk_version.go

@@ -29,20 +29,19 @@ import (
 //	minor
 //	patch
 //	prerelease (this will be alpha/beta/rc followed by a ".", followed by 1 or more digits (alpha.5)
-var release_regex *regexp.Regexp = regexp.MustCompile("^v(?P<major>[[:digit:]]+)\\.(?P<minor>[[:digit:]]+)\\.(?P<patch>[[:digit:]]+)(-{1}(?P<prerelease>(alpha|beta|rc)\\.[[:digit:]]+))*")
+var releaseRegex = regexp.MustCompile(`^v(?P<major>[[:digit:]]+)\.(?P<minor>[[:digit:]]+)\.(?P<patch>[[:digit:]]+)(-{1}(?P<prerelease>(alpha|beta|rc)\.[[:digit:]]+))*`)
 
 // This small program exists because checking the VELERO_VERSION rules in bash is difficult, and difficult to test for correctness.
 // Calling it with --verify will verify whether or not the VELERO_VERSION environment variable is a valid version string, without parsing for its components.
 // Calling it without --verify will try to parse the version into its component pieces.
 func main() {
+	veleroVersion := os.Getenv("VELERO_VERSION")
 
-	velero_version := os.Getenv("VELERO_VERSION")
-
-	submatches := reSubMatchMap(release_regex, velero_version)
+	submatches := reSubMatchMap(releaseRegex, veleroVersion)
 
 	// Didn't match the regex, exit.
 	if len(submatches) == 0 {
-		fmt.Printf("VELERO_VERSION of %s was not valid. Please correct the value and retry.", velero_version)
+		fmt.Printf("VELERO_VERSION of %s was not valid. Please correct the value and retry.", veleroVersion)
 		os.Exit(1)
 	}
 

hack/release-tools/chk_version_test.go

@@ -56,7 +56,7 @@ func TestRegexMatching(t *testing.T) {
 	for _, test := range tests {
 		name := fmt.Sprintf("Testing version string %s", test.version)
 		t.Run(name, func(t *testing.T) {
-			results := reSubMatchMap(release_regex, test.version)
+			results := reSubMatchMap(releaseRegex, test.version)
 
 			if len(results) == 0 && test.expectMatch {
 				t.Fail()

hack/release-tools/goreleaser.sh

@@ -41,17 +41,21 @@ else
     export GIT_TREE_STATE=dirty
 fi
 
+# Verify .goreleaser.yml format first.
+echo "Start to verify .goreleaser.yml format"
+goreleaser check
+
 # $PUBLISH must explicitly be set to 'TRUE' for goreleaser
 # to publish the release to GitHub.
 if [[ "${PUBLISH:-}" != "TRUE" ]]; then
     echo "Not set to publish"
     goreleaser release \
-        --rm-dist \
+        --clean \
         --release-notes="${RELEASE_NOTES_FILE}" \
-        --skip-publish
+        --snapshot # Generate an unversioned snapshot release, skipping all validations and without publishing any artifacts (implies --skip-publish, --skip-announce and --skip-validate)
 else
     echo "Getting ready to publish"
     goreleaser release \
-        --rm-dist \
+        --clean \
         --release-notes="${RELEASE_NOTES_FILE}"
 fi