Add missing files

.github/ISSUE_TEMPLATE/bug_report.md

@@ -10,13 +10,10 @@ about: Tell us about a problem you are experiencing
 
 **What did you expect to happen:**
 
-**The following information will help us better understand what's going on**:
 
-_If you are using velero v1.7.0+:_  
-Please use `velero debug  --backup <backupname> --restore <restorename>` to generate the support bundle, and attach to this issue, more options please refer to `velero debug --help` 
+**The output of the following commands will help us better understand what's going on**:
+(Pasting long output into a [GitHub gist](https://gist.github.com) or other pastebin is fine.)
 
-_If you are using earlier versions:_  
-Please provide the output of the following commands (Pasting long output into a [GitHub gist](https://gist.github.com) or other pastebin is fine.)
 - `kubectl logs deployment/velero -n velero`
 - `velero backup describe <backupname>` or `kubectl get backup/<backupname> -n velero -o yaml`
 - `velero backup logs <backupname>`

.github/auto-assignees.yml

@@ -9,14 +9,12 @@ reviewers:
 
   groups:
     maintainers:
+      - zubron
       - dsu-igeek
+      - jenting
       - sseago
       - reasonerjt
       - ywk253100
-      - blackpiglet
-      - qiuming-best
-      - shubham-pampattiwar
-      - Lyndon-Li
 
     tech-writer:
       - a-mccarthy

.github/dependabot.yml

@@ -1,12 +0,0 @@
-version: 2
-updates:
-  # Dependencies listed in go.mod
-  - package-ecosystem: "gomod"
-    directory: "/" # Location of package manifests
-    schedule:
-      interval: "weekly"
-    labels:
-      - "kind/changelog-not-required"
-    ignore:
-      - dependency-name: "*"
-        update-types: ["version-update:semver-major", "version-update:semver-minor", "version-update:semver-patch"]

.github/pull_request_template.md

@@ -9,5 +9,5 @@ Fixes #(issue)
 # Please indicate you've done the following:
 
 - [ ] [Accepted the DCO](https://velero.io/docs/v1.5/code-standards/#dco-sign-off). Commits without the DCO will delay acceptance.
-- [ ] [Created a changelog file](https://velero.io/docs/v1.5/code-standards/#adding-a-changelog) or added `/kind changelog-not-required` as a comment on this pull request.
+- [ ] [Created a changelog file](https://velero.io/docs/v1.5/code-standards/#adding-a-changelog) or added `/kind changelog-not-required`.
 - [ ] Updated the corresponding documentation in `site/content/docs/main`.

.github/stale.yml

@@ -14,15 +14,9 @@ exemptLabels:
   - 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

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

@@ -14,7 +14,7 @@ jobs:
       - name: Set up Go
         uses: actions/setup-go@v2
         with:
-          go-version: 1.20.3
+          go-version: 1.16
         id: go
       # Look for a CLI that's made for this PR
       - name: Fetch built CLI
@@ -57,13 +57,14 @@ jobs:
       matrix:
         # Latest k8s versions. There's no series-based tag, nor is there a latest tag.
         k8s:
+          - 1.15.12
+          - 1.16.15
+          - 1.17.17
+          - 1.18.15
           - 1.19.7
           - 1.20.2
           - 1.21.1
           - 1.22.0
-          - 1.23.6
-          - 1.24.2
-          - 1.25.3
     # All steps run in parallel unless otherwise specified.
     # See https://docs.github.com/en/actions/learn-github-actions/managing-complex-workflows#creating-dependent-jobs
     steps:
@@ -81,7 +82,7 @@ jobs:
             velero-${{ github.event.pull_request.number }}-
       - uses: engineerd/setup-kind@v0.5.0
         with:
-          version: "v0.17.0"
+          version: "v0.11.1"
           image: "kindest/node:v${{ matrix.k8s }}"
       - name: Install CRDs
         run: |

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

@@ -14,7 +14,7 @@ jobs:
       - name: Set up Go
         uses: actions/setup-go@v2
         with:
-          go-version: 1.20.3
+          go-version: 1.16
         id: go
       # Look for a CLI that's made for this PR
       - name: Fetch built CLI
@@ -60,19 +60,21 @@ jobs:
     strategy:
       matrix:
         k8s:
-          - 1.19.16
-          - 1.20.15
-          - 1.21.12
-          - 1.22.9
-          - 1.23.6
-          - 1.24.0
-          - 1.25.3
+          # doesn't cover 1.15 as 1.15 doesn't support "apiextensions.k8s.io/v1" that is needed for the case
+          #- 1.15.12
+          - 1.16.15
+          - 1.17.17
+          - 1.18.15
+          - 1.19.7
+          - 1.20.2
+          - 1.21.1
+          - 1.22.0
       fail-fast: false
     steps:
       - name: Set up Go
         uses: actions/setup-go@v2
         with:
-          go-version: 1.20.3
+          go-version: 1.16
         id: go
       - name: Check out the code
         uses: actions/checkout@v2
@@ -81,7 +83,7 @@ jobs:
           docker run -d --rm -p 9000:9000 -e "MINIO_ACCESS_KEY=minio" -e "MINIO_SECRET_KEY=minio123" -e "MINIO_DEFAULT_BUCKETS=bucket,additional-bucket" bitnami/minio:2021.6.17-debian-10-r7
       - uses: engineerd/setup-kind@v0.5.0
         with:
-          version: "v0.17.0"
+          version: "v0.11.1"
           image: "kindest/node:v${{ matrix.k8s }}"
       - name: Fetch built CLI
         id: cli-cache
@@ -113,22 +115,10 @@ jobs:
           aws_access_key_id=minio
           aws_secret_access_key=minio123
           EOF
-
-          # Match kubectl version to k8s server version
-          curl -LO https://dl.k8s.io/release/v${{ matrix.k8s }}/bin/linux/amd64/kubectl
-          sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
-
           GOPATH=~/go CLOUD_PROVIDER=kind \
               OBJECT_STORE_PROVIDER=aws BSL_CONFIG=region=minio,s3ForcePathStyle="true",s3Url=http://$(hostname -i):9000 \
               CREDS_FILE=/tmp/credential BSL_BUCKET=bucket \
               ADDITIONAL_OBJECT_STORE_PROVIDER=aws ADDITIONAL_BSL_CONFIG=region=minio,s3ForcePathStyle="true",s3Url=http://$(hostname -i):9000 \
               ADDITIONAL_CREDS_FILE=/tmp/credential ADDITIONAL_BSL_BUCKET=additional-bucket \
-              GINKGO_FOCUS='Basic\]\[ClusterResource' VELERO_IMAGE=velero:pr-test \
-              make -C test/e2e run
-        timeout-minutes: 30
-      - name: Upload debug bundle
-        if: ${{ failure() }}
-        uses: actions/upload-artifact@v2
-        with:
-          name: DebugBundle
-          path: /home/runner/work/velero/velero/test/e2e/debug-bundle*
+              GINKGO_FOCUS=Basic VELERO_IMAGE=velero:pr-test \
+              make -C test/e2e run

.github/workflows/opened-issues-triage.yml

@@ -0,0 +1,15 @@
+name: Move new issues into Triage
+
+on:
+  issues:
+    types: [opened]
+
+jobs:
+  automate-project-columns:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: alex-page/github-project-automation-plus@v0.3.0
+        with:
+          project: "Velero Support Board"
+          column: "New"
+          repo-token: ${{ secrets.GH_TOKEN }}

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

@@ -1,9 +1,5 @@
 name: Pull Request Changelog Check
-# by setting `on: [pull_request]`, that means action will be trigger when PR is opened, synchronize, reopened.
-# Add labeled and unlabeled events too.
-on:
-  pull_request:
-    types: [opened, synchronize, reopened, labeled, unlabeled]
+on: [pull_request]
 jobs:
 
   build:

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

@@ -8,7 +8,7 @@ jobs:
       - name: Set up Go
         uses: actions/setup-go@v2
         with:
-          go-version: 1.20.3
+          go-version: 1.16
         id: go
       - name: Check out the code
         uses: actions/checkout@v2
@@ -21,9 +21,3 @@ jobs:
             ${{ runner.os }}-go-
       - name: Make ci
         run: make ci
-      - name: Upload test coverage
-        uses: codecov/codecov-action@v2
-        with:
-          token: ${{ secrets.CODECOV_TOKEN }}
-          files: coverage.out
-          verbose: true

.github/workflows/pr-codespell.yml

@@ -14,7 +14,7 @@ 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
+        ignore_words_list: iam,aks,ist,bridget,ue
         check_filenames: true
         check_hidden: true

.github/workflows/pr-containers.yml

@@ -1,37 +0,0 @@
-name: build Velero containers on Dockerfile change
-
-on:
-  pull_request:
-    branches:
-      - 'main'
-      - 'release-**'
-    paths:
-      - 'Dockerfile'
-
-jobs:
-  build:
-    name: Build
-    runs-on: ubuntu-latest
-    steps:
-    - uses: actions/checkout@v3
-      name: Checkout
-
-    - name: Set up QEMU
-      id: qemu
-      uses: docker/setup-qemu-action@v1
-      with:
-        platforms: all
-
-    - name: Set up Docker Buildx
-      id: buildx
-      uses: docker/setup-buildx-action@v1
-      with:
-        version: latest
-
-    # Although this action also calls docker-push.sh, it is not triggered
-    # by push, so BRANCH and TAG are empty by default. docker-push.sh will
-    # only build Velero image without pushing.
-    - name: Make Velero container without pushing to registry.
-      if: github.repository == 'vmware-tanzu/velero'
-      run: |
-        ./hack/docker-push.sh

.github/workflows/push-builder.yml

@@ -2,9 +2,7 @@ name: build-image
 
 on:
   push:
-    branches:
-      - 'main'
-      - 'release-**'
+    branches: [ main ]
     paths:
     - 'hack/build-image/Dockerfile'
 
@@ -14,16 +12,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
 
-    - uses: actions/checkout@v2
-      with:
-        # The default value is "1" which fetches only a single commit. If we merge PR without squash or rebase,
-        # there are at least two commits: the first one is the merge commit and the second one is the real commit
-        # contains the changes.
-        # As we use the Dockerfile's commit ID as the tag of the build-image, fetching only 1 commit causes the merge
-        # commit ID to be the tag.
-        # While when running make commands locally, as the local git repository usually contains all commits, the Dockerfile's
-        # commit ID is the second one. This is mismatch with the images in Dockerhub
-        fetch-depth: 2
+    - uses: actions/checkout@master
 
     - name: Build
       run: make build-image

.github/workflows/push.yml

@@ -2,9 +2,7 @@ name: Main CI
 
 on:
   push:
-    branches:
-      - 'main'
-      - 'release-**'
+    branches: [ main ]
     tags:
       - '*'
 
@@ -18,22 +16,11 @@ jobs:
     - name: Set up Go
       uses: actions/setup-go@v2
       with:
-        go-version: 1.20.3
+        go-version: 1.16
       id: go
 
-    - uses: actions/checkout@v3
-
-    # Fix issue of setup-gcloud
-    - run: |
-        sudo apt-get install python2.7
-        export CLOUDSDK_PYTHON="/usr/bin/python2"
-
-    - uses: google-github-actions/setup-gcloud@v0
-      with:
-        version: '285.0.0'
-        service_account_key: ${{ secrets.GCS_SA_KEY }}
-        export_default_credentials: true
-    - run: gcloud info
+    - name: Check out code into the Go module directory
+      uses: actions/checkout@v2
 
     - name: Set up QEMU
       id: qemu
@@ -53,53 +40,9 @@ jobs:
     - name: Test
       run: make test
 
-    - name: Upload test coverage
-      uses: codecov/codecov-action@v2
-      with:
-        token: ${{ secrets.CODECOV_TOKEN }}
-        files: coverage.out
-        verbose: true
-
     # 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: |
-        # 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)
-
-        # Upload Velero image package to GCS
-        source hack/ci/build_util.sh
-        BIN=velero
-        RESTORE_HELPER_BIN=velero-restore-helper
-        GCS_BUCKET=velero-builds
-        VELERO_IMAGE=${BIN}-${VERSION}
-        VELERO_RESTORE_HELPER_IMAGE=${RESTORE_HELPER_BIN}-${VERSION}
-        VELERO_IMAGE_FILE=${VELERO_IMAGE}.tar.gz
-        VELERO_RESTORE_HELPER_IMAGE_FILE=${VELERO_RESTORE_HELPER_IMAGE}.tar.gz
-        VELERO_IMAGE_BACKUP_FILE=${VELERO_IMAGE}-'build.'${GITHUB_RUN_NUMBER}.tar.gz
-        VELERO_RESTORE_HELPER_IMAGE_BACKUP_FILE=${VELERO_RESTORE_HELPER_IMAGE}-'build.'${GITHUB_RUN_NUMBER}.tar.gz
-
-        cp ${VELERO_IMAGE_FILE} ${VELERO_IMAGE_BACKUP_FILE}
-        cp ${VELERO_RESTORE_HELPER_IMAGE_FILE} ${VELERO_RESTORE_HELPER_IMAGE_BACKUP_FILE}
-
-        uploader ${VELERO_IMAGE_FILE} ${GCS_BUCKET}
-        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
+        ./hack/docker-push.sh

.gitignore

@@ -46,7 +46,5 @@ _tiltbuild
 tilt-resources/tilt-settings.json
 tilt-resources/velero_v1_backupstoragelocation.yaml
 tilt-resources/deployment.yaml
-tilt-resources/node-agent.yaml
+tilt-resources/restic.yaml
 tilt-resources/cloud
-
-test/e2e/report.xml

.goreleaser.yml

@@ -14,7 +14,7 @@
 
 dist: _output
 builds:
-  - main: ./cmd/velero/velero.go
+  - main: ./cmd/velero/main.go
     env:
       - CGO_ENABLED=0
     goos:
@@ -27,9 +27,11 @@ builds:
       - arm64
       - ppc64le
     ignore:
-      # don't build arm for darwin and arm/arm64 for windows
+      # don't build arm/arm64 for darwin or windows
       - goos: darwin
         goarch: arm
+      - goos: darwin
+        goarch: arm64
       - goos: darwin
         goarch: ppc64le
       - goos: windows

ADOPTERS.md

@@ -14,7 +14,7 @@ If you're using Velero and want to add your organization to this list,
 <a href="https://sighup.io/" border="0" target="_blank"><img alt="sighup.io" src="site/static/img/adopters/sighup.svg" height="50"></a>&nbsp; &nbsp; &nbsp;
 <a href="https://mayadata.io/" border="0" target="_blank"><img alt="mayadata.io" src="site/static/img/adopters/mayadata.svg" height="50"></a>&nbsp; &nbsp; &nbsp;
 <a href="https://www.replicated.com/" border="0" target="_blank"><img alt="replicated.com" src="site/static/img/adopters/replicated-logo-red.svg" height="50"></a>
-<a href="https://cloudcasa.io/" border="0" target="_blank"><img alt="cloudcasa.io" src="site/static/img/adopters/cloudcasa.svg" height="50"></a>
+
 ## Success Stories
 
 Below is a list of adopters of Velero in **production environments** that have
@@ -40,9 +40,7 @@ We have integrated our [solution with Velero][11] to provide our customers with
 Kyma [integrates with Velero][41] to effortlessly back up and restore Kyma clusters with all its resources. Velero capabilities allow Kyma users to define and run manual and scheduled backups in order to successfully handle a disaster-recovery scenario.
 
 **[Red Hat][50]**  
-Red Hat has developed 2 operators for the OpenShift platform:
-- [Migration Toolkit for Containers][51] (Crane): This operator uses [Velero and Restic][52] to drive the migration of applications between OpenShift clusters.
-- [OADP (OpenShift API for Data Protection) Operator][53]: This operator sets up and installs Velero on the OpenShift platform, allowing users to backup and restore applications.
+Red Hat has developed the [Cluster Application Migration Tool][51] which uses [Velero and Restic][52] to drive the migration of applications between OpenShift clusters.
 
 **[Dell EMC][70]**  
 For Kubernetes environments, [PowerProtect Data Manager][71] leverages the Container Storage Interface (CSI) framework to take snapshots to back up the persistent data or the data that the application creates e.g. databases. [Dell EMC leverages Velero][72] to backup the namespace configuration files (also known as Namespace meta data) for enterprise grade data protection.
@@ -58,11 +56,8 @@ MayaData is a large user of Velero as well as a contributor. MayaData offers a D
 Okteto integrates Velero in [Okteto Cloud][94] and [Okteto Enterprise][95] to periodically backup and restore our clusters for disaster recovery. Velero is also a core software building block to provide namespace cloning capabilities, a feature that allows our users cloning staging environments into their personal development namespace for providing production-like development environments.
 
 **[Replicated][100]**<br>
-Replicated uses the Velero open source project to enable snapshots in [KOTS][101] to backup Kubernetes manifests & persistent volumes. In addition to the default functionality that Velero provides, [KOTS][101] provides a detailed interface in the [Admin Console][102] that can be used to manage the storage destination and schedule, and to perform and monitor the backup and restore process.<br>
-
-**[CloudCasa][103]**<br>
-[Catalogic Software][104] integrates Velero with [CloudCasa][103] - A Smart Home in the Cloud for Backups. CloudCasa is a simple, scalable, cloud-native solution providing data protection and disaster recovery as a service. This solution is built using Kubernetes for protecting Kubernetes clusters.<br>
-
+Replicated uses the Velero open source project to enable snapshots in [KOTS][101] to backup Kubernetes manifests & persistent volumes. In addition to the default functionality that Velero provides, [KOTS][101] provides a detailed interface in the [Admin Console][102] that can be used to manage the storage destination and schedule, and to perform and monitor the backup and restore process.
+​
 ## Adding your organization to the list of Velero Adopters
 
 If you are using Velero and would like to be included in the list of `Velero Adopters`, add an SVG version of your logo to the `site/static/img/adopters` directory in this repo and submit a [pull request][3] with your change. Name the image file something that reflects your company (e.g., if your company is called Acme, name the image acme.png). See this for an example [PR][4].
@@ -91,7 +86,6 @@ If you would like to add your logo to a future `Adopters of Velero` section on [
 [50]: https://redhat.com
 [51]: https://github.com/fusor/mig-operator
 [52]: https://github.com/fusor/mig-operator/blob/master/docs/usage/2.md
-[53]: https://github.com/openshift/oadp-operator
 
 [60]: https://banzaicloud.com
 [61]: https://banzaicloud.com/products/pipeline/
@@ -116,6 +110,3 @@ If you would like to add your logo to a future `Adopters of Velero` section on [
 [100]: https://www.replicated.com
 [101]: https://kots.io
 [102]: https://kots.io/kotsadm/snapshots/overview/
-
-[103]: https://cloudcasa.io/
-[104]: https://www.catalogicsoftware.com/

CHANGELOG.md

@@ -1,9 +1,7 @@
 ## Current release:
-  * [CHANGELOG-1.9.md][19]
+  * [CHANGELOG-1.7.md][17]
 
 ## Older releases:
-  * [CHANGELOG-1.8.md][18]
-  * [CHANGELOG-1.7.md][17]
   * [CHANGELOG-1.6.md][16]
   * [CHANGELOG-1.5.md][15]
   * [CHANGELOG-1.4.md][14]
@@ -22,8 +20,6 @@
   * [CHANGELOG-0.3.md][1]
 
 
-[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
 [16]: https://github.com/vmware-tanzu/velero/blob/main/changelogs/CHANGELOG-1.6.md
 [15]: https://github.com/vmware-tanzu/velero/blob/main/changelogs/CHANGELOG-1.5.md

Dockerfile

@@ -11,68 +11,50 @@
 # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 # See the License for the specific language governing permissions and
 # limitations under the License.
-
-# Velero binary build section
-FROM --platform=$BUILDPLATFORM golang:1.20.3-bullseye as velero-builder
+FROM --platform=$BUILDPLATFORM golang:1.16 as builder-env
 
 ARG GOPROXY
-ARG BIN
 ARG PKG
 ARG VERSION
-ARG REGISTRY
 ARG GIT_SHA
 ARG GIT_TREE_STATE
-ARG TARGETOS
-ARG TARGETARCH
-ARG TARGETVARIANT
+ARG REGISTRY
 
 ENV CGO_ENABLED=0 \
     GO111MODULE=on \
     GOPROXY=${GOPROXY} \
-    GOOS=${TARGETOS} \
-    GOARCH=${TARGETARCH} \
-    GOARM=${TARGETVARIANT} \
     LDFLAGS="-X ${PKG}/pkg/buildinfo.Version=${VERSION} -X ${PKG}/pkg/buildinfo.GitSHA=${GIT_SHA} -X ${PKG}/pkg/buildinfo.GitTreeState=${GIT_TREE_STATE} -X ${PKG}/pkg/buildinfo.ImageRegistry=${REGISTRY}"
 
 WORKDIR /go/src/github.com/vmware-tanzu/velero
 
 COPY . /go/src/github.com/vmware-tanzu/velero
 
+RUN apt-get update && apt-get install -y bzip2
+
+FROM --platform=$BUILDPLATFORM builder-env as builder
+
+ARG TARGETOS
+ARG TARGETARCH
+ARG TARGETVARIANT
+ARG PKG
+ARG BIN
+ARG RESTIC_VERSION
+
+ENV GOOS=${TARGETOS} \
+    GOARCH=${TARGETARCH} \
+    GOARM=${TARGETVARIANT}
+
 RUN mkdir -p /output/usr/bin && \
+    bash ./hack/download-restic.sh && \
     export GOARM=$( echo "${GOARM}" | cut -c2-) && \
     go build -o /output/${BIN} \
     -ldflags "${LDFLAGS}" ${PKG}/cmd/${BIN}
 
-# Restic binary build section
-FROM --platform=$BUILDPLATFORM golang:1.19.8-bullseye as restic-builder
-
-ARG BIN
-ARG TARGETOS
-ARG TARGETARCH
-ARG TARGETVARIANT
-ARG RESTIC_VERSION
-
-env CGO_ENABLED=0 \
-    GO111MODULE=on \
-    GOPROXY=${GOPROXY} \
-    GOOS=${TARGETOS} \
-    GOARCH=${TARGETARCH} \
-    GOARM=${TARGETVARIANT}
-
-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
-
-# Velero image packing section
-FROM gcr.io/distroless/base-nossl-debian11@sha256:9523ef8cf054e23a81e722d231c6f604ab43a03c5b174b5c8386c78c0b6473d0
+FROM gcr.io/distroless/base-debian10:nonroot
 
 LABEL maintainer="Nolan Brubaker <brubakern@vmware.com>"
 
-COPY --from=velero-builder /output /
-
-COPY --from=restic-builder /output /
+COPY --from=builder /output /
 
 USER nonroot:nonroot
 

MAINTAINERS.md

@@ -6,14 +6,12 @@
 
 | Maintainer | GitHub ID | Affiliation |
 | --------------- | --------- | ----------- |
-| Dave Smith-Uchida | [dsu-igeek](https://github.com/dsu-igeek) | [Kasten](https://github.com/kastenhq/) |
+| Bridget McErlean | [zubron](https://github.com/zubron) | [VMware](https://www.github.com/vmware/) |
+| Dave Smith-Uchida | [dsu-igeek](https://github.com/dsu-igeek) | [VMware](https://www.github.com/vmware/) |
+| JenTing Hsiao | [jenting](https://github.com/jenting) | [SUSE](https://github.com/SUSE/)
 | 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))
@@ -23,17 +21,14 @@
 * Nolan Brubaker ([nrb](https://github.com/nrb))
 * Ashish Amarnath ([ashish-amarnath](https://github.com/ashish-amarnath))
 * Carlisia Thompson ([carlisia](https://github.com/carlisia))
-* Bridget McErlean ([zubron](https://github.com/zubron))
-* JenTing Hsiao ([jenting](https://github.com/jenting))
 
 ## 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) |
+| Architect | Dave Smith-Uchida (dsu-igeek) |
+| Technical Lead | Daniel Jiang (reasonerjt) |
 | Kubernetes CSI Liaison |  |
-| Deployment |  |
-| Community Management | Orlin Vasilev [OrlinVasilev](https://github.com/OrlinVasilev) |
-| Product Management | Pradeep Kumar Chaturvedi [pradeepkchaturvedi](https://github.com/pradeepkchaturvedi) |
-
+| Deployment | JenTing Hsiao (jenting) |
+| Community Management | Jonas Rosland (jonasrosland) |
+| Product Management | Eleanor Millman (eleanor-millman) |

Makefile

@@ -82,9 +82,9 @@ see: https://velero.io/docs/main/build-from-source/#making-images-and-updating-v
 endef
 
 # The version of restic binary to be downloaded
-RESTIC_VERSION ?= 0.15.0
+RESTIC_VERSION ?= 0.12.1
 
-CLI_PLATFORMS ?= linux-amd64 linux-arm linux-arm64 darwin-amd64 darwin-arm64 windows-amd64 linux-ppc64le
+CLI_PLATFORMS ?= linux-amd64 linux-arm linux-arm64 darwin-amd64 windows-amd64 linux-ppc64le
 BUILDX_PLATFORMS ?= $(subst -,/,$(ARCH))
 BUILDX_OUTPUT_TYPE ?= docker
 
@@ -112,20 +112,19 @@ GOPROXY ?= https://proxy.golang.org
 # If you want to build all containers, see the 'all-containers' rule.
 all:
 	@$(MAKE) build
-	@$(MAKE) build BIN=velero-restore-helper
+	@$(MAKE) build BIN=velero-restic-restore-helper
 
 build-%:
 	@$(MAKE) --no-print-directory ARCH=$* build
-	@$(MAKE) --no-print-directory ARCH=$* build BIN=velero-restore-helper
+	@$(MAKE) --no-print-directory ARCH=$* build BIN=velero-restic-restore-helper
 
 all-build: $(addprefix build-, $(CLI_PLATFORMS))
 
-all-containers:
+all-containers: container-builder-env
 	@$(MAKE) --no-print-directory container
-	@$(MAKE) --no-print-directory container BIN=velero-restore-helper
+	@$(MAKE) --no-print-directory container BIN=velero-restic-restore-helper
 
 local: build-dirs
-# Add DEBUG=1 to enable debug locally
 	GOOS=$(GOOS) \
 	GOARCH=$(GOARCH) \
 	VERSION=$(VERSION) \
@@ -163,7 +162,6 @@ shell: build-dirs build-env
 	@# under $GOPATH).
 	@docker run \
 		-e GOFLAGS \
-		-e GOPROXY \
 		-i $(TTY) \
 		--rm \
 		-u $$(id -u):$$(id -g) \
@@ -178,6 +176,20 @@ shell: build-dirs build-env
 		$(BUILDER_IMAGE) \
 		/bin/sh $(CMD)
 
+container-builder-env:
+ifneq ($(BUILDX_ENABLED), true)
+	$(error $(BUILDX_ERROR))
+endif
+	@docker buildx build \
+	--target=builder-env \
+	--build-arg=GOPROXY=$(GOPROXY) \
+	--build-arg=PKG=$(PKG) \
+	--build-arg=VERSION=$(VERSION) \
+	--build-arg=GIT_SHA=$(GIT_SHA) \
+	--build-arg=GIT_TREE_STATE=$(GIT_TREE_STATE) \
+	--build-arg=REGISTRY=$(REGISTRY) \
+	-f $(VELERO_DOCKERFILE) .
+
 container:
 ifneq ($(BUILDX_ENABLED), true)
 	$(error $(BUILDX_ERROR))
@@ -186,7 +198,6 @@ endif
 	--output=type=$(BUILDX_OUTPUT_TYPE) \
 	--platform $(BUILDX_PLATFORMS) \
 	$(addprefix -t , $(IMAGE_TAGS)) \
-	--build-arg=GOPROXY=$(GOPROXY) \
 	--build-arg=PKG=$(PKG) \
 	--build-arg=BIN=$(BIN) \
 	--build-arg=VERSION=$(VERSION) \
@@ -196,12 +207,6 @@ endif
 	--build-arg=RESTIC_VERSION=$(RESTIC_VERSION) \
 	-f $(VELERO_DOCKERFILE) .
 	@echo "container: $(IMAGE):$(VERSION)"
-ifeq ($(BUILDX_OUTPUT_TYPE)_$(REGISTRY), registry_velero)
-	docker pull $(IMAGE):$(VERSION)
-	rm -f $(BIN)-$(VERSION).tar
-	docker save $(IMAGE):$(VERSION) -o $(BIN)-$(VERSION).tar
-	gzip -f $(BIN)-$(VERSION).tar
-endif
 
 SKIP_TESTS ?=
 test: build-dirs
@@ -333,9 +338,9 @@ changelog:
 #		PUBLISH=false \
 #		make release
 #
-# To run the release, which will publish a *DRAFT* GitHub release in github.com/vmware-tanzu/velero
+# To run the release, which will publish a *DRAFT* GitHub release in github.com/vmware-tanzu/velero 
 # (you still need to review/publish the GitHub release manually):
-#		GITHUB_TOKEN=your-github-token \
+#		GITHUB_TOKEN=your-github-token \ 
 #		RELEASE_NOTES_FILE=changelogs/CHANGELOG-1.2.md \
 #		PUBLISH=true \
 #		make release
@@ -354,7 +359,7 @@ serve-docs: build-image-hugo
 	-it -p 1313:1313 \
 	$(HUGO_IMAGE) \
 	hugo server --bind=0.0.0.0 --enableGitInfo=false
-# gen-docs generates a new versioned docs directory under site/content/docs.
+# 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:
 	@hack/release-tools/gen-docs.sh

PROJECT

@@ -0,0 +1,7 @@
+domain: io
+repo: github.com/vmware-tanzu/velero
+resources:
+- group: velero
+  kind: BackupStorageLocation
+  version: v1
+version: "2"

README.md

@@ -34,26 +34,6 @@ If you are ready to jump in and test, add code, or help with documentation, foll
 
 See [the list of releases][6] to find out about feature changes.
 
-### Velero compatibility matrix
-
-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 supports IPv4, IPv6, and dual stack environments. Support for this was tested against Velero v1.8.
-
-The Velero maintainers are continuously working to expand testing coverage, but are not able to test every combination of Velero and supported Kubernetes versions for each Velero release. The table above is meant to track the current testing coverage and the expected supported Kubernetes versions for each Velero version. If you have a question about test coverage before v1.9, please reach out in the [#velero-users](https://kubernetes.slack.com/archives/C6VCGP4MT) Slack channel.
-
-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.
-
 [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

ROADMAP.md

@@ -1 +1,42 @@
-# Please go to the [Velero Wiki](https://github.com/vmware-tanzu/velero/wiki/) to see our latest roadmap, archived roadmaps and roadmap guidance.
+## Velero Roadmap
+
+### About this document
+This document provides a link to the [Velero Project boards](https://github.com/vmware-tanzu/velero/projects) that serves as the up to date description of items that are in the release pipeline. The release boards have separate swim lanes based on prioritization. Most items are gathered from the community or include a feedback loop with the community. This should serve as a reference point for Velero users and contributors to understand where the project is heading, and help determine if a contribution could be conflicting with a longer term plan. 
+
+### How to help?
+Discussion on the roadmap can take place in threads under [Issues](https://github.com/vmware-tanzu/velero/issues) or in [community meetings](https://velero.io/community/). Please open and comment on an issue if you want to provide suggestions, use cases, and feedback to an item in the roadmap. Please review the roadmap to avoid potential duplicated effort.
+
+### How to add an item to the roadmap?
+One of the most important aspects in any open source community is the concept of proposals. Large changes to the codebase and / or new features should be preceded by a [proposal](https://github.com/vmware-tanzu/velero/blob/main/GOVERNANCE.md#proposal-process) in our repo.
+For smaller enhancements, you can open an issue to track that initiative or feature request.
+We work with and rely on community feedback to focus our efforts to improve Velero and maintain a healthy roadmap.
+
+### Current Roadmap
+The following table includes the current roadmap for Velero. If you have any questions or would like to contribute to Velero, please attend a [community meeting](https://velero.io/community/) to discuss with our team. If you don't know where to start, we are always looking for contributors that will help us reduce technical, automation, and documentation debt.
+Please take the timelines & dates as proposals and goals. Priorities and requirements change based on community feedback, roadblocks encountered, community contributions, etc. If you depend on a specific item, we encourage you to attend community meetings to get updated status information, or help us deliver that feature by contributing to Velero.
+
+`Last Updated: October 2021`
+
+#### 1.8.0 Roadmap (to be delivered January/February 2021)
+
+|Issue|Description|Timeline|Notes|
+|---|---|---|---|
+|[4108](https://github.com/vmware-tanzu/velero/issues/4108), [4109](https://github.com/vmware-tanzu/velero/issues/4109)|Solution for CSI - Azure and AWS|2022 H1|Currently, Velero plugins for AWS and Azure cannot back up persistent volumes that were provisioned using the CSI driver. This will fix that.|
+|[3229](https://github.com/vmware-tanzu/velero/issues/3229),[4112](https://github.com/vmware-tanzu/velero/issues/4112)|Moving data mover functionality from the Velero Plugin for vSphere into Velero proper|2022 H1|This work is a precursor to decoupling the Astrolabe snapshotting infrastructure.|
+|[3533](https://github.com/vmware-tanzu/velero/issues/3533)|Upload Progress Monitoring|2022 H1|Finishing up the work done in the 1.7 timeframe. The data mover work depends on this.|
+|[1975](https://github.com/vmware-tanzu/velero/issues/1975)|Test dual stack mode|2022 H1|We already tested IPv6, but we want to confirm that dual stack mode works as well.|
+|[2082](https://github.com/vmware-tanzu/velero/issues/2082)|Delete Backup CRs on removing target location. |2022 H1||
+|[3516](https://github.com/vmware-tanzu/velero/issues/3516)|Restore issue with MutatingWebhookConfiguration v1beta1 API version|2022 H1||
+|[2308](https://github.com/vmware-tanzu/velero/issues/2308)|Restoring nodePort service that has nodePort preservation always fails if service already exists in the namespace|2022 H1||
+|[4115](https://github.com/vmware-tanzu/velero/issues/4115)|Support for multiple set of credentials for VolumeSnapshotLocations|2022 H1||
+|[1980](https://github.com/vmware-tanzu/velero/issues/1980)|Velero triggers backup immediately for scheduled backups|2022 H1||
+|[4067](https://github.com/vmware-tanzu/velero/issues/4067)|Pre and post backup and restore hooks|2022 H1||
+|[3742](https://github.com/vmware-tanzu/velero/issues/3742)|Carvel packaging for Velero for vSphere|2022 H1|AWS and Azure have been completed already.|
+|[3285](https://github.com/vmware-tanzu/velero/issues/3285)|Design doc for Velero plugin versioning|2022 H1||
+|[4231](https://github.com/vmware-tanzu/velero/issues/4231)|Technical health (prioritizing giving developers confidence and saving developers time)|2022 H1|More automated tests (especially the pre-release manual tests) and more automation of the running of tests.|
+|[4110](https://github.com/vmware-tanzu/velero/issues/4110)|Solution for CSI - GCP|2022 H1|Currently, the Velero plugin for GCP cannot back up persistent volumes that were provisioned using the CSI driver. This will fix that.|
+|[3742](https://github.com/vmware-tanzu/velero/issues/3742)|Carvel packaging for Velero for restic|2022 H1|AWS and Azure have been completed already.|
+|[3454](https://github.com/vmware-tanzu/velero/issues/3454),[4134](https://github.com/vmware-tanzu/velero/issues/4134),[4135](https://github.com/vmware-tanzu/velero/issues/4135)|Kubebuilder tech debt|2022 H1||
+|[4111](https://github.com/vmware-tanzu/velero/issues/4111)|Ignore items returned by ItemSnapshotter.AlsoHandles during backup|2022 H1|This will enable backup of complex objects, because we can then tell Velero to ignore things that were already backed up when Velero was previously called recursively.|
+
+Other work may make it into the 1.8 release, but this is the work that will be prioritized first.

Tiltfile

@@ -7,7 +7,7 @@ k8s_yaml([
     'config/crd/v1/bases/velero.io_downloadrequests.yaml',
     'config/crd/v1/bases/velero.io_podvolumebackups.yaml',
     'config/crd/v1/bases/velero.io_podvolumerestores.yaml',
-    'config/crd/v1/bases/velero.io_backuprepositories.yaml',
+    'config/crd/v1/bases/velero.io_resticrepositories.yaml',
     'config/crd/v1/bases/velero.io_restores.yaml',
     'config/crd/v1/bases/velero.io_schedules.yaml',
     'config/crd/v1/bases/velero.io_serverstatusrequests.yaml',
@@ -17,7 +17,7 @@ k8s_yaml([
 # default values
 settings = {
     "default_registry": "docker.io/velero",
-    "use_node_agent": False,
+    "enable_restic": False,
     "enable_debug": False,
     "debug_continue_on_start": True,  # Continue the velero process by default when in debug mode
     "create_backup_locations": False,
@@ -34,9 +34,9 @@ k8s_yaml(kustomize('tilt-resources'))
 k8s_yaml('tilt-resources/deployment.yaml')
 if settings.get("enable_debug"):
     k8s_resource('velero', port_forwards = '2345')
-    # TODO: Need to figure out how to apply port forwards for all node-agent pods
-if settings.get("use_node_agent"):
-    k8s_yaml('tilt-resources/node-agent.yaml')
+    # TODO: Need to figure out how to apply port forwards for all restic pods
+if settings.get("enable_restic"):
+    k8s_yaml('tilt-resources/restic.yaml')
 if settings.get("create_backup_locations"):
     k8s_yaml('tilt-resources/velero_v1_backupstoragelocation.yaml')
 if settings.get("setup-minio"):
@@ -50,7 +50,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.16.6 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  && \
@@ -103,7 +103,7 @@ 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=' + local_goos + ' GOARCH=amd64 RESTIC_VERSION=0.12.0 OUTPUT_DIR=_tiltbuild/restic ./hack/download-restic.sh',
 )
 
 # Note: we need a distro with a bash shell to exec into the Velero container

changelogs/CHANGELOG-0.9.md

@@ -154,7 +154,7 @@
   * Skip completed jobs and pods when restoring (#463, @nrb)
   * Set namespace correctly when syncing backups from object storage (#472, @skriss)
   * When building on macOS, bind-mount volumes with delegated config (#478, @skriss)
-  * Add replica sets and daemonsets to cohabiting resources so they're not backed up twice (#482 #485, @skriss)
+  * Add replica sets and daemonsets to cohabitating resources so they're not backed up twice (#482 #485, @skriss)
   * Shut down the Ark server gracefully on SIGINT/SIGTERM (#483, @skriss)
   * Only back up resources that support GET and DELETE in addition to LIST and CREATE (#486, @nrb)
   * Show a better error message when trying to get an incomplete restore's logs (#496, @nrb)

changelogs/CHANGELOG-1.10.md

@@ -1,262 +0,0 @@
-## 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
-### 2022-11-23
-
-### Download
-https://github.com/vmware-tanzu/velero/releases/tag/v1.10.0
-
-### Container Image
-`velero/velero:v1.10.0`
-
-### Documentation
-https://velero.io/docs/v1.10/
-
-### Upgrading
-https://velero.io/docs/v1.10/upgrade-to-1.10/
-
-### Highlights
-
-#### Unified Repository and Kopia integration
-In this release, we introduced the Unified Repository architecture to build a data path where data movers and the backup repository are decoupled and a unified backup repository could serve various data movement activities.
-
-In this release, we also deeply integrate Velero with Kopia, specifically, Kopia's uploader modules are isolated as a generic file system uploader; Kopia's repository modules are encapsulated as the unified backup repository.
-
-For more information, refer to the [design document](https://github.com/vmware-tanzu/velero/blob/v1.10.0/design/unified-repo-and-kopia-integration/unified-repo-and-kopia-integration.md).
-
-#### File system backup refactor
-Velero's file system backup (a.k.s. pod volume backup or formerly restic backup) is refactored as the first user of the Unified Repository architecture. Specifically, we added a new path, the Kopia path, besides the existing Restic path. While Restic path is still available and set as default, you can opt in Kopia path by specifying the `uploader-type` parameter at installation time. Meanwhile, you are free to restore from existing backups under either path, Velero dynamically switches to the correct path to process the restore.
-
-Because of the new path, we renamed some modules and parameters, refer to the Break Changes section for more details.
-
-For more information, visit the [file system backup document](https://velero.io/docs/v1.10/file-system-backup/) and [v1.10 upgrade guide document](https://velero.io/docs/v1.10/upgrade-to-1.10/).
-
-Meanwhile, we've created a performance guide for both Restic path and Kopia path, which helps you to choose between the two paths and provides you the best practice to configure them under different scenarios. Please note that the results in the guide are based on our testing environments, you may get different results when testing in your own ones. For more information, visit the [performance guide document](https://velero.io/docs/v1.10/performance-guidance/).
-
-#### Plugin versioning V1 refactor
-In this release, Velero moves plugins BackupItemAction, RestoreItemAction and VolumeSnapshotterAction to version v1, this allows future plugin changes that do not support backward compatibility, so is a preparation for various complex tasks, for example, data movement tasks.
-For more information, refer to the [plugin versioning design document](https://github.com/vmware-tanzu/velero/blob/v1.10.0/design/plugin-versioning.md).
-
-#### Refactor the controllers using Kubebuilder v3
-In this release we continued our code modernization work, rewriting some controllers using Kubebuilder v3. This work is ongoing and we will continue to make progress in future releases.
-
-#### Add credentials to volume snapshot locations
-In this release, we enabled dedicate credentials options to volume snapshot locations so that you can specify credentials per volume snapshot location as same as backup storage location.
-
-For more information, please visit the [locations document](https://velero.io/docs/v1.10/locations/).
-
-#### CSI snapshot enhancements
-In this release we added several changes to enhance the robustness of CSI snapshot procedures, for example, some protection code for error handling, and a mechanism to skip exclusion checks so that CSI snapshot works with various backup resource filters.
-
-#### Backup schedule pause/unpause
-In this release, Velero supports to pause/unpause a backup schedule during or after its creation. Specifically:
-
-At creation time, you can specify `–paused` flag to `velero schedule create` command, if so, you will create a paused schedule that will not run until it is unpaused
-After creation, you can run `velero schedule pause` or `velero schedule unpause` command to pause/unpause a schedule
-
-#### Runtime and dependencies
-In order to fix CVEs, we changed Velero's runtime and dependencies as follows:
-
-Bump go runtime to v1.18.8
-Bump some core dependent libraries to newer versions
-Compile Restic (v0.13.1) with go 1.18.8 instead of packaging the official binary
-
-
-#### Breaking changes
-Due to file system backup refactor, below modules and parameters name have been changed in this release:
-
-`restic` daemonset is renamed to `node-agent`
-`resticRepository` CR is renamed to `backupRepository`
-`velero restic repo` command is renamed to `velero repo`
-`velero-restic-credentials` secret is renamed to `velero-repo-credentials`
-`default-volumes-to-restic` parameter is renamed to `default-volumes-to-fs-backup`
-`restic-timeout` parameter is renamed to `fs-backup-timeout`
-`default-restic-prune-frequency` parameter is renamed to `default-repo-maintain-frequency`
-
-#### Upgrade
-Due to the major changes of file system backup, the old upgrade steps are not suitable any more. For the new upgrade steps, visit [v1.10 upgrade guide document](https://velero.io/docs/v1.10/upgrade-to-1.10/).
-
-#### Limitations/Known issues
-In this release, Kopia backup repository (so the Kopia path of file system backup) doesn't support self signed certificate for S3 compatible storage. To track this problem, refer to this [Velero issue](https://github.com/vmware-tanzu/velero/issues/5123) or [Kopia issue](https://github.com/kopia/kopia/issues/1443). 
-
-Due to the code change in Velero, there will be some code change required in vSphere plugin, without which the functionality may be impacted.  Therefore, if you are using vSphere plugin in your workflow, please hold the upgrade until the issue [#485](https://github.com/vmware-tanzu/velero-plugin-for-vsphere/issues/485) is fixed in vSphere plugin.
-
-### All changes
-  
-  * Restore ClusterBootstrap before Cluster otherwise a new default ClusterBootstrap object is create for the cluster  (#5616, @ywk253100)
-  * Add compile restic binary for CVE fix  (#5574, @qiuming-best)
-  * Fix controller problematic log output  (#5572, @qiuming-best)
-  * Enhance the restore priorities list to support specifying the low prioritized resources that need to be restored in the last (#5535, @ywk253100)
-  * fix restic backup progress error (#5534, @qiuming-best)
-  * fix restic backup failure with self-signed certification backend storage (#5526, @qiuming-best)
-  * Add credential store in backup deletion controller to support VSL credential. (#5521, @blackpiglet)
-  * Fix issue 5505: the pod volume backups/restores except the first one fail under the kopia path if "AZURE_CLOUD_NAME" is specified (#5512, @Lyndon-Li)
-  * After Pod Volume Backup/Restore refactor, remove all the unreasonable appearance of "restic" word from documents (#5499, @Lyndon-Li)
-  * Refactor Pod Volume Backup/Restore doc to match the new behavior (#5484, @Lyndon-Li)
-  * Remove redundancy code block left by #5388. (#5483, @blackpiglet)
-  * Issue fix 5477: create the common way to support S3 compatible object storages that work for both Restic and Kopia; Keep the resticRepoPrefix parameter for compatibility (#5478, @Lyndon-Li)
-  * Update the k8s.io dependencies to 0.24.0.
-This also required an update to github.com/bombsimon/logrusr/v3.
-Removed the `WithClusterName` method
-as it is a "legacy field that was
-always cleared by the system and never used" as per upstream k8s
-https://github.com/kubernetes/apimachinery/blob/release-1.24/pkg/apis/meta/v1/types.go#L257-L259 (#5471, @kcboyle)
-  * Add v1.10 velero upgrade doc (#5468, @qiuming-best)
-  * Upgrade velero docker image to use go 1.18 and upgrade golangci-lint to 1.45.0 (#5459, @Lyndon-Li)
-  * Add VolumeSnapshot client back. (#5449, @blackpiglet)
-  * Change subcommand `velero restic repo` to `velero repo` (#5446, @allenxu404)
-  * Remove irrational "Restic" names in Velero code after the PVBR refactor (#5444, @Lyndon-Li)
-  * moved RIA execute input/output structs back to velero package (#5441, @sseago)
-  * Rename Velero pod volume restore init helper from "velero-restic-restore-helper" to "velero-restore-helper" (#5432, @Lyndon-Li)
-  * Skip the exclusion check for additional resources returned by BIA (#5429, @reasonerjt)
-  * Change B/R describe CLI to support Kopia (#5412, @allenxu404)
-  * Add nil check before execution of csi snapshot delete (#5401, @shubham-pampattiwar)
-  * update velero using klog to version v2.9.0 (#5396, @blackpiglet)
-  * Fix Test_prepareBackupRequest_BackupStorageLocation UT failure. (#5394, @blackpiglet)
-  * Rename Velero daemonset from "restic" to "node-agent" (#5390, @Lyndon-Li)
-  * Add some corner cases checking for CSI snapshot in backup controller. (#5388, @blackpiglet)
-  * Fix issue 5386: Velero providers a full URL as the S3Url while the underlying minio client only accept the host part of the URL as the endpoint and the schema should be specified separately. (#5387, @Lyndon-Li)
-  * Fix restore error with flag namespace-mappings (#5377, @qiuming-best)
-  * Pod Volume Backup/Restore Refactor: Rename parameters in CRDs and commands to remove "Restic" word (#5370, @Lyndon-Li)
-  * Added backupController's UT to test the prepareBackupRequest() method BackupStorageLocation processing logic (#5362, @niulechuan)
-  * Fix a repoEnsurer problem introduced by the refactor - The repoEnsurer didn't check "" state of BackupRepository, as a result, the function GetBackupRepository always returns without an error even though the ensreReady is specified. (#5359, @Lyndon-Li)
-  * Add E2E test for schedule backup (#5355, @danfengliu)
-  * Add useOwnerReferencesInBackup field doc for schedule. (#5353, @cleverhu)
-  * Clarify the help message for the default value of parameter --snapshot-volumes, when it's not set. (#5350, @blackpiglet)
-  * Fix restore cmd extraflag overwrite bug (#5347, @qiuming-best)
-  * Resolve gopkg.in/yaml.v3 vulnerabilities by upgrading gopkg.in/yaml.v3 to v3.0.1 (#5344, @kaovilai)
-  * Increase ensure restic repository timeout to 5m (#5335, @shubham-pampattiwar)
-  * Add opt-in and opt-out PersistentVolume backup to E2E tests (#5331, @danfengliu)
-  * Cancel downloadRequest when timeout without downloadURL (#5329, @kaovilai)
-  * Fix PVB finds wrong parent snapshot (#5322, @qiuming-best)
-  * Fix issue 4874 and 4752: check the daemonset pod is running in the node where the workload pod resides before running the PVB for the pod (#5319, @Lyndon-Li)
-  * plugin versioning v1 refactor for VolumeSnapshotter (#5318, @sseago)
-  * Change the status of restore to completed from partially failed when restore empty backup (#5314, @allenxu404)
-  * RestoreItemAction v1 refactoring for plugin api versioning (#5312, @sseago)
-  * Refactor the repoEnsurer code to use controller runtime client and wrap some common BackupRepository operations to share with other modules (#5308, @Lyndon-Li)
-  * Remove snapshot related lister, informer and client from backup controller. (#5299, @jxun)
-  * Remove github.com/apex/log logger. (#5297, @blackpiglet)
-  * change CSISnapshotTimeout from pointer to normal variables. (#5294, @cleverhu)
-  * Optimize code for restore exists resources. (#5293, @cleverhu)
-  * Add more detailed comments for labels columns. (#5291, @cleverhu)
-  * Add backup status checking in schedule controller. (#5283, @blackpiglet)
-  * Add changes for problems/enhancements found during smoking test for Kopia pod volume backup/restore (#5282, @Lyndon-Li)
-  * Support pause/unpause schedules (#5279, @ywk253100)
-  *  plugin/clientmgmt refactoring for BackupItemAction v1 (#5271, @sseago)
-  * Don't move velero v1 plugins to new proto dir (#5263, @sseago)
-  * Fill gaps for Kopia path of PVBR: integrate Repo Manager with Unified Repo; pass UploaderType to PVBR backupper and restorer; pass RepositoryType to BackupRepository controller and Repo Ensurer (#5259, @Lyndon-Li)
-  * Add csiSnapshotTimeout for describe backup (#5252, @cleverhu)
-  * equip gc controller with configurable frequency (#5248, @allenxu404)
-  * Fix nil pointer panic when restoring StatefulSets (#5247, @divolgin)
-  * Controller refactor code modifications. (#5241, @jxun)
-  * Fix edge cases for already exists resources (#5239, @shubham-pampattiwar)
-  * Check for empty ns list before checking nslist[0] (#5236, @sseago)
-  * Remove reference to non-existent doc (#5234, @reasonerjt)
-  * Add changes for Kopia Integration: Kopia Lib - method implementation. Add changes to write Kopia Repository logs to Velero log (#5233, @Lyndon-Li)
-  * Add changes for Kopia Integration: Kopia Lib - initialize Kopia repo (#5231, @Lyndon-Li)
-  * Uploader Implementation: Kopia backup and restore (#5221, @qiuming-best)
-  * Migrate backup sync controller from code-generator to kubebuilder. (#5218, @jxun)
-  * check vsc null pointer (#5217, @lilongfeng0902)
-  * Refactor GCController with kubebuilder (#5215, @allenxu404)
-  * Uploader Implementation: Restic backup and restore (#5214, @qiuming-best)
-  * Add parameter "uploader-type" to velero server (#5212, @reasonerjt)
-  * Add annotation "pv.kubernetes.io/migrated-to" for CSI checking. (#5181, @jxun)
-  * Add changes for Kopia Integration: Unified Repository Provider - method implementation (#5179, @Lyndon-Li)
-  * Treat namespaces with exclude label as excludedNamespaces
-Related issue: #2413 (#5178, @allenxu404)
-  * Reduce CRD size. (#5174, @jxun)
-  * Fix restic backups to multiple backup storage locations bug (#5172, @qiuming-best)
-  * Add changes for Kopia Integration: Unified Repository Provider - Repo Password (#5167, @Lyndon-Li)
-  * Skip registering "crd-remap-version" plugin when feature flag "EnableAPIGroupVersions" is set (#5165, @reasonerjt)
-  * Kopia uploader integration on shim progress uploader module (#5163, @qiuming-best)
-  * Add labeled and unlabeled events for PR changelog check action. (#5157, @jxun)
-  * VolumeSnapshotLocation refactor with kubebuilder. (#5148, @jxun)
-  * Delay CA file deletion in PVB controller. (#5145, @jxun)
-  * This commit splits the pkg/restic package into several packages to support Kopia integration works (#5143, @ywk253100)
-  * Kopia Integration: Add the Unified Repository Interface definition. Kopia Integration: Add the changes for Unified Repository storage config. Related Issues; #5076, #5080 (#5142, @Lyndon-Li)
-  * Update the CRD for kopia integration (#5135, @reasonerjt)
-  * Let "make shell xxx" respect GOPROXY (#5128, @reasonerjt)
-  * Modify BackupStoreGetter to avoid BSL spec changes (#5122, @sseago)
-  * Dump stack trace when the plugin server handles panic (#5110, @reasonerjt)
-  * Make CSI snapshot creation timeout configurable. (#5104, @jxun)
-  *  Fix bsl validation bug: the BSL is validated continually and doesn't respect the validation period configured (#5101, @ywk253100)
-  * Exclude "csinodes.storage.k8s.io" and "volumeattachments.storage.k8s.io" from restore by default. (#5064, @jxun)
-  * Move 'velero.io/exclude-from-backup' label string to const (#5053, @niulechuan)
-  * Modify Github actions. (#5052, @jxun)
-  * Fix typo in doc, in https://velero.io/docs/main/restore-reference/ "Restore order" section, "Mamespace" should be "Namespace". (#5051, @niulechuan)
-  * Delete opened issues triage action. (#5041, @jxun)
-  * When spec.RestoreStatus is empty, don't restore status (#5008, @sseago)
-  * Added DownloadTargetKindCSIBackupVolumeSnapshots for retrieving the signed URL to download only the `<backup name>`-csi-volumesnapshots.json.gz  and DownloadTargetKindCSIBackupVolumeSnapshotContents to download only `<backup name>`-csi-volumesnapshotcontents.json.gz in the DownloadRequest CR structure. These files are already present in the backup layout.  (#4980, @anshulahuja98)
-  * Refactor BackupItemAction proto and related code to backupitemaction/v1 package.  This is part of implementation of the plugin version design https://github.com/vmware-tanzu/velero/blob/main/design/plugin-versioning.md (#4943, @phuongatemc)
-  * Unified Repository Design (#4926, @Lyndon-Li)
-  * Add credentials to volume snapshot locations (#4864, @sseago)

changelogs/CHANGELOG-1.8.md

@@ -1,110 +0,0 @@
-## v1.8.0
-### 2022-01-14
-
-### Download
-https://github.com/vmware-tanzu/velero/releases/tag/v1.8.0
-
-### Container Image
-`velero/velero:v1.8.0`
-
-### Documentation
-https://velero.io/docs/v1.8
-
-### Upgrading
-https://velero.io/docs/v1.8/upgrade-to-1.8/
-
-### Highlights
-
-#### Velero plugins now support handling volumes created by the CSI drivers of cloud providers
-Versions 1.4 of the Velero plugins for AWS, Azure and GCP now support snapshotting and restoring the persistent volumes provisioned by CSI driver via the APIs of the cloud providers. With this enhancement, users can backup and restore the persistent volumes on these cloud providers without using the Velero CSI plugin. The CSI plugin will remain beta and the feature flag `EnableCSI` will be disabled by default.
-
-For the version of the plugins and the CSI drivers they support respectively please see the table:
-
-| Plugin | Version | CSI Driver |
-| --- | ----------- | ---------- |
-| velero-plugin-for-aws | v1.4.0 | ebs.csi.aws.com |
-| velero-plugin-for-microsoft-azure | v1.4.0 | disk.csi.azure.com |
-| velero-plugin-for-gcp | v1.4.0 | pd.csi.storage.gke.io |
-
-#### IPv6 dual stack support
-We've verified the functionality of Velero on IPv6 dual stack by successfully running the E2E test on IPv6 dual stack environment.
-#### Refactor the controllers using Kubebuilder v3
-In this release we continued our code modernization work, rewriting some controllers using Kubebuilder v3. This work is ongoing and we will continue to make progress in future releases.
-#### Enhancements to E2E test cases
-More test cases have been added to the E2E test suite to improve the release health.
-#### Respect the cron setting of scheduled backup
-The creation time is now taken into account to calculate the next run for scheduled backup.
-
-#### Deleting BSLs also cleans up related resources
-
-When a Backup Storage Location (BSL) is deleted, backup and Restic repository resources will also be deleted.
-
-#### Breaking changes
-
-Starting in v1.8, Velero will only support Kubernetes v1 CRD meaning that Velero v1.8+ will only run on Kubernetes v1.16+. Before upgrading, make sure you are running a supported Kubernetes version. For more information, see our [compatibility matrix](https://github.com/vmware-tanzu/velero#velero-compatibility-matrix).
-
-#### Upload Progress Monitoring and Item Snapshotter
-Item Snapshotter plugin API was merged.  This will support both Upload Progress
-monitoring and the planned Data Mover.  Upload Progress monitoring PRs are
-in progress for 1.9.
-
-### All changes
-
-* E2E test on ssr object with controller namespace mix-ups (#4521, @mqiu)
-* Check whether the volume is provisioned by CSI driver or not by the annotation as well (#4513, @ywk253100)
-* Initialize the labels field of `velero backup-location create` option to avoid #4484 (#4491, @ywk253100)
-* Fix e2e 2500 namespaces scale test timeout problem (#4480, @mqiu)
-* Add backup deletion e2e test  (#4401, @danfengliu)
-* Return the error when getting backup store in backup deletion controller (#4465, @reasonerjt)
-* Ignore the provided port is already allocated error when restoring the LoadBalancer service (#4462, @ywk253100)
-* Revert #4423 migrate backup sync controller to kubebuilder. (#4457, @jxun)
-* 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)
-* 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
-  when item snapshots are taken and contains an array of volume.Itemsnapshots
-  containing the information about the snapshots.  This will not be used unless
-  upload progress monitoring and item snapshots are enabled and an ItemSnapshot
-  plugin is used to take snapshots.
-
-Also added DownloadTargetKindBackupItemSnapshots for retrieving the signed URL to download only the `<backup name>`-itemsnapshots.json.gz part of a backup for use by
-`velero backup describe`. (#4429, @dsmithuchida)
-* Migrate backup sync controller from code-generator to kubebuilder. (#4423, @jxun)
-* Added UploadProgressFeature flag to enable Upload Progress Monitoring and Item
-  Snapshotters. (#4416, @dsmithuchida)
-* Added BackupWithResolvers and RestoreWithResolvers calls.  Will eventually replace Backup and Restore methods.
-  Adds ItemSnapshotters to Backup and Restore workflows. (#4410, @dsu)
-* Build for darwin-arm64 (#4409, @epk)
-* Add resource filtering test cases (#4404, @mqiu)
-* Fix the issue that the backup cannot be deleted after the application uninstalled (#4398, @ywk253100)
-* Add restoreactionitem plugin to handle admission webhook configurations (#4397, @reasonerjt)
-* Keep the annotation "pv.kubernetes.io/provisioned-by" when restoring PVs (#4391, @ywk253100)
-* Adjust structure of e2e test codes (#4386, @mqiu)
-* feat: migrate velero controller from kubebuilder v2 to v3
-  From Velero v1.8, apiextesions.k8s.io/v1beta1 is no longer supported,
-  which means only CRD of apiextensions.k8s.io/v1 is supported,
-  and the supported Kubernetes version is updated to v1.16 and later. (#4382, @jxun)
-* Delete backups and Restic repos associated with deleted BSL(s) (#4377, @codegold79)
-* Add the key for GKE zone for AZ collection (#4376, @reasonerjt)
-* Fix statefulsets volumeClaimTemplates storageClassName when use Changing PV/PVC Storage Classes (#4375, @Box-Cube)
-* Fix snapshot e2e test issue of jsonpath (#4372, @danfengliu)
-* Modify the timestamp in the name of a backup generated from schedule to use UTC. (#4353, @jxun)
-* Read Availability zone from nodeAffinity requirements  (#4350, @reasonerjt)
-* Use factory.Namespace() to replace hardcoded velero namespace (#4346, @half-life666)
-* Return the error if velero failed to detect S3 region for restic repo (#4343, @reasonerjt)
-* Add init log option for velero controller-runtime manager. (#4341, @jxun)
-* Ignore the `provided port is already allocated` error when restoring the `NodePort` service (#4336, @ywk253100)
-* Fixed an issue with the `backup-location create` command where the BSL Credential field would be set to an invalid empty SecretKeySelector when no credential details were provided. (#4322, @zubron)
-* fix buggy pager func (#4306, @alaypatel07)
-* Don't create a backup immediately after creating a schedule (#4281, @ywk253100)
-* Fix CVE-2020-29652 and CVE-2020-26160 (#4274, @ywk253100)
-* Refine tag-release.sh to align with change in release process (#4185, @reasonerjt)
-* Fix plugins incompatible issue in upgrade test (#4141, @danfengliu)
-* Verify group before treating resource as cohabiting (#4126, @sseago)
-* Added ItemSnapshotter plugin definition and plugin framework - addresses #3533.
-  Part of the Upload Progress enhancement (#3533) (#4077, @dsmithuchida)
-* Add upgrade test in E2E test (#4058, @danfengliu)
-* Handle namespace mapping for PVs without snapshots on restore (#3708, @sseago)

changelogs/CHANGELOG-1.9.md

@@ -1,104 +0,0 @@
-## v1.9.0
-### 2022-06-13
-
-### Download
-https://github.com/vmware-tanzu/velero/releases/tag/v1.9.0
-
-### Container Image
-`velero/velero:v1.9.0`
-
-### Documentation
-https://velero.io/docs/v1.9/
-
-### Upgrading
-https://velero.io/docs/v1.9/upgrade-to-1.9/
-
-### Highlights
-
-#### Improvement to the CSI plugin
-- Bump up to the CSI volume snapshot v1 API
-- No VolumeSnapshot will be left in the source namespace of the workload
-- Report metrics for CSI snapshots
-
-More improvements please refer to [CSI plugin improvement](https://github.com/vmware-tanzu/velero/issues?q=is%3Aissue+label%3A%22CSI+plugin+-+GA+-+phase1%22+is%3Aclosed)
-
-With these improvements we'll provide official support for CSI snapshots on AKS/EKS clusters. (with CSI plugin v0.3.0)
-
-#### Refactor the controllers using Kubebuilder v3
-In this release we continued our code modernization work, rewriting some controllers using Kubebuilder v3. This work is ongoing and we will continue to make progress in future releases.
-
-#### Optionally restore status on selected resources
-Options are added to the CLI and Restore spec to control the group of resources whose status will be restored.
-
-#### ExistingResourcePolicy in the restore API
-Users can choose to overwrite or patch the existing resources during restore by setting this policy.
-
-#### Upgrade integrated Restic version and add skip TLS validation in Restic command
-Upgrade integrated Restic version, which will resolve some of the CVEs, and support skip TLS validation in Restic backup/restore.
-
-#### Breaking changes
-With bumping up the API to v1 in CSI plugin, the v0.3.0 CSI plugin will only work for Kubernetes v1.20+
-
-### All changes
-
-  * restic: add full support for setting SecurityContext for restore init container from configMap. (#4084, @MatthieuFin)
-  * Add metrics backup_items_total and backup_items_errors (#4296, @tobiasgiese)
-  * Convert PodVolumebackup controller to the Kubebuilder framework (#4436, @fgold)
-  * Skip not mounted volumes when backing up (#4497, @dkeven)
-  * Update doc for v1.8 (#4517, @reasonerjt)
-  * Fix bug to make the restic prune frequency configurable (#4518, @ywk253100)
-  * Add E2E test of backups sync from BSL (#4545, @mqiu)
-  * Fix: OrderedResources in Schedules (#4550, @dbrekau)
-  * Skip volumes of non-running pods when backing up (#4584, @bynare)
-  * E2E SSR test add retry mechanism and logs  (#4591, @mqiu)
-  * Add pushing image to GCR in github workflow to facilitate some environments that have rate limitation to docker hub, e.g. vSphere. (#4623, @jxun)
-  * Add existingResourcePolicy to Restore API (#4628, @shubham-pampattiwar)
-  * Fix E2E backup namespaces test (#4634, @qiuming-best)
-  * Update image used by E2E test to gcr.io (#4639, @jxun)
-  * Add multiple label selector support to Velero Backup and Restore APIs (#4650, @shubham-pampattiwar)
-  * Convert Pod Volume Restore resource/controller to the Kubebuilder framework (#4655, @ywk253100)
-  * Update --use-owner-references-in-backup description in velero command line. (#4660, @jxun)
-  * Avoid overwritten hook's exec.container parameter when running pod command executor. (#4661, @jxun)
-  * Support regional pv for GKE (#4680, @jxun)
-  * Bypass the remap CRD version plugin when v1beta1 CRD is not supported (#4686, @reasonerjt)
-  * Add GINKGO_SKIP to support skip specific case in e2e test. (#4692, @jxun)
-  * Add --pod-labels flag to velero install (#4694, @j4m3s-s)
-  * Enable coverage in test.sh and upload to codecov (#4704, @reasonerjt)
-  * Mark the BSL as "Unavailable" when gets any error and add a new field "Message" to the status to record the error message (#4719, @ywk253100)
-  * Support multiple skip option for E2E test (#4725, @jxun)
-  * Add PriorityClass to the AdditionalItems of Backup's PodAction and Restore's PodAction plugin to backup and restore PriorityClass if it is used by a Pod. (#4740, @phuongatemc)
-  * Insert all restore errors and warnings into restore log. (#4743, @sseago)
-  * Refactor schedule controller with kubebuilder (#4748, @ywk253100)
-  * Garbage collector now adds labels to backups that failed to delete for BSLNotFound, BSLCannotGet, BSLReadOnly reasons. (#4757, @kaovilai)
-  * Skip podvolumerestore creation when restore excludes pv/pvc (#4769, @half-life666)
-  * Add parameter for e2e test to support modify kibishii install path. (#4778, @jxun)
-  * Ensure the restore hook applied to new namespace based on the mapping (#4779, @reasonerjt)
-  * Add ability to restore status on selected resources (#4785, @RafaeLeal)
-  * Do not take snapshot for PV to avoid duplicated snapshotting, when CSI feature is enabled. (#4797, @jxun)
-  * Bump up to v1 API for CSI snapshot (#4800, @reasonerjt)
-  * fix: delete empty backups (#4817, @yuvalman)
-  * Add CSI VolumeSnapshot related metrics. (#4818, @jxun)
-  * Fix default-backup-ttl not work (#4831, @qiuming-best)
-  * Make the vsc created by backup sync controller deletable (#4832, @reasonerjt)
-  * Make in-progress backup/restore as failed when doing the reconcile to avoid hanging in in-progress status (#4833, @ywk253100)
-  * Use controller-gen to generate the deep copy methods for objects (#4838, @ywk253100)
-  * Update integrated Restic version and add insecureSkipTLSVerify for Restic CLI. (#4839, @jxun)
-  * Modify CSI VolumeSnapshot metric related code. (#4854, @jxun)
-  * Refactor backup deletion controller based on kubebuilder (#4855, @reasonerjt)
-  * Remove VolumeSnapshots created during backup when CSI feature is enabled. (#4858, @jxun)
-  * Convert Restic Repository resource/controller to the Kubebuilder framework (#4859, @qiuming-best)
-  * Add ClusterClasses to the restore priority list (#4866, @reasonerjt)
-  * Cleanup the .velero folder after restic done (#4872, @big-appled)
-  * Delete orphan CSI snapshots in backup sync controller (#4887, @reasonerjt)
-  * Make waiting VolumeSnapshot to ready process parallel. (#4889, @jxun)
-  * continue rather than return for non-matching restore action label (#4890, @sseago)
-  * Make in-progress PVB/PVR as failed when restic controller restarts to avoid hanging backup/restore (#4893, @ywk253100)
-  * Refactor BSL controller with periodical enqueue source (#4894, @jxun)
-  * Make garbage collection for expired backups configurable (#4897, @ywk253100)
-  * Bump up the version of distroless to base-debian11 (#4898, @ywk253100)
-  * Add schedule ordered resources E2E test (#4913, @qiuming-best)
-  * Make velero completion zsh command output can be used by `source` command. (#4914, @jxun)
-  * Enhance the map flag to support parsing input value contains entry delimiters (#4920, @ywk253100)
-  * Fix E2E test [Backups][Deletion][Restic] on GCP. (#4968, @jxun)
-  * Disable status as sub resource in CRDs (#4972, @ywk253100)
-  * Add more information for failing to get path or snapshot in restic backup and restore. (#4988, @jxun)

changelogs/unreleased/4058-danfengliu

@@ -0,0 +1 @@
+Add upgrade test in E2E test

changelogs/unreleased/4126-sseago

@@ -0,0 +1 @@
+Verify group before treating resource as cohabitating

changelogs/unreleased/4141-danfengliu

@@ -0,0 +1 @@
+Fix plugins incompatible issue in upgrade test

changelogs/unreleased/4185-reasonerjt

@@ -0,0 +1 @@
+Refine tag-release.sh to align with change in release process

changelogs/unreleased/4274-ywk253100

@@ -0,0 +1 @@
+Fix CVE-2020-29652 and CVE-2020-26160

changelogs/unreleased/4281-ywk253100

@@ -0,0 +1 @@
+Don't create a backup immediately after creating a schedule

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

@@ -38,12 +38,6 @@ func main() {
 		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
 			}
 		}
@@ -81,28 +75,3 @@ func done() bool {
 
 	return true
 }
-
-// remove .velero folder
-func removeFolder() error {
-	children, err := ioutil.ReadDir("/restores")
-	if err != nil {
-		return err
-	}
-
-	for _, child := range children {
-		if !child.IsDir() {
-			fmt.Printf("%s is not a directory, skipping.\n", child.Name())
-			continue
-		}
-
-		donePath := filepath.Join("/restores", child.Name(), ".velero")
-
-		err = os.RemoveAll(donePath)
-		if err != nil {
-			return err
-		}
-		fmt.Printf("Deleted %s", donePath)
-	}
-
-	return nil
-}

cmd/velero/main.go

@@ -20,7 +20,7 @@ import (
 	"os"
 	"path/filepath"
 
-	"k8s.io/klog/v2"
+	"k8s.io/klog"
 
 	"github.com/vmware-tanzu/velero/pkg/cmd"
 	"github.com/vmware-tanzu/velero/pkg/cmd/velero"

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

@@ -4,7 +4,7 @@ apiVersion: apiextensions.k8s.io/v1
 kind: CustomResourceDefinition
 metadata:
   annotations:
-    controller-gen.kubebuilder.io/version: v0.7.0
+    controller-gen.kubebuilder.io/version: v0.3.0
   creationTimestamp: null
   name: backups.velero.io
 spec:
@@ -37,22 +37,9 @@ spec:
           spec:
             description: BackupSpec defines the specification for a Velero backup.
             properties:
-              csiSnapshotTimeout:
-                description: CSISnapshotTimeout specifies the time used to wait for
-                  CSI VolumeSnapshot status turns to ReadyToUse during creation, before
-                  returning error as timeout. The default value is 10 minute.
-                type: string
-              defaultVolumesToFsBackup:
-                description: DefaultVolumesToFsBackup specifies whether pod volume
-                  file system backup should be used for all volumes by default.
-                nullable: true
-                type: boolean
               defaultVolumesToRestic:
-                description: "DefaultVolumesToRestic specifies whether restic should
-                  be used to take a backup of all pod volumes by default. \n Deprecated:
-                  this field is no longer used and will be removed entirely in future.
-                  Use DefaultVolumesToFsBackup instead."
-                nullable: true
+                description: DefaultVolumesToRestic specifies whether restic should
+                  be used to take a backup of all pod volumes by default.
                 type: boolean
               excludedNamespaces:
                 description: ExcludedNamespaces contains a list of namespaces that
@@ -327,69 +314,13 @@ spec:
                       type: string
                     type: object
                 type: object
-              orLabelSelectors:
-                description: OrLabelSelectors is list of metav1.LabelSelector to filter
-                  with when adding individual objects to the backup. If multiple provided
-                  they will be joined by the OR operator. LabelSelector as well as
-                  OrLabelSelectors cannot co-exist in backup request, only one of
-                  them can be used.
-                items:
-                  description: A label selector is a label query over a set of resources.
-                    The result of matchLabels and matchExpressions are ANDed. An empty
-                    label selector matches all objects. A null label selector matches
-                    no objects.
-                  properties:
-                    matchExpressions:
-                      description: matchExpressions is a list of label selector requirements.
-                        The requirements are ANDed.
-                      items:
-                        description: A label selector requirement is a selector that
-                          contains values, a key, and an operator that relates the
-                          key and values.
-                        properties:
-                          key:
-                            description: key is the label key that the selector applies
-                              to.
-                            type: string
-                          operator:
-                            description: operator represents a key's relationship
-                              to a set of values. Valid operators are In, NotIn, Exists
-                              and DoesNotExist.
-                            type: string
-                          values:
-                            description: values is an array of string values. If the
-                              operator is In or NotIn, the values array must be non-empty.
-                              If the operator is Exists or DoesNotExist, the values
-                              array must be empty. This array is replaced during a
-                              strategic merge patch.
-                            items:
-                              type: string
-                            type: array
-                        required:
-                        - key
-                        - operator
-                        type: object
-                      type: array
-                    matchLabels:
-                      additionalProperties:
-                        type: string
-                      description: matchLabels is a map of {key,value} pairs. A single
-                        {key,value} in the matchLabels map is equivalent to an element
-                        of matchExpressions, whose key field is "key", the operator
-                        is "In", and the values array contains only "value". The requirements
-                        are ANDed.
-                      type: object
-                  type: object
-                nullable: true
-                type: array
               orderedResources:
                 additionalProperties:
                   type: string
                 description: OrderedResources specifies the backup order of resources
-                  of specific Kind. The map key is the resource name and value is
-                  a list of object names separated by commas. Each resource name has
-                  format "namespace/objectname".  For cluster resources, simply use
-                  "objectname".
+                  of specific Kind. The map key is the Kind name and value is a list
+                  of resource names separated by commas. Each resource name has format
+                  "namespace/resourcename".  For cluster resources, simply use "resourcename".
                 nullable: true
                 type: object
               snapshotVolumes:
@@ -423,14 +354,6 @@ spec:
                 format: date-time
                 nullable: true
                 type: string
-              csiVolumeSnapshotsAttempted:
-                description: CSIVolumeSnapshotsAttempted is the total number of attempted
-                  CSI VolumeSnapshots for this backup.
-                type: integer
-              csiVolumeSnapshotsCompleted:
-                description: CSIVolumeSnapshotsCompleted is the total number of successfully
-                  completed CSI VolumeSnapshots for this backup.
-                type: integer
               errors:
                 description: Errors is a count of all error messages that were generated
                   during execution of the backup.  The actual errors are in the backup's
@@ -441,10 +364,6 @@ spec:
                 format: date-time
                 nullable: true
                 type: string
-              failureReason:
-                description: FailureReason is an error that caused the entire backup
-                  to fail.
-                type: string
               formatVersion:
                 description: FormatVersion is the backup format version, including
                   major, minor, and patch version.

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

@@ -4,7 +4,7 @@ apiVersion: apiextensions.k8s.io/v1
 kind: CustomResourceDefinition
 metadata:
   annotations:
-    controller-gen.kubebuilder.io/version: v0.7.0
+    controller-gen.kubebuilder.io/version: v0.3.0
   creationTimestamp: null
   name: backupstoragelocations.velero.io
 spec:
@@ -158,10 +158,6 @@ spec:
                 format: date-time
                 nullable: true
                 type: string
-              message:
-                description: Message is a message about the backup storage location's
-                  status.
-                type: string
               phase:
                 description: Phase is the current state of the BackupStorageLocation.
                 enum:
@@ -172,7 +168,8 @@ spec:
         type: object
     served: true
     storage: true
-    subresources: {}
+    subresources:
+      status: {}
 status:
   acceptedNames:
     kind: ""

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

@@ -4,7 +4,7 @@ apiVersion: apiextensions.k8s.io/v1
 kind: CustomResourceDefinition
 metadata:
   annotations:
-    controller-gen.kubebuilder.io/version: v0.7.0
+    controller-gen.kubebuilder.io/version: v0.3.0
   creationTimestamp: null
   name: deletebackuprequests.velero.io
 spec:
@@ -16,16 +16,7 @@ spec:
     singular: deletebackuprequest
   scope: Namespaced
   versions:
-  - additionalPrinterColumns:
-    - description: The name of the backup to be deleted
-      jsonPath: .spec.backupName
-      name: BackupName
-      type: string
-    - description: The status of the deletion request
-      jsonPath: .status.phase
-      name: Status
-      type: string
-    name: v1
+  - name: v1
     schema:
       openAPIV3Schema:
         description: DeleteBackupRequest is a request to delete one or more backups.
@@ -72,7 +63,6 @@ spec:
         type: object
     served: true
     storage: true
-    subresources: {}
 status:
   acceptedNames:
     kind: ""

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

@@ -4,7 +4,7 @@ apiVersion: apiextensions.k8s.io/v1
 kind: CustomResourceDefinition
 metadata:
   annotations:
-    controller-gen.kubebuilder.io/version: v0.7.0
+    controller-gen.kubebuilder.io/version: v0.3.0
   creationTimestamp: null
   name: downloadrequests.velero.io
 spec:
@@ -46,12 +46,9 @@ spec:
                     - BackupLog
                     - BackupContents
                     - BackupVolumeSnapshots
-                    - BackupItemSnapshots
                     - BackupResourceList
                     - RestoreLog
                     - RestoreResults
-                    - CSIBackupVolumeSnapshots
-                    - CSIBackupVolumeSnapshotContents
                     type: string
                   name:
                     description: Name is the name of the kubernetes resource with
@@ -87,6 +84,8 @@ spec:
         type: object
     served: true
     storage: true
+    subresources:
+      status: {}
 status:
   acceptedNames:
     kind: ""

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

@@ -4,7 +4,7 @@ apiVersion: apiextensions.k8s.io/v1
 kind: CustomResourceDefinition
 metadata:
   annotations:
-    controller-gen.kubebuilder.io/version: v0.7.0
+    controller-gen.kubebuilder.io/version: v0.3.0
   creationTimestamp: null
   name: podvolumebackups.velero.io
 spec:
@@ -16,44 +16,7 @@ spec:
     singular: podvolumebackup
   scope: Namespaced
   versions:
-  - additionalPrinterColumns:
-    - description: Pod Volume Backup status such as New/InProgress
-      jsonPath: .status.phase
-      name: Status
-      type: string
-    - description: Time when this backup was started
-      jsonPath: .status.startTimestamp
-      name: Created
-      type: date
-    - description: Namespace of the pod containing the volume to be backed up
-      jsonPath: .spec.pod.namespace
-      name: Namespace
-      type: string
-    - description: Name of the pod containing the volume to be backed up
-      jsonPath: .spec.pod.name
-      name: Pod
-      type: string
-    - description: Name of the volume to be backed up
-      jsonPath: .spec.volume
-      name: Volume
-      type: string
-    - description: Backup repository identifier for this backup
-      jsonPath: .spec.repoIdentifier
-      name: Repository ID
-      type: string
-    - description: The type of the uploader to handle data transfer
-      jsonPath: .spec.uploaderType
-      name: Uploader Type
-      type: string
-    - description: Name of the Backup Storage Location where this backup should be
-        stored
-      jsonPath: .spec.backupStorageLocation
-      name: Storage Location
-      type: string
-    - jsonPath: .metadata.creationTimestamp
-      name: Age
-      type: date
-    name: v1
+  - name: v1
     schema:
       openAPIV3Schema:
         properties:
@@ -74,7 +37,7 @@ spec:
             properties:
               backupStorageLocation:
                 description: BackupStorageLocation is the name of the backup storage
-                  location where the backup repository is stored.
+                  location where the restic repository is stored.
                 type: string
               node:
                 description: Node is the name of the node that the Pod is running
@@ -118,7 +81,7 @@ spec:
                     type: string
                 type: object
               repoIdentifier:
-                description: RepoIdentifier is the backup repository identifier.
+                description: RepoIdentifier is the restic repository identifier.
                 type: string
               tags:
                 additionalProperties:
@@ -126,14 +89,6 @@ spec:
                 description: Tags are a map of key-value pairs that should be applied
                   to the volume backup as tags.
                 type: object
-              uploaderType:
-                description: UploaderType is the type of the uploader to handle the
-                  data transfer.
-                enum:
-                - kopia
-                - restic
-                - ""
-                type: string
               volume:
                 description: Volume is the name of the volume within the Pod to be
                   backed up.
@@ -198,7 +153,6 @@ spec:
         type: object
     served: true
     storage: true
-    subresources: {}
 status:
   acceptedNames:
     kind: ""

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

@@ -4,7 +4,7 @@ apiVersion: apiextensions.k8s.io/v1
 kind: CustomResourceDefinition
 metadata:
   annotations:
-    controller-gen.kubebuilder.io/version: v0.7.0
+    controller-gen.kubebuilder.io/version: v0.3.0
   creationTimestamp: null
   name: podvolumerestores.velero.io
 spec:
@@ -16,41 +16,7 @@ spec:
     singular: podvolumerestore
   scope: Namespaced
   versions:
-  - additionalPrinterColumns:
-    - description: Namespace of the pod containing the volume to be restored
-      jsonPath: .spec.pod.namespace
-      name: Namespace
-      type: string
-    - description: Name of the pod containing the volume to be restored
-      jsonPath: .spec.pod.name
-      name: Pod
-      type: string
-    - description: The type of the uploader to handle data transfer
-      jsonPath: .spec.uploaderType
-      name: Uploader Type
-      type: string
-    - description: Name of the volume to be restored
-      jsonPath: .spec.volume
-      name: Volume
-      type: string
-    - description: Pod Volume Restore status such as New/InProgress
-      jsonPath: .status.phase
-      name: Status
-      type: string
-    - description: Pod Volume Restore status such as New/InProgress
-      format: int64
-      jsonPath: .status.progress.totalBytes
-      name: TotalBytes
-      type: integer
-    - description: Pod Volume Restore status such as New/InProgress
-      format: int64
-      jsonPath: .status.progress.bytesDone
-      name: BytesDone
-      type: integer
-    - jsonPath: .metadata.creationTimestamp
-      name: Age
-      type: date
-    name: v1
+  - name: v1
     schema:
       openAPIV3Schema:
         properties:
@@ -71,7 +37,7 @@ spec:
             properties:
               backupStorageLocation:
                 description: BackupStorageLocation is the name of the backup storage
-                  location where the backup repository is stored.
+                  location where the restic repository is stored.
                 type: string
               pod:
                 description: Pod is a reference to the pod containing the volume to
@@ -111,23 +77,11 @@ spec:
                     type: string
                 type: object
               repoIdentifier:
-                description: RepoIdentifier is the backup repository identifier.
+                description: RepoIdentifier is the restic repository identifier.
                 type: string
               snapshotID:
                 description: SnapshotID is the ID of the volume snapshot to be restored.
                 type: string
-              sourceNamespace:
-                description: SourceNamespace is the original namespace for namaspace
-                  mapping.
-                type: string
-              uploaderType:
-                description: UploaderType is the type of the uploader to handle the
-                  data transfer.
-                enum:
-                - kopia
-                - restic
-                - ""
-                type: string
               volume:
                 description: Volume is the name of the volume within the Pod to be
                   restored.
@@ -137,7 +91,6 @@ spec:
             - pod
             - repoIdentifier
             - snapshotID
-            - sourceNamespace
             - volume
             type: object
           status:
@@ -183,7 +136,6 @@ spec:
         type: object
     served: true
     storage: true
-    subresources: {}
 status:
   acceptedNames:
     kind: ""

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

@@ -4,26 +4,19 @@ apiVersion: apiextensions.k8s.io/v1
 kind: CustomResourceDefinition
 metadata:
   annotations:
-    controller-gen.kubebuilder.io/version: v0.7.0
+    controller-gen.kubebuilder.io/version: v0.3.0
   creationTimestamp: null
-  name: backuprepositories.velero.io
+  name: resticrepositories.velero.io
 spec:
   group: velero.io
   names:
-    kind: BackupRepository
-    listKind: BackupRepositoryList
-    plural: backuprepositories
-    singular: backuprepository
+    kind: ResticRepository
+    listKind: ResticRepositoryList
+    plural: resticrepositories
+    singular: resticrepository
   scope: Namespaced
   versions:
-  - additionalPrinterColumns:
-    - jsonPath: .metadata.creationTimestamp
-      name: Age
-      type: date
-    - jsonPath: .spec.repositoryType
-      name: Repository Type
-      type: string
-    name: v1
+  - name: v1
     schema:
       openAPIV3Schema:
         properties:
@@ -40,7 +33,7 @@ spec:
           metadata:
             type: object
           spec:
-            description: BackupRepositorySpec is the specification for a BackupRepository.
+            description: ResticRepositorySpec is the specification for a ResticRepository.
             properties:
               backupStorageLocation:
                 description: BackupStorageLocation is the name of the BackupStorageLocation
@@ -50,19 +43,12 @@ spec:
                 description: MaintenanceFrequency is how often maintenance should
                   be run.
                 type: string
-              repositoryType:
-                description: RepositoryType indicates the type of the backend repository
-                enum:
-                - kopia
-                - restic
-                - ""
-                type: string
               resticIdentifier:
                 description: ResticIdentifier is the full restic-compatible string
                   for identifying this repository.
                 type: string
               volumeNamespace:
-                description: VolumeNamespace is the namespace this backup repository
+                description: VolumeNamespace is the namespace this restic repository
                   contains pod volume backups for.
                 type: string
             required:
@@ -72,7 +58,7 @@ spec:
             - volumeNamespace
             type: object
           status:
-            description: BackupRepositoryStatus is the current status of a BackupRepository.
+            description: ResticRepositoryStatus is the current status of a ResticRepository.
             properties:
               lastMaintenanceTime:
                 description: LastMaintenanceTime is the last time maintenance was
@@ -82,10 +68,10 @@ spec:
                 type: string
               message:
                 description: Message is a message about the current status of the
-                  BackupRepository.
+                  ResticRepository.
                 type: string
               phase:
-                description: Phase is the current state of the BackupRepository.
+                description: Phase is the current state of the ResticRepository.
                 enum:
                 - New
                 - Ready
@@ -95,7 +81,6 @@ spec:
         type: object
     served: true
     storage: true
-    subresources: {}
 status:
   acceptedNames:
     kind: ""

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

@@ -4,7 +4,7 @@ apiVersion: apiextensions.k8s.io/v1
 kind: CustomResourceDefinition
 metadata:
   annotations:
-    controller-gen.kubebuilder.io/version: v0.7.0
+    controller-gen.kubebuilder.io/version: v0.3.0
   creationTimestamp: null
   name: schedules.velero.io
 spec:
@@ -16,26 +16,7 @@ spec:
     singular: schedule
   scope: Namespaced
   versions:
-  - additionalPrinterColumns:
-    - description: Status of the schedule
-      jsonPath: .status.phase
-      name: Status
-      type: string
-    - description: A Cron expression defining when to run the Backup
-      jsonPath: .spec.schedule
-      name: Schedule
-      type: string
-    - description: The last time a Backup was run for this schedule
-      jsonPath: .status.lastBackup
-      name: LastBackup
-      type: date
-    - jsonPath: .metadata.creationTimestamp
-      name: Age
-      type: date
-    - jsonPath: .spec.paused
-      name: Paused
-      type: boolean
-    name: v1
+  - name: v1
     schema:
       openAPIV3Schema:
         description: Schedule is a Velero resource that represents a pre-scheduled
@@ -56,9 +37,6 @@ spec:
           spec:
             description: ScheduleSpec defines the specification for a Velero schedule
             properties:
-              paused:
-                description: Paused specifies whether the schedule is paused or not
-                type: boolean
               schedule:
                 description: Schedule is a Cron expression defining when to run the
                   Backup.
@@ -67,22 +45,9 @@ spec:
                 description: Template is the definition of the Backup to be run on
                   the provided schedule
                 properties:
-                  csiSnapshotTimeout:
-                    description: CSISnapshotTimeout specifies the time used to wait
-                      for CSI VolumeSnapshot status turns to ReadyToUse during creation,
-                      before returning error as timeout. The default value is 10 minute.
-                    type: string
-                  defaultVolumesToFsBackup:
-                    description: DefaultVolumesToFsBackup specifies whether pod volume
-                      file system backup should be used for all volumes by default.
-                    nullable: true
-                    type: boolean
                   defaultVolumesToRestic:
-                    description: "DefaultVolumesToRestic specifies whether restic
-                      should be used to take a backup of all pod volumes by default.
-                      \n Deprecated: this field is no longer used and will be removed
-                      entirely in future. Use DefaultVolumesToFsBackup instead."
-                    nullable: true
+                    description: DefaultVolumesToRestic specifies whether restic should
+                      be used to take a backup of all pod volumes by default.
                     type: boolean
                   excludedNamespaces:
                     description: ExcludedNamespaces contains a list of namespaces
@@ -362,69 +327,14 @@ spec:
                           type: string
                         type: object
                     type: object
-                  orLabelSelectors:
-                    description: OrLabelSelectors is list of metav1.LabelSelector
-                      to filter with when adding individual objects to the backup.
-                      If multiple provided they will be joined by the OR operator.
-                      LabelSelector as well as OrLabelSelectors cannot co-exist in
-                      backup request, only one of them can be used.
-                    items:
-                      description: A label selector is a label query over a set of
-                        resources. The result of matchLabels and matchExpressions
-                        are ANDed. An empty label selector matches all objects. A
-                        null label selector matches no objects.
-                      properties:
-                        matchExpressions:
-                          description: matchExpressions is a list of label selector
-                            requirements. The requirements are ANDed.
-                          items:
-                            description: A label selector requirement is a selector
-                              that contains values, a key, and an operator that relates
-                              the key and values.
-                            properties:
-                              key:
-                                description: key is the label key that the selector
-                                  applies to.
-                                type: string
-                              operator:
-                                description: operator represents a key's relationship
-                                  to a set of values. Valid operators are In, NotIn,
-                                  Exists and DoesNotExist.
-                                type: string
-                              values:
-                                description: values is an array of string values.
-                                  If the operator is In or NotIn, the values array
-                                  must be non-empty. If the operator is Exists or
-                                  DoesNotExist, the values array must be empty. This
-                                  array is replaced during a strategic merge patch.
-                                items:
-                                  type: string
-                                type: array
-                            required:
-                            - key
-                            - operator
-                            type: object
-                          type: array
-                        matchLabels:
-                          additionalProperties:
-                            type: string
-                          description: matchLabels is a map of {key,value} pairs.
-                            A single {key,value} in the matchLabels map is equivalent
-                            to an element of matchExpressions, whose key field is
-                            "key", the operator is "In", and the values array contains
-                            only "value". The requirements are ANDed.
-                          type: object
-                      type: object
-                    nullable: true
-                    type: array
                   orderedResources:
                     additionalProperties:
                       type: string
                     description: OrderedResources specifies the backup order of resources
-                      of specific Kind. The map key is the resource name and value
-                      is a list of object names separated by commas. Each resource
-                      name has format "namespace/objectname".  For cluster resources,
-                      simply use "objectname".
+                      of specific Kind. The map key is the Kind name and value is
+                      a list of resource names separated by commas. Each resource
+                      name has format "namespace/resourcename".  For cluster resources,
+                      simply use "resourcename".
                     nullable: true
                     type: object
                   snapshotVolumes:
@@ -483,7 +393,6 @@ spec:
         type: object
     served: true
     storage: true
-    subresources: {}
 status:
   acceptedNames:
     kind: ""

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

@@ -4,7 +4,7 @@ apiVersion: apiextensions.k8s.io/v1
 kind: CustomResourceDefinition
 metadata:
   annotations:
-    controller-gen.kubebuilder.io/version: v0.7.0
+    controller-gen.kubebuilder.io/version: v0.3.0
   creationTimestamp: null
   name: serverstatusrequests.velero.io
 spec:
@@ -77,6 +77,8 @@ spec:
         type: object
     served: true
     storage: true
+    subresources:
+      status: {}
 status:
   acceptedNames:
     kind: ""

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

@@ -4,7 +4,7 @@ apiVersion: apiextensions.k8s.io/v1
 kind: CustomResourceDefinition
 metadata:
   annotations:
-    controller-gen.kubebuilder.io/version: v0.7.0
+    controller-gen.kubebuilder.io/version: v0.3.0
   creationTimestamp: null
   name: volumesnapshotlocations.velero.io
 spec:
@@ -13,8 +13,6 @@ spec:
     kind: VolumeSnapshotLocation
     listKind: VolumeSnapshotLocationList
     plural: volumesnapshotlocations
-    shortNames:
-    - vsl
     singular: volumesnapshotlocation
   scope: Namespaced
   versions:
@@ -45,24 +43,6 @@ spec:
                   type: string
                 description: Config is for provider-specific configuration fields.
                 type: object
-              credential:
-                description: Credential contains the credential information intended
-                  to be used with this location
-                properties:
-                  key:
-                    description: The key of the secret to select from.  Must be a
-                      valid secret key.
-                    type: string
-                  name:
-                    description: 'Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
-                      TODO: Add other useful fields. apiVersion, kind, uid?'
-                    type: string
-                  optional:
-                    description: Specify whether the Secret or its key must be defined
-                    type: boolean
-                required:
-                - key
-                type: object
               provider:
                 description: Provider is the provider of the volume storage.
                 type: string

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

@@ -0,0 +1,439 @@
+
+---
+apiVersion: apiextensions.k8s.io/v1beta1
+kind: CustomResourceDefinition
+metadata:
+  annotations:
+    controller-gen.kubebuilder.io/version: v0.3.0
+  creationTimestamp: null
+  name: backups.velero.io
+spec:
+  group: velero.io
+  names:
+    kind: Backup
+    listKind: BackupList
+    plural: backups
+    singular: backup
+  preserveUnknownFields: false
+  scope: Namespaced
+  validation:
+    openAPIV3Schema:
+      description: Backup is a Velero resource that represents the capture of Kubernetes
+        cluster state at a point in time (API objects and associated volume state).
+      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: BackupSpec defines the specification for a Velero backup.
+          properties:
+            defaultVolumesToRestic:
+              description: DefaultVolumesToRestic specifies whether restic should
+                be used to take a backup of all pod volumes by default.
+              type: boolean
+            excludedNamespaces:
+              description: ExcludedNamespaces contains a list of namespaces that are
+                not included in the backup.
+              items:
+                type: string
+              nullable: true
+              type: array
+            excludedResources:
+              description: ExcludedResources is a slice of resource names that are
+                not included in the backup.
+              items:
+                type: string
+              nullable: true
+              type: array
+            hooks:
+              description: Hooks represent custom behaviors that should be executed
+                at different phases of the backup.
+              properties:
+                resources:
+                  description: Resources are hooks that should be executed when backing
+                    up individual instances of a resource.
+                  items:
+                    description: BackupResourceHookSpec defines one or more BackupResourceHooks
+                      that should be executed based on the rules defined for namespaces,
+                      resources, and label selector.
+                    properties:
+                      excludedNamespaces:
+                        description: ExcludedNamespaces specifies the namespaces to
+                          which this hook spec does not apply.
+                        items:
+                          type: string
+                        nullable: true
+                        type: array
+                      excludedResources:
+                        description: ExcludedResources specifies the resources to
+                          which this hook spec does not apply.
+                        items:
+                          type: string
+                        nullable: true
+                        type: array
+                      includedNamespaces:
+                        description: IncludedNamespaces specifies the namespaces to
+                          which this hook spec applies. If empty, it applies to all
+                          namespaces.
+                        items:
+                          type: string
+                        nullable: true
+                        type: array
+                      includedResources:
+                        description: IncludedResources specifies the resources to
+                          which this hook spec applies. If empty, it applies to all
+                          resources.
+                        items:
+                          type: string
+                        nullable: true
+                        type: array
+                      labelSelector:
+                        description: LabelSelector, if specified, filters the resources
+                          to which this hook spec applies.
+                        nullable: true
+                        properties:
+                          matchExpressions:
+                            description: matchExpressions is a list of label selector
+                              requirements. The requirements are ANDed.
+                            items:
+                              description: A label selector requirement is a selector
+                                that contains values, a key, and an operator that
+                                relates the key and values.
+                              properties:
+                                key:
+                                  description: key is the label key that the selector
+                                    applies to.
+                                  type: string
+                                operator:
+                                  description: operator represents a key's relationship
+                                    to a set of values. Valid operators are In, NotIn,
+                                    Exists and DoesNotExist.
+                                  type: string
+                                values:
+                                  description: values is an array of string values.
+                                    If the operator is In or NotIn, the values array
+                                    must be non-empty. If the operator is Exists or
+                                    DoesNotExist, the values array must be empty.
+                                    This array is replaced during a strategic merge
+                                    patch.
+                                  items:
+                                    type: string
+                                  type: array
+                              required:
+                              - key
+                              - operator
+                              type: object
+                            type: array
+                          matchLabels:
+                            additionalProperties:
+                              type: string
+                            description: matchLabels is a map of {key,value} pairs.
+                              A single {key,value} in the matchLabels map is equivalent
+                              to an element of matchExpressions, whose key field is
+                              "key", the operator is "In", and the values array contains
+                              only "value". The requirements are ANDed.
+                            type: object
+                        type: object
+                      name:
+                        description: Name is the name of this hook.
+                        type: string
+                      post:
+                        description: PostHooks is a list of BackupResourceHooks to
+                          execute after storing the item in the backup. These are
+                          executed after all "additional items" from item actions
+                          are processed.
+                        items:
+                          description: BackupResourceHook defines a hook for a resource.
+                          properties:
+                            exec:
+                              description: Exec defines an exec hook.
+                              properties:
+                                command:
+                                  description: Command is the command and arguments
+                                    to execute.
+                                  items:
+                                    type: string
+                                  minItems: 1
+                                  type: array
+                                container:
+                                  description: Container is the container in the pod
+                                    where the command should be executed. If not specified,
+                                    the pod's first container is used.
+                                  type: string
+                                onError:
+                                  description: OnError specifies how Velero should
+                                    behave if it encounters an error executing this
+                                    hook.
+                                  enum:
+                                  - Continue
+                                  - Fail
+                                  type: string
+                                timeout:
+                                  description: Timeout defines the maximum amount
+                                    of time Velero should wait for the hook to complete
+                                    before considering the execution a failure.
+                                  type: string
+                              required:
+                              - command
+                              type: object
+                          required:
+                          - exec
+                          type: object
+                        type: array
+                      pre:
+                        description: PreHooks is a list of BackupResourceHooks to
+                          execute prior to storing the item in the backup. These are
+                          executed before any "additional items" from item actions
+                          are processed.
+                        items:
+                          description: BackupResourceHook defines a hook for a resource.
+                          properties:
+                            exec:
+                              description: Exec defines an exec hook.
+                              properties:
+                                command:
+                                  description: Command is the command and arguments
+                                    to execute.
+                                  items:
+                                    type: string
+                                  minItems: 1
+                                  type: array
+                                container:
+                                  description: Container is the container in the pod
+                                    where the command should be executed. If not specified,
+                                    the pod's first container is used.
+                                  type: string
+                                onError:
+                                  description: OnError specifies how Velero should
+                                    behave if it encounters an error executing this
+                                    hook.
+                                  enum:
+                                  - Continue
+                                  - Fail
+                                  type: string
+                                timeout:
+                                  description: Timeout defines the maximum amount
+                                    of time Velero should wait for the hook to complete
+                                    before considering the execution a failure.
+                                  type: string
+                              required:
+                              - command
+                              type: object
+                          required:
+                          - exec
+                          type: object
+                        type: array
+                    required:
+                    - name
+                    type: object
+                  nullable: true
+                  type: array
+              type: object
+            includeClusterResources:
+              description: IncludeClusterResources specifies whether cluster-scoped
+                resources should be included for consideration in the backup.
+              nullable: true
+              type: boolean
+            includedNamespaces:
+              description: IncludedNamespaces is a slice of namespace names to include
+                objects from. If empty, all namespaces are included.
+              items:
+                type: string
+              nullable: true
+              type: array
+            includedResources:
+              description: IncludedResources is a slice of resource names to include
+                in the backup. If empty, all resources are included.
+              items:
+                type: string
+              nullable: true
+              type: array
+            labelSelector:
+              description: LabelSelector is a metav1.LabelSelector to filter with
+                when adding individual objects to the backup. If empty or nil, all
+                objects are included. Optional.
+              nullable: true
+              properties:
+                matchExpressions:
+                  description: matchExpressions is a list of label selector requirements.
+                    The requirements are ANDed.
+                  items:
+                    description: A label selector requirement is a selector that contains
+                      values, a key, and an operator that relates the key and values.
+                    properties:
+                      key:
+                        description: key is the label key that the selector applies
+                          to.
+                        type: string
+                      operator:
+                        description: operator represents a key's relationship to a
+                          set of values. Valid operators are In, NotIn, Exists and
+                          DoesNotExist.
+                        type: string
+                      values:
+                        description: values is an array of string values. If the operator
+                          is In or NotIn, the values array must be non-empty. If the
+                          operator is Exists or DoesNotExist, the values array must
+                          be empty. This array is replaced during a strategic merge
+                          patch.
+                        items:
+                          type: string
+                        type: array
+                    required:
+                    - key
+                    - operator
+                    type: object
+                  type: array
+                matchLabels:
+                  additionalProperties:
+                    type: string
+                  description: matchLabels is a map of {key,value} pairs. A single
+                    {key,value} in the matchLabels map is equivalent to an element
+                    of matchExpressions, whose key field is "key", the operator is
+                    "In", and the values array contains only "value". The requirements
+                    are ANDed.
+                  type: object
+              type: object
+            metadata:
+              properties:
+                labels:
+                  additionalProperties:
+                    type: string
+                  type: object
+              type: object
+            orderedResources:
+              additionalProperties:
+                type: string
+              description: OrderedResources specifies the backup order of resources
+                of specific Kind. The map key is the Kind name and value is a list
+                of resource names separated by commas. Each resource name has format
+                "namespace/resourcename".  For cluster resources, simply use "resourcename".
+              nullable: true
+              type: object
+            snapshotVolumes:
+              description: SnapshotVolumes specifies whether to take cloud snapshots
+                of any PV's referenced in the set of objects included in the Backup.
+              nullable: true
+              type: boolean
+            storageLocation:
+              description: StorageLocation is a string containing the name of a BackupStorageLocation
+                where the backup should be stored.
+              type: string
+            ttl:
+              description: TTL is a time.Duration-parseable string describing how
+                long the Backup should be retained for.
+              type: string
+            volumeSnapshotLocations:
+              description: VolumeSnapshotLocations is a list containing names of VolumeSnapshotLocations
+                associated with this backup.
+              items:
+                type: string
+              type: array
+          type: object
+        status:
+          description: BackupStatus captures the current status of a Velero backup.
+          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
+            errors:
+              description: Errors is a count of all error messages that were generated
+                during execution of the backup.  The actual errors are in the backup's
+                log file in object storage.
+              type: integer
+            expiration:
+              description: Expiration is when this Backup is eligible for garbage-collection.
+              format: date-time
+              nullable: true
+              type: string
+            formatVersion:
+              description: FormatVersion is the backup format version, including major,
+                minor, and patch version.
+              type: string
+            phase:
+              description: Phase is the current state of the Backup.
+              enum:
+              - New
+              - FailedValidation
+              - InProgress
+              - Completed
+              - PartiallyFailed
+              - Failed
+              - Deleting
+              type: string
+            progress:
+              description: Progress contains information about the backup's execution
+                progress. Note that this information is best-effort only -- if Velero
+                fails to update it during a backup for any reason, it may be inaccurate/stale.
+              nullable: true
+              properties:
+                itemsBackedUp:
+                  description: ItemsBackedUp is the number of items that have actually
+                    been written to the backup tarball so far.
+                  type: integer
+                totalItems:
+                  description: TotalItems is the total number of items to be backed
+                    up. This number may change throughout the execution of the backup
+                    due to plugins that return additional related items to back up,
+                    the velero.io/exclude-from-backup label, and various other filters
+                    that happen as items are processed.
+                  type: integer
+              type: object
+            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
+            validationErrors:
+              description: ValidationErrors is a slice of all validation errors (if
+                applicable).
+              items:
+                type: string
+              nullable: true
+              type: array
+            version:
+              description: 'Version is the backup format major version. Deprecated:
+                Please see FormatVersion'
+              type: integer
+            volumeSnapshotsAttempted:
+              description: VolumeSnapshotsAttempted is the total number of attempted
+                volume snapshots for this backup.
+              type: integer
+            volumeSnapshotsCompleted:
+              description: VolumeSnapshotsCompleted is the total number of successfully
+                completed volume snapshots for this backup.
+              type: integer
+            warnings:
+              description: Warnings is a count of all warning messages that were generated
+                during execution of the backup. The actual warnings are in the backup's
+                log file in object storage.
+              type: integer
+          type: object
+      type: object
+  version: v1
+  versions:
+  - name: v1
+    served: true
+    storage: true
+status:
+  acceptedNames:
+    kind: ""
+    plural: ""
+  conditions: []
+  storedVersions: []

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

@@ -0,0 +1,179 @@
+
+---
+apiVersion: apiextensions.k8s.io/v1beta1
+kind: CustomResourceDefinition
+metadata:
+  annotations:
+    controller-gen.kubebuilder.io/version: v0.3.0
+  creationTimestamp: null
+  name: backupstoragelocations.velero.io
+spec:
+  additionalPrinterColumns:
+  - JSONPath: .status.phase
+    description: Backup Storage Location status such as Available/Unavailable
+    name: Phase
+    type: string
+  - JSONPath: .status.lastValidationTime
+    description: LastValidationTime is the last time the backup store location was
+      validated
+    name: Last Validated
+    type: date
+  - JSONPath: .metadata.creationTimestamp
+    name: Age
+    type: date
+  - JSONPath: .spec.default
+    description: Default backup storage location
+    name: Default
+    type: boolean
+  group: velero.io
+  names:
+    kind: BackupStorageLocation
+    listKind: BackupStorageLocationList
+    plural: backupstoragelocations
+    shortNames:
+    - bsl
+    singular: backupstoragelocation
+  preserveUnknownFields: false
+  scope: Namespaced
+  subresources:
+    status: {}
+  validation:
+    openAPIV3Schema:
+      description: BackupStorageLocation is a location where Velero stores backup
+        objects
+      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: BackupStorageLocationSpec defines the desired state of a Velero
+            BackupStorageLocation
+          properties:
+            accessMode:
+              description: AccessMode defines the permissions for the backup storage
+                location.
+              enum:
+              - ReadOnly
+              - ReadWrite
+              type: string
+            backupSyncPeriod:
+              description: BackupSyncPeriod defines how frequently to sync backup
+                API objects from object storage. A value of 0 disables sync.
+              nullable: true
+              type: string
+            config:
+              additionalProperties:
+                type: string
+              description: Config is for provider-specific configuration fields.
+              type: object
+            credential:
+              description: Credential contains the credential information intended
+                to be used with this location
+              properties:
+                key:
+                  description: The key of the secret to select from.  Must be a valid
+                    secret key.
+                  type: string
+                name:
+                  description: 'Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
+                    TODO: Add other useful fields. apiVersion, kind, uid?'
+                  type: string
+                optional:
+                  description: Specify whether the Secret or its key must be defined
+                  type: boolean
+              required:
+              - key
+              type: object
+            default:
+              description: Default indicates this location is the default backup storage
+                location.
+              type: boolean
+            objectStorage:
+              description: ObjectStorageLocation specifies the settings necessary
+                to connect to a provider's object storage.
+              properties:
+                bucket:
+                  description: Bucket is the bucket to use for object storage.
+                  type: string
+                caCert:
+                  description: CACert defines a CA bundle to use when verifying TLS
+                    connections to the provider.
+                  format: byte
+                  type: string
+                prefix:
+                  description: Prefix is the path inside a bucket to use for Velero
+                    storage. Optional.
+                  type: string
+              required:
+              - bucket
+              type: object
+            provider:
+              description: Provider is the provider of the backup storage.
+              type: string
+            validationFrequency:
+              description: ValidationFrequency defines how frequently to validate
+                the corresponding object storage. A value of 0 disables validation.
+              nullable: true
+              type: string
+          required:
+          - objectStorage
+          - provider
+          type: object
+        status:
+          description: BackupStorageLocationStatus defines the observed state of BackupStorageLocation
+          properties:
+            accessMode:
+              description: "AccessMode is an unused field. \n Deprecated: there is
+                now an AccessMode field on the Spec and this field will be removed
+                entirely as of v2.0."
+              enum:
+              - ReadOnly
+              - ReadWrite
+              type: string
+            lastSyncedRevision:
+              description: "LastSyncedRevision is the value of the `metadata/revision`
+                file in the backup storage location the last time the BSL's contents
+                were synced into the cluster. \n Deprecated: this field is no longer
+                updated or used for detecting changes to the location's contents and
+                will be removed entirely in v2.0."
+              type: string
+            lastSyncedTime:
+              description: LastSyncedTime is the last time the contents of the location
+                were synced into the cluster.
+              format: date-time
+              nullable: true
+              type: string
+            lastValidationTime:
+              description: LastValidationTime is the last time the backup store location
+                was validated the cluster.
+              format: date-time
+              nullable: true
+              type: string
+            phase:
+              description: Phase is the current state of the BackupStorageLocation.
+              enum:
+              - Available
+              - Unavailable
+              type: string
+          type: object
+      type: object
+  version: v1
+  versions:
+  - name: v1
+    served: true
+    storage: true
+status:
+  acceptedNames:
+    kind: ""
+    plural: ""
+  conditions: []
+  storedVersions: []

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

@@ -0,0 +1,73 @@
+
+---
+apiVersion: apiextensions.k8s.io/v1beta1
+kind: CustomResourceDefinition
+metadata:
+  annotations:
+    controller-gen.kubebuilder.io/version: v0.3.0
+  creationTimestamp: null
+  name: deletebackuprequests.velero.io
+spec:
+  group: velero.io
+  names:
+    kind: DeleteBackupRequest
+    listKind: DeleteBackupRequestList
+    plural: deletebackuprequests
+    singular: deletebackuprequest
+  preserveUnknownFields: false
+  scope: Namespaced
+  validation:
+    openAPIV3Schema:
+      description: DeleteBackupRequest is a request to delete one or more backups.
+      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: DeleteBackupRequestSpec is the specification for which backups
+            to delete.
+          properties:
+            backupName:
+              type: string
+          required:
+          - backupName
+          type: object
+        status:
+          description: DeleteBackupRequestStatus is the current status of a DeleteBackupRequest.
+          properties:
+            errors:
+              description: Errors contains any errors that were encountered during
+                the deletion process.
+              items:
+                type: string
+              nullable: true
+              type: array
+            phase:
+              description: Phase is the current state of the DeleteBackupRequest.
+              enum:
+              - New
+              - InProgress
+              - Processed
+              type: string
+          type: object
+      type: object
+  version: v1
+  versions:
+  - name: v1
+    served: true
+    storage: true
+status:
+  acceptedNames:
+    kind: ""
+    plural: ""
+  conditions: []
+  storedVersions: []

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

@@ -0,0 +1,96 @@
+
+---
+apiVersion: apiextensions.k8s.io/v1beta1
+kind: CustomResourceDefinition
+metadata:
+  annotations:
+    controller-gen.kubebuilder.io/version: v0.3.0
+  creationTimestamp: null
+  name: downloadrequests.velero.io
+spec:
+  group: velero.io
+  names:
+    kind: DownloadRequest
+    listKind: DownloadRequestList
+    plural: downloadrequests
+    singular: downloadrequest
+  preserveUnknownFields: false
+  scope: Namespaced
+  subresources:
+    status: {}
+  validation:
+    openAPIV3Schema:
+      description: DownloadRequest is a request to download an artifact from backup
+        object storage, such as a backup log file.
+      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: DownloadRequestSpec is the specification for a download request.
+          properties:
+            target:
+              description: Target is what to download (e.g. logs for a backup).
+              properties:
+                kind:
+                  description: Kind is the type of file to download.
+                  enum:
+                  - BackupLog
+                  - BackupContents
+                  - BackupVolumeSnapshots
+                  - BackupResourceList
+                  - RestoreLog
+                  - RestoreResults
+                  type: string
+                name:
+                  description: Name is the name of the kubernetes resource with which
+                    the file is associated.
+                  type: string
+              required:
+              - kind
+              - name
+              type: object
+          required:
+          - target
+          type: object
+        status:
+          description: DownloadRequestStatus is the current status of a DownloadRequest.
+          properties:
+            downloadURL:
+              description: DownloadURL contains the pre-signed URL for the target
+                file.
+              type: string
+            expiration:
+              description: Expiration is when this DownloadRequest expires and can
+                be deleted by the system.
+              format: date-time
+              nullable: true
+              type: string
+            phase:
+              description: Phase is the current state of the DownloadRequest.
+              enum:
+              - New
+              - Processed
+              type: string
+          type: object
+      type: object
+  version: v1
+  versions:
+  - name: v1
+    served: true
+    storage: true
+status:
+  acceptedNames:
+    kind: ""
+    plural: ""
+  conditions: []
+  storedVersions: []

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

@@ -0,0 +1,162 @@
+
+---
+apiVersion: apiextensions.k8s.io/v1beta1
+kind: CustomResourceDefinition
+metadata:
+  annotations:
+    controller-gen.kubebuilder.io/version: v0.3.0
+  creationTimestamp: null
+  name: podvolumebackups.velero.io
+spec:
+  group: velero.io
+  names:
+    kind: PodVolumeBackup
+    listKind: PodVolumeBackupList
+    plural: podvolumebackups
+    singular: podvolumebackup
+  preserveUnknownFields: false
+  scope: Namespaced
+  validation:
+    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: PodVolumeBackupSpec is the specification for a PodVolumeBackup.
+          properties:
+            backupStorageLocation:
+              description: BackupStorageLocation is the name of the backup storage
+                location where the restic repository is stored.
+              type: string
+            node:
+              description: Node is the name of the node that the Pod is running on.
+              type: string
+            pod:
+              description: Pod is a reference to the pod containing the volume to
+                be backed up.
+              properties:
+                apiVersion:
+                  description: API version of the referent.
+                  type: string
+                fieldPath:
+                  description: 'If referring to a piece of an object instead of an
+                    entire object, this string should contain a valid JSON/Go field
+                    access statement, such as desiredState.manifest.containers[2].
+                    For example, if the object reference is to a container within
+                    a pod, this would take on a value like: "spec.containers{name}"
+                    (where "name" refers to the name of the container that triggered
+                    the event) or if no container name is specified "spec.containers[2]"
+                    (container with index 2 in this pod). This syntax is chosen only
+                    to have some well-defined way of referencing a part of an object.
+                    TODO: this design is not final and this field is subject to change
+                    in the future.'
+                  type: string
+                kind:
+                  description: 'Kind of the referent. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds'
+                  type: string
+                name:
+                  description: 'Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names'
+                  type: string
+                namespace:
+                  description: 'Namespace of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/'
+                  type: string
+                resourceVersion:
+                  description: 'Specific resourceVersion to which this reference is
+                    made, if any. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency'
+                  type: string
+                uid:
+                  description: 'UID of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids'
+                  type: string
+              type: object
+            repoIdentifier:
+              description: RepoIdentifier is the restic repository identifier.
+              type: string
+            tags:
+              additionalProperties:
+                type: string
+              description: Tags are a map of key-value pairs that should be applied
+                to the volume backup as tags.
+              type: object
+            volume:
+              description: Volume is the name of the volume within the Pod to be backed
+                up.
+              type: string
+          required:
+          - backupStorageLocation
+          - node
+          - pod
+          - repoIdentifier
+          - volume
+          type: object
+        status:
+          description: PodVolumeBackupStatus is the current status of a PodVolumeBackup.
+          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
+            message:
+              description: Message is a message about the pod volume backup's status.
+              type: string
+            path:
+              description: Path is the full path within the controller pod being backed
+                up.
+              type: string
+            phase:
+              description: Phase is the current state of the PodVolumeBackup.
+              enum:
+              - New
+              - InProgress
+              - 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 of the pod
+                volume.
+              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
+  version: v1
+  versions:
+  - name: v1
+    served: true
+    storage: true
+status:
+  acceptedNames:
+    kind: ""
+    plural: ""
+  conditions: []
+  storedVersions: []

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

@@ -0,0 +1,145 @@
+
+---
+apiVersion: apiextensions.k8s.io/v1beta1
+kind: CustomResourceDefinition
+metadata:
+  annotations:
+    controller-gen.kubebuilder.io/version: v0.3.0
+  creationTimestamp: null
+  name: podvolumerestores.velero.io
+spec:
+  group: velero.io
+  names:
+    kind: PodVolumeRestore
+    listKind: PodVolumeRestoreList
+    plural: podvolumerestores
+    singular: podvolumerestore
+  preserveUnknownFields: false
+  scope: Namespaced
+  validation:
+    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: PodVolumeRestoreSpec is the specification for a PodVolumeRestore.
+          properties:
+            backupStorageLocation:
+              description: BackupStorageLocation is the name of the backup storage
+                location where the restic repository is stored.
+              type: string
+            pod:
+              description: Pod is a reference to the pod containing the volume to
+                be restored.
+              properties:
+                apiVersion:
+                  description: API version of the referent.
+                  type: string
+                fieldPath:
+                  description: 'If referring to a piece of an object instead of an
+                    entire object, this string should contain a valid JSON/Go field
+                    access statement, such as desiredState.manifest.containers[2].
+                    For example, if the object reference is to a container within
+                    a pod, this would take on a value like: "spec.containers{name}"
+                    (where "name" refers to the name of the container that triggered
+                    the event) or if no container name is specified "spec.containers[2]"
+                    (container with index 2 in this pod). This syntax is chosen only
+                    to have some well-defined way of referencing a part of an object.
+                    TODO: this design is not final and this field is subject to change
+                    in the future.'
+                  type: string
+                kind:
+                  description: 'Kind of the referent. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds'
+                  type: string
+                name:
+                  description: 'Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names'
+                  type: string
+                namespace:
+                  description: 'Namespace of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/'
+                  type: string
+                resourceVersion:
+                  description: 'Specific resourceVersion to which this reference is
+                    made, if any. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency'
+                  type: string
+                uid:
+                  description: 'UID of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids'
+                  type: string
+              type: object
+            repoIdentifier:
+              description: RepoIdentifier is the restic repository identifier.
+              type: string
+            snapshotID:
+              description: SnapshotID is the ID of the volume snapshot to be restored.
+              type: string
+            volume:
+              description: Volume is the name of the volume within the Pod to be restored.
+              type: string
+          required:
+          - backupStorageLocation
+          - pod
+          - repoIdentifier
+          - snapshotID
+          - volume
+          type: object
+        status:
+          description: PodVolumeRestoreStatus is the current status of a PodVolumeRestore.
+          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 pod volume restore's status.
+              type: string
+            phase:
+              description: Phase is the current state of the PodVolumeRestore.
+              enum:
+              - New
+              - InProgress
+              - 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
+  version: v1
+  versions:
+  - name: v1
+    served: true
+    storage: true
+status:
+  acceptedNames:
+    kind: ""
+    plural: ""
+  conditions: []
+  storedVersions: []

config/crd/v1beta1/bases/velero.io_resticrepositories.yaml

@@ -0,0 +1,89 @@
+
+---
+apiVersion: apiextensions.k8s.io/v1beta1
+kind: CustomResourceDefinition
+metadata:
+  annotations:
+    controller-gen.kubebuilder.io/version: v0.3.0
+  creationTimestamp: null
+  name: resticrepositories.velero.io
+spec:
+  group: velero.io
+  names:
+    kind: ResticRepository
+    listKind: ResticRepositoryList
+    plural: resticrepositories
+    singular: resticrepository
+  preserveUnknownFields: false
+  scope: Namespaced
+  validation:
+    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: ResticRepositorySpec is the specification for a ResticRepository.
+          properties:
+            backupStorageLocation:
+              description: BackupStorageLocation is the name of the BackupStorageLocation
+                that should contain this repository.
+              type: string
+            maintenanceFrequency:
+              description: MaintenanceFrequency is how often maintenance should be
+                run.
+              type: string
+            resticIdentifier:
+              description: ResticIdentifier is the full restic-compatible string for
+                identifying this repository.
+              type: string
+            volumeNamespace:
+              description: VolumeNamespace is the namespace this restic repository
+                contains pod volume backups for.
+              type: string
+          required:
+          - backupStorageLocation
+          - maintenanceFrequency
+          - resticIdentifier
+          - volumeNamespace
+          type: object
+        status:
+          description: ResticRepositoryStatus is the current status of a ResticRepository.
+          properties:
+            lastMaintenanceTime:
+              description: LastMaintenanceTime is the last time maintenance was run.
+              format: date-time
+              nullable: true
+              type: string
+            message:
+              description: Message is a message about the current status of the ResticRepository.
+              type: string
+            phase:
+              description: Phase is the current state of the ResticRepository.
+              enum:
+              - New
+              - Ready
+              - NotReady
+              type: string
+          type: object
+      type: object
+  version: v1
+  versions:
+  - name: v1
+    served: true
+    storage: true
+status:
+  acceptedNames:
+    kind: ""
+    plural: ""
+  conditions: []
+  storedVersions: []

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

@@ -0,0 +1,401 @@
+
+---
+apiVersion: apiextensions.k8s.io/v1beta1
+kind: CustomResourceDefinition
+metadata:
+  annotations:
+    controller-gen.kubebuilder.io/version: v0.3.0
+  creationTimestamp: null
+  name: schedules.velero.io
+spec:
+  group: velero.io
+  names:
+    kind: Schedule
+    listKind: ScheduleList
+    plural: schedules
+    singular: schedule
+  preserveUnknownFields: false
+  scope: Namespaced
+  validation:
+    openAPIV3Schema:
+      description: Schedule is a Velero resource that represents a pre-scheduled or
+        periodic Backup that should be run.
+      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: ScheduleSpec defines the specification for a Velero schedule
+          properties:
+            schedule:
+              description: Schedule is a Cron expression defining when to run the
+                Backup.
+              type: string
+            template:
+              description: Template is the definition of the Backup to be run on the
+                provided schedule
+              properties:
+                defaultVolumesToRestic:
+                  description: DefaultVolumesToRestic specifies whether restic should
+                    be used to take a backup of all pod volumes by default.
+                  type: boolean
+                excludedNamespaces:
+                  description: ExcludedNamespaces contains a list of namespaces that
+                    are not included in the backup.
+                  items:
+                    type: string
+                  nullable: true
+                  type: array
+                excludedResources:
+                  description: ExcludedResources is a slice of resource names that
+                    are not included in the backup.
+                  items:
+                    type: string
+                  nullable: true
+                  type: array
+                hooks:
+                  description: Hooks represent custom behaviors that should be executed
+                    at different phases of the backup.
+                  properties:
+                    resources:
+                      description: Resources are hooks that should be executed when
+                        backing up individual instances of a resource.
+                      items:
+                        description: BackupResourceHookSpec defines one or more BackupResourceHooks
+                          that should be executed based on the rules defined for namespaces,
+                          resources, and label selector.
+                        properties:
+                          excludedNamespaces:
+                            description: ExcludedNamespaces specifies the namespaces
+                              to which this hook spec does not apply.
+                            items:
+                              type: string
+                            nullable: true
+                            type: array
+                          excludedResources:
+                            description: ExcludedResources specifies the resources
+                              to which this hook spec does not apply.
+                            items:
+                              type: string
+                            nullable: true
+                            type: array
+                          includedNamespaces:
+                            description: IncludedNamespaces specifies the namespaces
+                              to which this hook spec applies. If empty, it applies
+                              to all namespaces.
+                            items:
+                              type: string
+                            nullable: true
+                            type: array
+                          includedResources:
+                            description: IncludedResources specifies the resources
+                              to which this hook spec applies. If empty, it applies
+                              to all resources.
+                            items:
+                              type: string
+                            nullable: true
+                            type: array
+                          labelSelector:
+                            description: LabelSelector, if specified, filters the
+                              resources to which this hook spec applies.
+                            nullable: true
+                            properties:
+                              matchExpressions:
+                                description: matchExpressions is a list of label selector
+                                  requirements. The requirements are ANDed.
+                                items:
+                                  description: A label selector requirement is a selector
+                                    that contains values, a key, and an operator that
+                                    relates the key and values.
+                                  properties:
+                                    key:
+                                      description: key is the label key that the selector
+                                        applies to.
+                                      type: string
+                                    operator:
+                                      description: operator represents a key's relationship
+                                        to a set of values. Valid operators are In,
+                                        NotIn, Exists and DoesNotExist.
+                                      type: string
+                                    values:
+                                      description: values is an array of string values.
+                                        If the operator is In or NotIn, the values
+                                        array must be non-empty. If the operator is
+                                        Exists or DoesNotExist, the values array must
+                                        be empty. This array is replaced during a
+                                        strategic merge patch.
+                                      items:
+                                        type: string
+                                      type: array
+                                  required:
+                                  - key
+                                  - operator
+                                  type: object
+                                type: array
+                              matchLabels:
+                                additionalProperties:
+                                  type: string
+                                description: matchLabels is a map of {key,value} pairs.
+                                  A single {key,value} in the matchLabels map is equivalent
+                                  to an element of matchExpressions, whose key field
+                                  is "key", the operator is "In", and the values array
+                                  contains only "value". The requirements are ANDed.
+                                type: object
+                            type: object
+                          name:
+                            description: Name is the name of this hook.
+                            type: string
+                          post:
+                            description: PostHooks is a list of BackupResourceHooks
+                              to execute after storing the item in the backup. These
+                              are executed after all "additional items" from item
+                              actions are processed.
+                            items:
+                              description: BackupResourceHook defines a hook for a
+                                resource.
+                              properties:
+                                exec:
+                                  description: Exec defines an exec hook.
+                                  properties:
+                                    command:
+                                      description: Command is the command and arguments
+                                        to execute.
+                                      items:
+                                        type: string
+                                      minItems: 1
+                                      type: array
+                                    container:
+                                      description: Container is the container in the
+                                        pod where the command should be executed.
+                                        If not specified, the pod's first container
+                                        is used.
+                                      type: string
+                                    onError:
+                                      description: OnError specifies how Velero should
+                                        behave if it encounters an error executing
+                                        this hook.
+                                      enum:
+                                      - Continue
+                                      - Fail
+                                      type: string
+                                    timeout:
+                                      description: Timeout defines the maximum amount
+                                        of time Velero should wait for the hook to
+                                        complete before considering the execution
+                                        a failure.
+                                      type: string
+                                  required:
+                                  - command
+                                  type: object
+                              required:
+                              - exec
+                              type: object
+                            type: array
+                          pre:
+                            description: PreHooks is a list of BackupResourceHooks
+                              to execute prior to storing the item in the backup.
+                              These are executed before any "additional items" from
+                              item actions are processed.
+                            items:
+                              description: BackupResourceHook defines a hook for a
+                                resource.
+                              properties:
+                                exec:
+                                  description: Exec defines an exec hook.
+                                  properties:
+                                    command:
+                                      description: Command is the command and arguments
+                                        to execute.
+                                      items:
+                                        type: string
+                                      minItems: 1
+                                      type: array
+                                    container:
+                                      description: Container is the container in the
+                                        pod where the command should be executed.
+                                        If not specified, the pod's first container
+                                        is used.
+                                      type: string
+                                    onError:
+                                      description: OnError specifies how Velero should
+                                        behave if it encounters an error executing
+                                        this hook.
+                                      enum:
+                                      - Continue
+                                      - Fail
+                                      type: string
+                                    timeout:
+                                      description: Timeout defines the maximum amount
+                                        of time Velero should wait for the hook to
+                                        complete before considering the execution
+                                        a failure.
+                                      type: string
+                                  required:
+                                  - command
+                                  type: object
+                              required:
+                              - exec
+                              type: object
+                            type: array
+                        required:
+                        - name
+                        type: object
+                      nullable: true
+                      type: array
+                  type: object
+                includeClusterResources:
+                  description: IncludeClusterResources specifies whether cluster-scoped
+                    resources should be included for consideration in the backup.
+                  nullable: true
+                  type: boolean
+                includedNamespaces:
+                  description: IncludedNamespaces is a slice of namespace names to
+                    include objects from. If empty, all namespaces are included.
+                  items:
+                    type: string
+                  nullable: true
+                  type: array
+                includedResources:
+                  description: IncludedResources is a slice of resource names to include
+                    in the backup. If empty, all resources are included.
+                  items:
+                    type: string
+                  nullable: true
+                  type: array
+                labelSelector:
+                  description: LabelSelector is a metav1.LabelSelector to filter with
+                    when adding individual objects to the backup. If empty or nil,
+                    all objects are included. Optional.
+                  nullable: true
+                  properties:
+                    matchExpressions:
+                      description: matchExpressions is a list of label selector requirements.
+                        The requirements are ANDed.
+                      items:
+                        description: A label selector requirement is a selector that
+                          contains values, a key, and an operator that relates the
+                          key and values.
+                        properties:
+                          key:
+                            description: key is the label key that the selector applies
+                              to.
+                            type: string
+                          operator:
+                            description: operator represents a key's relationship
+                              to a set of values. Valid operators are In, NotIn, Exists
+                              and DoesNotExist.
+                            type: string
+                          values:
+                            description: values is an array of string values. If the
+                              operator is In or NotIn, the values array must be non-empty.
+                              If the operator is Exists or DoesNotExist, the values
+                              array must be empty. This array is replaced during a
+                              strategic merge patch.
+                            items:
+                              type: string
+                            type: array
+                        required:
+                        - key
+                        - operator
+                        type: object
+                      type: array
+                    matchLabels:
+                      additionalProperties:
+                        type: string
+                      description: matchLabels is a map of {key,value} pairs. A single
+                        {key,value} in the matchLabels map is equivalent to an element
+                        of matchExpressions, whose key field is "key", the operator
+                        is "In", and the values array contains only "value". The requirements
+                        are ANDed.
+                      type: object
+                  type: object
+                metadata:
+                  properties:
+                    labels:
+                      additionalProperties:
+                        type: string
+                      type: object
+                  type: object
+                orderedResources:
+                  additionalProperties:
+                    type: string
+                  description: OrderedResources specifies the backup order of resources
+                    of specific Kind. The map key is the Kind name and value is a
+                    list of resource names separated by commas. Each resource name
+                    has format "namespace/resourcename".  For cluster resources, simply
+                    use "resourcename".
+                  nullable: true
+                  type: object
+                snapshotVolumes:
+                  description: SnapshotVolumes specifies whether to take cloud snapshots
+                    of any PV's referenced in the set of objects included in the Backup.
+                  nullable: true
+                  type: boolean
+                storageLocation:
+                  description: StorageLocation is a string containing the name of
+                    a BackupStorageLocation where the backup should be stored.
+                  type: string
+                ttl:
+                  description: TTL is a time.Duration-parseable string describing
+                    how long the Backup should be retained for.
+                  type: string
+                volumeSnapshotLocations:
+                  description: VolumeSnapshotLocations is a list containing names
+                    of VolumeSnapshotLocations associated with this backup.
+                  items:
+                    type: string
+                  type: array
+              type: object
+            useOwnerReferencesInBackup:
+              description: UseOwnerReferencesBackup specifies whether to use OwnerReferences
+                on backups created by this Schedule.
+              nullable: true
+              type: boolean
+          required:
+          - schedule
+          - template
+          type: object
+        status:
+          description: ScheduleStatus captures the current state of a Velero schedule
+          properties:
+            lastBackup:
+              description: LastBackup is the last time a Backup was run for this Schedule
+                schedule
+              format: date-time
+              nullable: true
+              type: string
+            phase:
+              description: Phase is the current phase of the Schedule
+              enum:
+              - New
+              - Enabled
+              - FailedValidation
+              type: string
+            validationErrors:
+              description: ValidationErrors is a slice of all validation errors (if
+                applicable)
+              items:
+                type: string
+              type: array
+          type: object
+      type: object
+  version: v1
+  versions:
+  - name: v1
+    served: true
+    storage: true
+status:
+  acceptedNames:
+    kind: ""
+    plural: ""
+  conditions: []
+  storedVersions: []

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

@@ -0,0 +1,89 @@
+
+---
+apiVersion: apiextensions.k8s.io/v1beta1
+kind: CustomResourceDefinition
+metadata:
+  annotations:
+    controller-gen.kubebuilder.io/version: v0.3.0
+  creationTimestamp: null
+  name: serverstatusrequests.velero.io
+spec:
+  group: velero.io
+  names:
+    kind: ServerStatusRequest
+    listKind: ServerStatusRequestList
+    plural: serverstatusrequests
+    shortNames:
+    - ssr
+    singular: serverstatusrequest
+  preserveUnknownFields: false
+  scope: Namespaced
+  subresources:
+    status: {}
+  validation:
+    openAPIV3Schema:
+      description: ServerStatusRequest is a request to access current status information
+        about the Velero server.
+      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: ServerStatusRequestSpec is the specification for a ServerStatusRequest.
+          type: object
+        status:
+          description: ServerStatusRequestStatus is the current status of a ServerStatusRequest.
+          properties:
+            phase:
+              description: Phase is the current lifecycle phase of the ServerStatusRequest.
+              enum:
+              - New
+              - Processed
+              type: string
+            plugins:
+              description: Plugins list information about the plugins running on the
+                Velero server
+              items:
+                description: PluginInfo contains attributes of a Velero plugin
+                properties:
+                  kind:
+                    type: string
+                  name:
+                    type: string
+                required:
+                - kind
+                - name
+                type: object
+              nullable: true
+              type: array
+            processedTimestamp:
+              description: ProcessedTimestamp is when the ServerStatusRequest was
+                processed by the ServerStatusRequestController.
+              format: date-time
+              nullable: true
+              type: string
+            serverVersion:
+              description: ServerVersion is the Velero server version.
+              type: string
+          type: object
+      type: object
+  version: v1
+  versions:
+  - name: v1
+    served: true
+    storage: true
+status:
+  acceptedNames:
+    kind: ""
+    plural: ""
+  conditions: []
+  storedVersions: []

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

@@ -0,0 +1,74 @@
+
+---
+apiVersion: apiextensions.k8s.io/v1beta1
+kind: CustomResourceDefinition
+metadata:
+  annotations:
+    controller-gen.kubebuilder.io/version: v0.3.0
+  creationTimestamp: null
+  name: volumesnapshotlocations.velero.io
+spec:
+  group: velero.io
+  names:
+    kind: VolumeSnapshotLocation
+    listKind: VolumeSnapshotLocationList
+    plural: volumesnapshotlocations
+    singular: volumesnapshotlocation
+  preserveUnknownFields: false
+  scope: Namespaced
+  validation:
+    openAPIV3Schema:
+      description: VolumeSnapshotLocation is a location where Velero stores volume
+        snapshots.
+      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: VolumeSnapshotLocationSpec defines the specification for a
+            Velero VolumeSnapshotLocation.
+          properties:
+            config:
+              additionalProperties:
+                type: string
+              description: Config is for provider-specific configuration fields.
+              type: object
+            provider:
+              description: Provider is the provider of the volume storage.
+              type: string
+          required:
+          - provider
+          type: object
+        status:
+          description: VolumeSnapshotLocationStatus describes the current status of
+            a Velero VolumeSnapshotLocation.
+          properties:
+            phase:
+              description: VolumeSnapshotLocationPhase is the lifecycle phase of a
+                Velero VolumeSnapshotLocation.
+              enum:
+              - Available
+              - Unavailable
+              type: string
+          type: object
+      type: object
+  version: v1
+  versions:
+  - name: v1
+    served: true
+    storage: true
+status:
+  acceptedNames:
+    kind: ""
+    plural: ""
+  conditions: []
+  storedVersions: []

config/crd/v1beta1/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/v1beta1/main.go

config/rbac/role.yaml

@@ -4,53 +4,8 @@ apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRole
 metadata:
   creationTimestamp: null
-  name: velero-perms
+  name: manager-role
 rules:
-- apiGroups:
-  - ""
-  resources:
-  - persistentvolumerclaims
-  verbs:
-  - get
-- apiGroups:
-  - ""
-  resources:
-  - persistentvolumes
-  verbs:
-  - get
-- apiGroups:
-  - ""
-  resources:
-  - pods
-  verbs:
-  - get
-- apiGroups:
-  - velero.io
-  resources:
-  - backuprepositories
-  verbs:
-  - create
-  - delete
-  - get
-  - list
-  - patch
-  - update
-  - watch
-- apiGroups:
-  - velero.io
-  resources:
-  - backuprepositories/status
-  verbs:
-  - get
-  - patch
-  - update
-- apiGroups:
-  - velero.io
-  resources:
-  - backups
-  verbs:
-  - create
-  - delete
 - apiGroups:
   - velero.io
   resources:
@@ -71,26 +26,6 @@ rules:
   - get
   - patch
   - update
-- apiGroups:
-  - velero.io
-  resources:
-  - deletebackuprequests
-  verbs:
-  - create
-  - delete
-  - get
-  - list
-  - patch
-  - update
-  - watch
-- apiGroups:
-  - velero.io
-  resources:
-  - deletebackuprequests/status
-  verbs:
-  - get
-  - patch
-  - update
 - apiGroups:
   - velero.io
   resources:
@@ -111,66 +46,6 @@ rules:
   - get
   - patch
   - update
-- apiGroups:
-  - velero.io
-  resources:
-  - podvolumebackups
-  verbs:
-  - create
-  - delete
-  - get
-  - list
-  - patch
-  - update
-  - watch
-- apiGroups:
-  - velero.io
-  resources:
-  - podvolumebackups/status
-  verbs:
-  - get
-  - patch
-  - update
-- apiGroups:
-  - velero.io
-  resources:
-  - podvolumerestores
-  verbs:
-  - create
-  - delete
-  - get
-  - list
-  - patch
-  - update
-  - watch
-- apiGroups:
-  - velero.io
-  resources:
-  - podvolumerestores/status
-  verbs:
-  - get
-  - patch
-  - update
-- apiGroups:
-  - velero.io
-  resources:
-  - schedules
-  verbs:
-  - create
-  - delete
-  - get
-  - list
-  - patch
-  - update
-  - watch
-- apiGroups:
-  - velero.io
-  resources:
-  - schedules/status
-  verbs:
-  - get
-  - patch
-  - update
 - apiGroups:
   - velero.io
   resources:
@@ -191,15 +66,3 @@ rules:
   - get
   - patch
   - update
-- apiGroups:
-  - velero.io
-  resources:
-  - volumesnapshotlocations
-  verbs:
-  - create
-  - delete
-  - get
-  - list
-  - patch
-  - update
-  - watch

design/2082-bsl-delete-associated-resources_design.md

@@ -1,40 +0,0 @@
-# Delete Backup and Restic Repo Resources when BSL is Deleted
-
-## Abstract
-
-Issue #2082 requested that with the command `velero backup-location delete <bsl name>` (implemented in Velero 1.6 with #3073), the following will be deleted:
-
-- associated Velero backups (to be clear, these are custom Kubernetes resources called "backups" that are stored in the API server)
-- associated Restic repositories (custom Kubernetes resources called "resticrepositories")
-
-This design doc explains how the request will be implemented.
-
-## Background
-
-When a BSL resource is deleted from its Velero namespace, the associated custom Kubernetes resources, backups and Restic repositories, can no longer be used.
-It makes sense to clean those resources up when a BSL is deleted.
-
-## Goals
-
-Update the `velero backup-location delete <bsl name>` command to delete associated backup and Restic repository resources in the same Velero namespace.
-
-## Non Goals
-
-[It was suggested](https://github.com/vmware-tanzu/velero/issues/2082#issuecomment-827951311) to fix bug #2697 alongside this issue.
-However, I think that should be fixed separately because although it is similar (restore objects are not being deleted), it is also quite different.
-One is adding a command feature update (this issue) and the other is a bug fix and each affect different parts of the code base.
-
-## High-Level Design
-
-Update the `velero backup-location delete <bsl name>` command to do the following:
-
-- find in the same Velero namespace from which the BSL was deleted the associated backup resources and Restic repositories, called "backups.velero.io" and "resticrepositories.velero.io" respectively
-- delete the resources found
-
-The above logic will be added to [where BSLs are deleted](https://github.com/vmware-tanzu/velero/blob/main/pkg/cmd/cli/backuplocation/delete.go).
-
-## Alternative Considered
-
-I had considered deleting the backup files (the ones in json format and tarballs) in the BSL itself.
-However, a standard use case is to back up a cluster and then restore into a new cluster.
-Deleting the backup storage location in either location is not expected to remove all of the backups in the backup storage location and should not be done.

design/CLI/PoC/base/CRDs.yaml

@@ -505,8 +505,6 @@ spec:
                       - BackupResourceList
                       - RestoreLog
                       - RestoreResults
-                      - CSIBackupVolumeSnapshots
-                      - CSIBackupVolumeSnapshotContents
                   type: string
                 name:
                   description: Name is the name of the kubernetes resource with

design/CLI/PoC/overlays/plugins/restic.yaml

@@ -5,22 +5,22 @@ metadata:
   creationTimestamp: null
   labels:
     component: velero
-  name: node-agent
+  name: restic
   namespace: velero
 spec:
   selector:
     matchLabels:
-      name: node-agent
+      name: restic
   template:
     metadata:
       creationTimestamp: null
       labels:
         component: velero
-        name: node-agent
+        name: restic
     spec:
       containers:
         - args:
-            - node-agent
+            - restic
             - server
           command:
             - /velero
@@ -43,7 +43,7 @@ spec:
               value: /credentials/cloud
           image: velero/velero:latest
           imagePullPolicy: Always
-          name: node-agent
+          name: restic
           resources: {}
           volumeMounts:
             - mountPath: /host_pods

design/Implemented/backup-resources-order.md

@@ -2,7 +2,7 @@
 This document proposes a solution that allows user to specify a backup order for resources of specific resource type.
 
 ## Background
-During backup process, user may need to back up resources of specific type in some specific order to ensure the resources were backup properly because these resources are related and ordering might be required to preserve the consistency for the apps to recover itself from the backup image 
+During backup process, user may need to back up resources of specific type in some specific order to ensure the resources were backup properly because these resources are related and ordering might be required to preserve the consistency for the apps to recover itself <EFBFBD>from the backup image 
 (Ex: primary-secondary database pods in a cluster).
 
 ## Goals
@@ -12,7 +12,7 @@ During backup process, user may need to back up resources of specific type in so
 - 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.
 
 ## High-Level Design
-User will specify a map of resource type to list resource names (separate by semicolons).  Each name will be in the format "namespaceName/resourceName" to enable ordering across namespaces.  Based on this map, the resources of each resource type will be sorted by the order specified in the list of resources.  If a resource instance belong to that specific type but its name is not in the order list, then it will be put behind other resources that are in the list.
+User will specify a map of resource type to list resource names (separate by semicolons).  Each name will be in the format "namespaceName/resourceName" to enable ordering accross namespaces.  Based on this map, the resources of each resource type will be sorted by the order specified in the list of resources.  If a resource instance belong to that specific type but its name is not in the order list, then it will be put behind other resources that are in the list.
 
 ### Changes to BackupSpec
 Add new field to BackupSpec
@@ -36,5 +36,5 @@ Example:
 >velero backup create mybackup --ordered-resources "pod=ns1/pod1,ns1/pod2;persistentvolumeclaim=n2/slavepod,ns2/primarypod"
 
 ## Open Issues
-- In the CLI, the design proposes to use commas to separate items of a resource type and semicolon to separate key-value pairs.  This follows the convention of using commas to separate items in a list (For example: --include-namespaces ns1,ns2).  However, the syntax for map in labels and annotations use commas to separate key-value pairs.  So it introduces some inconsistency.
+- In the CLI, the design proposes to use commas to separate items of a resource type and semicolon to separate key-value pairs.  This follows the convention of using commas to separate items in a list (For example: --include-namespaces ns1,ns2).  However, the syntax for map in labels and annotations use commas to seperate key-value pairs.  So it introduces some inconsistency.
 - For pods that managed by Deployment or DaemonSet, this design may not work because the pods' name is randomly generated and if pods are restarted, they would have different names so the Backup operation may not consider the restarted pods in the sorting algorithm.  This problem will be addressed when we enhance the design to use regular expression to specify the OrderResources instead of exact match. 

design/Implemented/generating-velero-crds-with-structural-schema.md

@@ -28,7 +28,7 @@ This document proposes adding _controller-tools_ to the project to automatically
 _controller-tools_ works by reading the Go files that contain the API type definitions.
 It uses a combination of the struct fields, types, tags and comments to build the OpenAPIv3 schema for the CRDs. The tooling makes some assumptions based on conventions followed in upstream Kubernetes and the ecosystem, which involves some changes to the Velero API type definitions, especially around optional fields.
 
-In order for _controller-tools_ to read the Go files containing Velero API type definitions, the CRDs need to be generated at build time, as these files are not available at runtime (i.e. the Go files are not accessible by the compiled binary).
+In order for _controller-tools_ to read the Go files containing Velero API type defintiions, the CRDs need to be generated at build time, as these files are not available at runtime (i.e. the Go files are not accessible by the compiled binary).
 These generated CRD manifests (YAML) will then need to be available to the `pkg/install` package for it to include when installing Velero resources.
 
 ## Detailed Design

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

@@ -429,7 +429,7 @@ Instead, a new method for 'Progress' will be added to interface. Velero server r
 
 But, this involves good amount of changes and needs a way for backward compatibility.
 
-As volume plugins are mostly K8s native, its fine to go ahead with current limitation.
+As volume plugins are mostly K8s native, its fine to go ahead with current limiation.
 
 ### Update Backup CR
 Instead of creating new CRs, plugins can directly update the status of Backup CR. But, this deviates from current approach of having separate CRs like PodVolumeBackup/PodVolumeRestore to know operations progress.

design/existing-resource-policy_design.md

@@ -1,262 +0,0 @@
-# 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.
-
-## 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):
-- Velero tries to attempt restore of the `service` 
-- Fetches the `service` from the cluster 
-- If the `service` exists then:
-    - Checks whether the `service` instance in the cluster is equal to the `service`  instance present in backup
-        - If not equal then skips the restore of the `service` and adds a restore warning (except for [ServiceAccount objects](https://github.com/vmware-tanzu/velero/blob/574baeb3c920f97b47985ec3957debdc70bcd5f8/pkg/restore/restore.go#L1246))
-        - If equal then skips the restore of the `service` and mentions that the restore of resource `service` is skipped in logs
-
-It is desired to add the functionality to specify whether or not to overwrite the instance of resource `service` in cluster with the one present in backup during the restore process.
-
-Related issue: https://github.com/vmware-tanzu/velero/issues/4066
-
-## Goals
-- Add support for `ExistingResourcePolicy` to restore API for Kubernetes resources.
-
-## Non Goals
-- Change existing restore workflow for `ServiceAccount` objects
-- Add support for `ExistingResourcePolicy` as `recreate` for Kubernetes resources. (Future scope feature)
-
-## Unrelated Proposals (Completely different functionalities than the one proposed in the design)
-- Add support for `ExistingResourcePolicy` to restore API for Non-Kubernetes resources.
-- Add support for `ExistingResourcePolicy` to restore API for `PersistentVolume` data.
-
-### Use-cases/Scenarios
-
-### A. Production Cluster - Backup Cluster:
-Let's say you have a Backup Cluster which is identical to the Production Cluster. After some operations/usage/time the Production Cluster had changed itself, there might be new deployments, some secrets might have been updated. Now, this means that the Backup cluster will no longer be identical to the Production Cluster. In order to keep the Backup Cluster up to date/identical to the Production Cluster with respect to Kubernetes resources except PV data we would like to use Velero for scheduling new backups which would in turn help us update the Backup Cluster via Velero restore.
-
-Reference: https://github.com/vmware-tanzu/velero/issues/4066#issuecomment-954320686
-
-### B. Help identify resource delta:
-Here delta resources mean the resources restored by a previous backup, but they are no longer in the latest backup. Let's follow a sequence of steps to understand this scenario:
-- Consider there are 2 clusters, Cluster A, which has 3 resources - P1, P2 and P3.
-- Create a Backup1 from Cluster A which has P1, P2 and P3.
-- Perform restore on a new Cluster B using Backup1.
-- Now, Lets say in Cluster A resource P1 gets deleted and resource P2 gets updated.
-- Create a new Backup2 with the new state of Cluster A, keep in mind Backup1 has P1, P2 and P3 while Backup2 has P2' and P3.
-- So the Delta here is (|Cluster B - Backup2|), Delete P1 and Update P2.
-- During Restore time we would want the Restore to help us identify this resource delta.
-
-Reference: https://github.com/vmware-tanzu/velero/pull/4613#issuecomment-1027260446
-
-## High-Level Design
-### Approach 1: Add a new spec field `existingResourcePolicy` to the Restore API
-In this approach we do *not* change existing velero behavior. If the resource to restore in cluster is equal to the one backed up then do nothing following current Velero behavior. For resources that already exist in the cluster that are not equal to the resource in the backup (other than Service Accounts). We add a new optional spec field `existingResourcePolicy` which can have the following values:
-1. `none`: This is the existing behavior, if Velero encounters a resource that already exists in the cluster, we simply
-skip restoration.
-2. `update`: This option would provide the following behavior.
-   - Unchanged resources: Velero would update the backup/restore labels on the unchanged resources, if labels patch fails Velero adds a restore error.
-   - Changed resources: Velero will first try to patch the changed resource, Now if the patch:
-       - succeeds: Then the in-cluster resource gets updated with the labels as well as the resource diff
-       - fails: Velero adds a restore warning and tries to just update the backup/restore labels on the resource, if the labels patch also fails then we add restore error.
-3. `recreate`:  If resource already exists, then Velero will delete it and recreate the resource.
-
-*Note:* The `recreate` option is a non-goal for this enhancement proposal, but it is considered as a future scope.
-Another thing to highlight is that Velero will not be deleting any resources in any of the policy options proposed in 
-this design but Velero will patch the resources in `update` policy option.
-
-Example:
-A. The following Restore will execute the `existingResourcePolicy` restore type `none` for the `services` and `deployments` present in the `velero-protection` namespace.
-
-```
-Kind: Restore
-
-…
-
-includeNamespaces: velero-protection
-includeResources:
-  - services
-  - deployments
-existingResourcePolicy: none
-
-```
-
-B. The following Restore will execute the `existingResourcePolicy` restore type `update` for the `secrets` and `daemonsets` present in the `gdpr-application` namespace.
-```
-Kind: Restore
-
-…
-includeNamespaces: gdpr-application
-includeResources:
-  - secrets
-  - daemonsets
-existingResourcePolicy: update
-```
-
-### Approach 2: Add a new spec field `existingResourcePolicyConfig` to the Restore API
-In this approach we give user the ability to specify which resources are to be included for a particular kind of force update behaviour, essentially a more granular approach where in the user is able to specify a resource:behaviour mapping. It would look like:
-`existingResourcePolicyConfig`:
-- `patch:` 
-    - `includedResources:` [ ]string
-- `recreate:`
-    - `includedResources:` [ ]string
-
-*Note:* 
-- There is no `none` behaviour in this approach as that would conform to the current/default Velero restore behaviour.
-- The `recreate` option is a non-goal for this enhancement proposal, but it is considered as a future scope.
-
-
-Example:
-A. The following Restore will execute the restore type `patch` and apply the `existingResourcePolicyConfig` for `secrets` and `daemonsets` present in the `inventory-app` namespace.
-```
-Kind: Restore
-…
-includeNamespaces: inventory-app
-existingResourcePolicyConfig:
-  patch:
-    includedResources
-     - secrets
-     - daemonsets
-
-```
-
-
-### Approach 3: Combination of Approach 1 and Approach 2
-
-Now, this approach is somewhat a combination of the aforementioned approaches. Here we propose addition of two spec fields to the Restore API - `existingResourceDefaultPolicy` and `existingResourcePolicyOverrides`. As the names suggest ,the idea being that `existingResourceDefaultPolicy` would describe the default velero behaviour for this restore and `existingResourcePolicyOverrides` would override the default policy explicitly for some resources.
-
-Example:
-A. The following Restore will execute the restore type `patch` as the `existingResourceDefaultPolicy` but will override the default policy for `secrets` using the `existingResourcePolicyOverrides` spec as `none`.
-```
-Kind: Restore
-…
-includeNamespaces: inventory-app
-existingResourceDefaultPolicy: patch
-existingResourcePolicyOverrides:
-  none:
-    includedResources
-     - secrets
-
-```
-
-## Detailed Design
-### Approach 1: Add a new spec field `existingResourcePolicy` to the Restore API
-The `existingResourcePolicy` spec field will be an `PolicyType` type field. 
-
-Restore API:
-```
-type RestoreSpec struct {
-.
-.
-.
-// ExistingResourcePolicy specifies the restore behaviour for the kubernetes resource to be restored
-// +optional
-ExistingResourcePolicy PolicyType
-
-}
-```
-PolicyType:
-```
-type PolicyType string
-const PolicyTypeNone PolicyType  = "none"
-const PolicyTypePatch PolicyType = "update"
-```
-
-### Approach 2: Add a new spec field `existingResourcePolicyConfig` to the Restore API
-The `existingResourcePolicyConfig` will be a spec of type `PolicyConfiguration` which gets added to the Restore API.
-
-Restore API:
-```
-type RestoreSpec struct {
-.
-.
-.
-// ExistingResourcePolicyConfig specifies the restore behaviour for a particular/list of kubernetes resource(s) to be restored
-// +optional
-ExistingResourcePolicyConfig []PolicyConfiguration
-
-}
-```
-
-PolicyConfiguration:
-```
-type PolicyConfiguration struct {
-
-PolicyTypeMapping map[PolicyType]ResourceList
-
-}
-```
-
-PolicyType:
-```
-type PolicyType string
-const PolicyTypePatch PolicyType = "patch"
-const PolicyTypeRecreate PolicyType = "recreate"
-```
-
-ResourceList:
-```
-type ResourceList struct {
-IncludedResources []string 
-}
-```
-
-### Approach 3: Combination of Approach 1 and Approach 2
-
-Restore API:
-```
-type RestoreSpec struct {
-.
-.
-.
-// 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
-// +optional
-existingResourcePolicyOverrides []PolicyConfiguration
-
-}
-```
-
-PolicyType:
-```
-type PolicyType string
-const PolicyTypeNone PolicyType  = "none"
-const PolicyTypePatch PolicyType = "patch"
-const PolicyTypeRecreate PolicyType = "recreate"
-```
-PolicyConfiguration:
-```
-type PolicyConfiguration struct {
-
-PolicyTypeMapping map[PolicyType]ResourceList
-
-}
-```
-ResourceList:
-```
-type ResourceList struct {
-IncludedResources []string 
-}
-```
-
-The restore workflow changes will be done [here](https://github.com/vmware-tanzu/velero/blob/b40bbda2d62af2f35d1406b9af4d387d4b396839/pkg/restore/restore.go#L1245)
-
-### CLI changes for Approach 1
-We would introduce a new CLI flag called `existing-resource-policy` of string type. This flag would be used to accept the 
-policy from the user. The velero restore command would look somewhat like this:
-```
-velero create restore <restore_name> --existing-resource-policy=update 
-```
-
-Help message `Restore Policy to be used during the restore workflow, can be - none, update`
-
-The CLI changes will go at `pkg/cmd/cli/restore/create.go`
-
-We would also add a validation which checks for invalid policy values provided to this flag.
-
-Restore describer will also be updated to reflect the policy `pkg/cmd/util/output/restore_describer.go`
-
-### Implementation Decision
-We have decided to go ahead with the implementation of Approach 1 as:
-- It is easier to implement 
-- It is also easier to scale and leaves room for improvement and the door open to expanding to approach 3
-- It also provides an option to preserve the existing velero restore workflow

design/multiple-label-selectors_design.md

@@ -1,138 +0,0 @@
-# Ensure support for backing up resources based on multiple labels
-## Abstract
-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.
-
-## Background
-Currently, Velero's Backup/Restore API has a spec field `LabelSelector` which helps in filtering of resources based on
-a **single** label value per backup/restore request. For instance, if the user specifies the `Backup.Spec.LabelSelector` as
-`data-protection-app: true`, Velero will grab all the resources that possess this label and perform the backup
-operation on them. The `LabelSelector` field does not accept more than one labels, and thus if the user want to take
-backup for resources consisting of a label from a set of labels (label1 OR label2 OR label3) then the user needs to
-create multiple backups per label rule. It would be really useful if Velero Backup API could respect a set of
-labels (OR Rule) for a single backup request.
-
-Related Issue: https://github.com/vmware-tanzu/velero/issues/1508
-
-## Goals
-- Enable support for backing up resources based on multiple labels (OR Logic) in a single backup config.
-- Enable support for restoring resources based on multiple labels (OR Logic) in a single restore config.
-
-## Use Case/Scenario
-Let's say as a Velero user you want to take a backup of secrets, but all these secrets do not have one single consistent
-label on them. We want to take backup of secrets having any one label in `app=gdpr`, `app=wpa` and `app=ccpa`. Here
-we would have to create 3 instances of backup for each label rule. This can become cumbersome at scale.
-
-## High-Level Design
-### Addition of `OrLabelSelectors` spec to Velero Backup/Restore API
-For Velero to back up resources if they consist of any one label from a set of labels, we would like to add a new spec
-field `OrLabelSelectors` which would enable user to specify them. The Velero backup would somewhat look like:
-
-```
-apiVersion: velero.io/v1
-kind: Backup
-metadata:
-  name: backup-101
-  namespace: openshift-adp
-spec:
-  includedNamespaces:
-  - test
-  storageLocation: velero-sample-1
-  ttl: 720h0m0s
-  orLabelSelectors:
-  - matchLabels:
-      app=gdpr
-  - matchLabels:
-      app=wpa
-  - matchLabels:
-      app=ccpa
-```
-
-**Note:** This approach will **not** be changing any current behavior related to Backup API spec `LabelSelector`. Rather we
-propose that the label in `LabelSelector` spec and labels in `OrLabelSelectors` should be treated as different Velero functionalities.
-Both these fields will be treated as separate Velero Backup API specs. If `LabelSelector` (singular) is present then just match that label.
-And if `OrLabelSelectors` is present then match to any label in the set specified by the user. For backup case, if both the `LabelSelector` and `OrLabelSelectors` 
-are specified (we do not anticipate this as a real world use-case) then the `OrLabelSelectors` will take precedence, `LabelSelector` will
-only be used to filter only when `OrLabelSelectors` is not specified by the user. This helps to keep both spec behaviour independent and not confuse the users. 
-This way we preserve the existing Velero behaviour and implement the new functionality in a much cleaner way.
-For instance, let's take a look the following cases:
-
-1. Only `LabelSelector` specified: Velero will create a backup with resources matching label `app=protect-db`
-```
-apiVersion: velero.io/v1
-kind: Backup
-metadata:
-  name: backup-101
-  namespace: openshift-adp
-spec:
-  includedNamespaces:
-  - test
-  storageLocation: velero-sample-1
-  ttl: 720h0m0s
-  labelSelector:
-  - matchLabels:
-      app=gdpr
-```
-2. Only `OrLabelSelectors` specified: Velero will create a backup with resources matching any label from set `{app=gdpr, app=wpa, app=ccpa}`
-```
-apiVersion: velero.io/v1
-kind: Backup
-metadata:
-  name: backup-101
-  namespace: openshift-adp
-spec:
-  includedNamespaces:
-  - test
-  storageLocation: velero-sample-1
-  ttl: 720h0m0s
-  orLabelSelectors:
-  - matchLabels:
-      app=gdpr
-  - matchLabels:
-      app=wpa
-  - matchLabels:
-      app=ccpa
-```
-
-Similar implementation will be done for the Restore API as well.
-
-## Detailed Design
-With the Introduction of `OrLabelSelectors` the BackupSpec and RestoreSpec will look like:
-
-BackupSpec:
-```
-type BackupSpec struct {
-[...]
-// OrLabelSelectors is a set of []metav1.LabelSelector to filter with
-// when adding individual objects to the backup. Resources matching any one
-// label from the set of labels will be added to the backup. If empty
-// or nil, all objects are included. Optional.
-// +optional
-OrLabelSelectors []\*metav1.LabelSelector
-[...]
-}
-```
-
-RestoreSpec:
-```
-type RestoreSpec struct {
-[...]
-// OrLabelSelectors is a set of []metav1.LabelSelector to filter with
-// when restoring objects from the backup. Resources matching any one
-// label from the set of labels will be restored from the backup. If empty
-// or nil, all objects are included from the backup. Optional.
-// +optional
-OrLabelSelectors []\*metav1.LabelSelector
-[...]
-}
-```
-
-The logic to collect resources to be backed up for a particular backup will be updated in the `backup/item_collector.go`
-around [here](https://github.com/vmware-tanzu/velero/blob/574baeb3c920f97b47985ec3957debdc70bcd5f8/pkg/backup/item_collector.go#L294).
-
-And for filtering the resources to be restored, the changes will go [here](https://github.com/vmware-tanzu/velero/blob/d1063bda7e513150fd9ae09c3c3c8b1115cb1965/pkg/restore/restore.go#L1769)
-
-**Note:**
-- This feature will not be exposed via Velero CLI.

design/new-prepost-backuprestore-plugin-hooks.md

@@ -1,735 +0,0 @@
-# Pre-Backup, Post-Backup, Pre-Restore, and Post-Restore Action Plugin Hooks
-
-## Abstract
-
-Velero should provide a way to trigger actions before and after each backup and restore.
-**Important**: These proposed plugin hooks are fundamentally different from the existing plugin hooks, BackupItemAction and RestoreItemAction, which are triggered per resource item during backup and restore, respectively.
-The proposed plugin hooks are to be executed only once: pre-backup (before backup starts), post-backup (after the backup is completed and uploaded to object storage, including volumes snapshots), pre-restore (before restore starts) and post-restore (after the restore is completed, including volumes are restored).
-
-### PreBackup and PostBackup Actions
-
-For the backup,  the sequence of events of Velero backup are the following (these sequence depicted is prior upcoming changes for [upload progress #3533](https://github.com/vmware-tanzu/velero/issues/3533) ):
-
-```
-New Backup Request
- |--> Validation of the request
-       |--> Set Backup Phase "In Progress"
-            | --> Start Backup
-                  | --> Discover all Plugins
-                        |--> Check if Backup Exists
-                             |--> Backup all K8s Resource Items
-                                  |--> Perform all Volumes Snapshots
-                                       |--> Final Backup Phase is determined
-                                            |--> Persist Backup and Logs on Object Storage
-```
-We propose the pre-backup and post-backup plugin hooks to be executed in this sequence:
-
-```
-New Backup Request
- |--> Validation of the request
-       |--> Set Backup Phase "In Progress"
-            | --> Start Backup
-                  | --> Discover all Plugins
-                        |--> Check if Backup Exists
-                             |--> **PreBackupActions** are executed, logging actions on existent backup log file
-                                   |--> Backup all K8s Resource Items
-                                        |--> Perform all Volumes Snapshots
-                                            |--> Final Backup Phase is determined
-                                                 |--> Persist Backup and logs on Object Storage
-                                                    |--> **PostBackupActions** are executed, logging to its own file
-```
-These plugin hooks will be invoked:
-
-- PreBackupAction: plugin actions are executed after the backup object is created and validated but before the backup is being processed, more precisely _before_ function [c.backupper.Backup](https://github.com/vmware-tanzu/velero/blob/74476db9d791fa91bba0147eac8ec189820adb3d/pkg/controller/backup_controller.go#L590). If the PreBackupActions return an err, the backup object is not processed and the Backup phase will be set as `FailedPreBackupActions`.
-
-- PostBackupAction: plugin actions are executed after the backup is finished and persisted, more precisely _after_ function [c.runBackup](https://github.com/vmware-tanzu/velero/blob/74476db9d791fa91bba0147eac8ec189820adb3d/pkg/controller/backup_controller.go#L274).
-
-The proposed plugin hooks will execute actions that will have statuses on their own:
-`Backup.Status.PreBackupActionsStatuses` and `Backup.Status.PostBackupActionsStatuses` which will be an array of a proposed struct `ActionStatus` with PluginName, StartTimestamp, CompletionTimestamp and Phase.
-
-### PreRestore and PostRestore Actions
-
-For the restore,  the sequence of events of Velero restore are the following (these sequence depicted is prior upcoming changes for [upload progress #3533](https://github.com/vmware-tanzu/velero/issues/3533) ):
-```
-New Restore Request
- |--> Validation of the request
-      |--> Checks if restore is from a backup or a schedule
-           |--> Fetches backup
-                |--> Set Restore Phase "In Progress"
-                     |--> Start Restore
-                          |--> Discover all Plugins
-                               |--> Download backup file to temp
-                                    |--> Fetch list of volumes snapshots
-                                         |--> Restore K8s items, including PVs
-                                              |--> Final Restore Phase is determined
-                                                   |--> Persist Restore logs on Object Storage
-```
-We propose the pre-restore and post-restore plugin hooks to be executed in this sequence:
-```
-New Restore Request
- |--> Validation of the request
-      |--> Checks if restore is from a backup or a schedule
-           |--> Fetches backup
-                |--> Set Restore Phase "In Progress"
-                     |--> Start Restore
-                          |--> Discover all Plugins
-                                |--> Download backup file to temp
-                                         |--> Fetch list of volumes snapshots
-                                            |--> **PreRestoreActions** are executed, logging actions on existent backup log file
-                                              |--> Restore K8s items, including PVs
-                                                   |--> Final Restore Phase is determined
-                                                        |--> Persist Restore logs on Object Storage
-                                                            |--> **PostRestoreActions** are executed, logging to its own file
-```
-
-These plugin hooks will be invoked:
-
-- PreRestoreAction: plugin actions are executed after the restore object is created and validated and before the backup object is fetched, more precisely in function `runValidatedRestore` _after_ function [info.backupStore.GetBackupVolumeSnapshots](https://github.com/vmware-tanzu/velero/blob/7c75cd6cf854064c9a454e53ba22cc5881d3f1f0/pkg/controller/restore_controller.go#L460). If the PreRestoreActions return an err, the restore object is not processed and the Restore phase will be set a `FailedPreRestoreActions`.
-  
-- PostRestoreAction: plugin actions are executed after the restore finishes processing all items and volumes snapshots are restored and logs persisted, more precisely in function `processRestore` _after_ setting [`restore.Status.CompletionTimestamp`](https://github.com/vmware-tanzu/velero/blob/7c75cd6cf854064c9a454e53ba22cc5881d3f1f0/pkg/controller/restore_controller.go#L273).
-
-The proposed plugin hooks will execute actions that will have statuses on their own:
-`Restore.Status.PreRestoreActionsStatuses` and `Restore.Status.PostRestoreActionsStatuses` which will be an array of a proposed struct `ActionStatus` with PluginName, StartTimestamp, CompletionTimestamp and Phase.
-
-## Background
-
-Increasingly, Velero is employed for workload migrations across different Kubernetes clusters.
-Using Velero for migrations requires an atomic operation involving a Velero backup on a source cluster followed by a Velero restore on a destination cluster.
-
-It is common during these migrations to perform many actions inside and outside Kubernetes clusters.
-**Attention**: these actions are not per resource item, but they are actions to be executed _once_ before and/or after the migration itself (remember, migration in this context is Velero Backup + Velero Restore).
-
-One important use case driving this proposal is migrating stateful workloads at scale across different clusters/storage backends.
-Today, Velero's Restic integration is the response for such use cases, but there are some limitations:
-
-- Quiesce/unquiesce workloads: Pod hooks are useful for quiescing/unquiescing workloads, but platform engineers often do not have the luxury/visibility/time/knowledge to go through each pod in order to add specific commands to quiesce/unquiesce workloads.
-- Orphan PVC/PV pairs: PVCs/PVs that do not have associated running pods are not backed up and consequently, are not migrated.
-
-Aiming to address these two limitations, and separate from this proposal, we would like to write a Velero plugin that takes advantage of the proposed Pre-Backup plugin hook. This plugin will be executed _once_ (not per resource item) prior backup. It will scale down the applications setting `.spec.replicas=0` to all deployments, statefulsets, daemonsets, replicasets, etc. and will start a small-footprint staging pod that will mount all PVC/PV pairs. Similarly, we would like to write another plugin that will utilize the proposed Post-Restore plugin hook. This plugin will unquiesce migrated applications by killing the staging pod and reinstating original `.spec.replicas` values after the Velero restore is completed.
-
-Other examples of plugins that can use the proposed plugin hooks are:
-
-- PostBackupAction: trigger a Velero Restore after a successful Velero backup (and complete the migration operation).
-- PreRestoreAction: pre-expand the cluster's capacity via Cluster API to avoid starvation of cluster resources before the restore.
-- PostRestoreAction: call actions to be performed outside Kubernetes clusters, such as configure a global load balancer (GLB) that enables the new cluster.
-
-The post backup actions will be executed after the backup is uploaded (persisted) on the disk. The logs of post-backup actions will be uploaded on the disk once the actions are completed.
-
-The post restore actions will be executed after the restore is uploaded (persisted) on the disk. The logs of post-restore actions will be uploaded on the disk once the actions are completed.
-
-This design seeks to provide missing extension points. This proposal's scope is to only add the new plugin hooks, not the plugins themselves.
-
-## Goals
-
-- Provide PreBackupAction, PostBackupAction, PreRestoreAction, and PostRestoreAction APIs for plugins to implement.
-- Update Velero backup and restore creation logic to invoke registered PreBackupAction and PreRestoreAction plugins before processing the backup and restore respectively.
-- Update Velero backup and restore complete logic to invoke registered PostBackupAction and PostRestoreAction plugins the objects are uploaded on disk.
-- Create one `ActionStatus` struct to keep track of execution of the plugin hooks. This struct has PluginName, StartTimestamp, CompletionTimestamp and Phase.
-- Add sub statuses for the plugins on Backup object: `Backup.Status.PreBackupActionsStatuses` and `Backup.Status.PostBackupActionsStatuses`. They will be flagged as optional and nullable. They will be populated only each plugin registered for the PreBackup and PostBackup hooks, respectively.
-- Add sub statuses for the plugins on Restore object: `Backup.Status.PreRestoreActionsStatuses` and `Backup.Status.PostRestoreActionsStatuses`. They will be flagged as optional and nullable. They will be populated only each plugin registered for the PreRestore and PostRestore hooks, respectively.
-- that will be populated optionally if Pre/Post Backup/Restore.
-
-## Non-Goals
-
-- Specific implementations of the PreBackupAction, PostBackupAction, PreRestoreAction and PostRestoreAction API beyond test cases.
-- For migration specific actions (Velero Backup + Velero Restore), add disk synchronization during the validation of the Restore (making sure the newly created backup will show during restore)
-
-## High-Level Design
-
-The Velero backup controller package will be modified for `PreBackupAction` and `PostBackupAction`.
-
-The PreBackupAction plugin API will resemble the BackupItemAction plugin hook design, but with the fundamental difference that it will receive only as input the Velero `Backup` object created.
-It will not receive any resource list items because the backup is not yet running at that stage.
-In addition, the `PreBackupAction` interface will only have an `Execute()` method since the plugin will be executed once per Backup creation, not per item.
-
-The Velero backup controller will be modified so that if there are any PreBackupAction plugins registered, they will be
-
-The PostBackupAction plugin API will resemble the BackupItemAction plugin design, but with the fundamental difference that it will receive only as input the Velero `Backup` object without any resource list items.
-By this stage, the backup has already been executed, with items backed up and volumes snapshots processed and persisted.
-The `PostBackupAction` interface will only have an `Execute()` method since the plugin will be executed only once per Backup, not per item.
-
-If there are any PostBackupAction plugins registered, they will be executed after the backup is finished and persisted, more precisely _after_ function [c.runBackup](https://github.com/vmware-tanzu/velero/blob/74476db9d791fa91bba0147eac8ec189820adb3d/pkg/controller/backup_controller.go#L274).
-
-The Velero restore controller package will be modified for `PreRestoreAction` and `PostRestoreAction`.
-
-The PreRestoreAction plugin API will resemble the RestoreItemAction plugin design, but with the fundamental difference that it will receive only as input the Velero `Restore` object created.
-It will not receive any resource list items because the restore has not yet been running at that stage.
-In addition, the `PreRestoreAction` interface will only have an `Execute()` method since the plugin will be executed only once per Restore creation, not per item.
-
-The Velero restore controller will be modified so that if there are any PreRestoreAction plugins registered, they will be executed after the restore object is created and validated and before the backup object is fetched, more precisely in function `runValidatedRestore` _after_ function [info.backupStore.GetBackupVolumeSnapshots](https://github.com/vmware-tanzu/velero/blob/7c75cd6cf854064c9a454e53ba22cc5881d3f1f0/pkg/controller/restore_controller.go#L460). If the PreRestoreActions return an err, the restore object is not processed and the Restore phase will be set a `FailedPreRestoreActions`.
-
-The PostRestoreAction plugin API will resemble the RestoreItemAction plugin design, but with the fundamental difference that it will receive only as input the Velero `Restore` object without any resource list items.
-At this stage, the restore has already been executed.
-The `PostRestoreAction` interface will only have an `Execute()` method since the plugin will be executed only once per Restore, not per item.
-
-If any PostRestoreAction plugins are registered, they will be executed after the restore finishes processing all items and volumes snapshots are restored and logs persisted, more precisely in function `processRestore` _after_ setting [`restore.Status.CompletionTimestamp`](https://github.com/vmware-tanzu/velero/blob/7c75cd6cf854064c9a454e53ba22cc5881d3f1f0/pkg/controller/restore_controller.go#L273).
-
-## Detailed Design
-
-### New Status struct
-
-To keep the status of the plugins, we propose the following struct:
-
-```go
-type ActionStatus struct {
-    // PluginName is the name of the registered plugin
-    // retrieved by the PluginManager as id.Name
-    // +optional
-    // +nullable
-    PluginName string `json:"pluginName,omitempty"`
-
-    // StartTimestamp records the time the plugin started.
-    // +optional
-    // +nullable
-    StartTimestamp *metav1.Time `json:"startTimestamp,omitempty"`
-
-    // CompletionTimestamp records the time the plugin was completed.
-    // +optional
-    // +nullable
-    CompletionTimestamp *metav1.Time `json:"completionTimestamp,omitempty"`
-
-    // Phase is the current state of the Action.
-    // +optional
-    // +nullable
-    Phase ActionPhase `json:"phase,omitempty"`
-}
-
-// ActionPhase is a string representation of the lifecycle phase of an action being executed by a plugin
-// of a Velero backup.
-// +kubebuilder:validation:Enum=InProgress;Completed;Failed
-type ActionPhase string
-
-const (
-    // ActionPhaseInProgress means the action has being executed
-    ActionPhaseInProgress ActionPhase = "InProgress"
-
-    // ActionPhaseCompleted means the action finished successfully
-    ActionPhaseCompleted ActionPhase = "Completed"
-
-    // ActionPhaseFailed means the action failed
-    ActionPhaseFailed ActionPhase = "Failed"
-)
-
-```
-
-### Backup Status of the Plugins
-
-The `Backup` Status section will have the follow:
-
-```go
-type BackupStatus struct {
-    (...)
-    // PreBackupActionsStatuses contains information about the pre backup plugins's execution.
-    // Note that this information is will be only populated if there are prebackup plugins actions
-    // registered
-    // +optional
-    // +nullable
-    PreBackupActionsStatuses *[]ActionStatus `json:"preBackupActionsStatuses,omitempty"`
-
-    // PostBackupActionsStatuses contains information about the post backup plugins's execution.
-    // Note that this information is will be only populated if there are postbackup plugins actions
-    // registered
-    // +optional
-    // +nullable
-    PostBackupActionsStatuses *[]ActionStatus `json:"postBackupActionsStatuses,omitempty"`
-
-}
-```
-
-### Restore Status of the Plugins
-
-The `Restore` Status section will have the follow:
-
-```go
-type RestoreStatus struct {
-    (...)
-    // PreRestoreActionsStatuses contains information about the pre Restore plugins's execution.
-    // Note that this information is will be only populated if there are preRestore plugins actions
-    // registered
-    // +optional
-    // +nullable
-    PreRestoreActionsStatuses *[]ActionStatus `json:"preRestoreActionsStatuses,omitempty"`
-
-    // PostRestoreActionsStatuses contains information about the post restore plugins's execution.
-    // Note that this information is will be only populated if there are postrestore plugins actions
-    // registered
-    // +optional
-    // +nullable
-    PostRestoreActionsStatuses *[]ActionStatus `json:"postRestoreActionsStatuses,omitempty"`
-
-}
-```
-
-### New Backup and Restore Phases
-
-#### New Backup Phase: FailedPreBackupActions
-
-In case the PreBackupActionsStatuses has at least one `ActionPhase` = `Failed`, it means al least one of the plugins returned an error and consequently, the backup will not move forward. The final status of the Backup object will be set as `FailedPreBackupActions`:
-
-```go
-
-// BackupPhase is a string representation of the lifecycle phase
-// of a Velero backup.
-// +kubebuilder:validation:Enum=New;FailedValidation;FailedPreBackupActions;InProgress;Uploading;UploadingPartialFailure;Completed;PartiallyFailed;Failed;Deleting
-type BackupPhase string
-
-const (
-
-    (...)
-
-    // BackupPhaseFailedPreBackupActions means one or more the Pre Backup Actions has failed
-    // and therefore backup will not run.
-    BackupPhaseFailedPreBackupActions BackupPhase = "FailedPreBackupActions"
-
-    (...)
-)
-
-```
-
-#### New Restore Phase FailedPreRestoreActions
-
-In case the PreRestoreActionsStatuses has at least one `ActionPhase` = `Failed`, it means al least one of the plugins returned an error and consequently, the restore will not move forward. The final status of the Restore object will be set as `FailedPreRestoreActions`:
-
-```go
-
-// RestorePhase is a string representation of the lifecycle phase
-// of a Velero restore
-// +kubebuilder:validation:Enum=New;FailedValidation;FailedPreRestoreActions;InProgress;Completed;PartiallyFailed;Failed
-type RestorePhase string
-
-const (
-
-    (...)
-
-    // RestorePhaseFailedPreRestoreActions means one or more the Pre Restore Actions has failed
-    // and therefore restore will not run.
-    RestorePhaseFailedPreRestoreActions BackupPhase = "FailedPreRestoreActions"
-
-    (...)
-)
-
-```
-
-### New Interface types
-
-#### PreBackupAction
-
-The `PreBackupAction` interface is as follows:
-
-```go
-// PreBackupAction provides a hook into the backup process before it begins.
-type PreBackupAction interface {
-    // Execute the PreBackupAction plugin providing it access to the Backup that
-    // is being executed
-    Execute(backup *api.Backup) error
-}
-```
-
-`PreBackupAction` will be defined in `pkg/plugin/velero/pre_backup_action.go`.
-
-#### PostBackupAction
-
-The `PostBackupAction` interface is as follows:
-
-```go
-// PostBackupAction provides a hook into the backup process after it completes.
-type PostBackupAction interface {
-    // Execute the PostBackupAction plugin providing it access to the Backup that
-    // has been completed
-    Execute(backup *api.Backup) error
-}
-```
-
-`PostBackupAction` will be defined in `pkg/plugin/velero/post_backup_action.go`.
-
-#### PreRestoreAction
-
-The `PreRestoreAction` interface is as follows:
-
-```go
-// PreRestoreAction provides a hook into the restore process before it begins.
-type PreRestoreAction interface {
-    // Execute the PreRestoreAction plugin providing it access to the Restore that
-    // is being executed
-    Execute(restore *api.Restore) error
-}
-```
-
-`PreRestoreAction` will be defined in `pkg/plugin/velero/pre_restore_action.go`.
-
-#### PostRestoreAction
-
-The `PostRestoreAction` interface is as follows:
-
-```go
-// PostRestoreAction provides a hook into the restore process after it completes.
-type PostRestoreAction interface {
-    // Execute the PostRestoreAction plugin providing it access to the Restore that
-    // has been completed
-    Execute(restore *api.Restore) error
-}
-```
-
-`PostRestoreAction` will be defined in `pkg/plugin/velero/post_restore_action.go`.
-
-### New BackupStore Interface Methods
-
-For the persistence of the logs originated from the PostBackup and PostRestore plugins, create two additional methods on `BackupStore` interface:
-
-```go
-type BackupStore interface {
-    (...)
-    PutPostBackuplog(backup string, log io.Reader) error
-    PutPostRestoreLog(backup, restore string, log io.Reader) error
-    (...)
-```
-
-The implementation of these new two methods will go hand-in-hand with the changes of uploading phases rebase.
-
-
-### Generate Protobuf Definitions and Client/Servers
-
-In `pkg/plugin/proto`, add the following:
-
-1. Protobuf definitions will be necessary for PreBackupAction in `pkg/plugin/proto/PreBackupAction.proto`.
-
-```protobuf
-message PreBackupActionExecuteRequest {
-    ...
-}
-
-service PreBackupAction {
-    rpc Execute(PreBackupActionExecuteRequest) returns (Empty)
-}
-```
-
-Once these are written, then a client and server implementation can be written in `pkg/plugin/framework/pre_backup_action_client.go` and `pkg/plugin/framework/pre_backup_action_server.go`, respectively.
-
-2. Protobuf definitions will be necessary for PostBackupAction in `pkg/plugin/proto/PostBackupAction.proto`.
-
-```protobuf
-message PostBackupActionExecuteRequest {
-    ...
-}
-
-service PostBackupAction {
-    rpc Execute(PostBackupActionExecuteRequest) returns (Empty)
-}
-```
-
-Once these are written, then a client and server implementation can be written in `pkg/plugin/framework/post_backup_action_client.go` and `pkg/plugin/framework/post_backup_action_server.go`, respectively.
-
-3. Protobuf definitions will be necessary for PreRestoreAction in `pkg/plugin/proto/PreRestoreAction.proto`.
-
-```protobuf
-message PreRestoreActionExecuteRequest {
-    ...
-}
-
-service PreRestoreAction {
-    rpc Execute(PreRestoreActionExecuteRequest) returns (Empty)
-}
-```
-
-Once these are written, then a client and server implementation can be written in `pkg/plugin/framework/pre_restore_action_client.go` and `pkg/plugin/framework/pre_restore_action_server.go`, respectively.
-
-4. Protobuf definitions will be necessary for PostRestoreAction in `pkg/plugin/proto/PostRestoreAction.proto`.
-
-```protobuf
-message PostRestoreActionExecuteRequest {
-    ...
-}
-
-service PostRestoreAction {
-    rpc Execute(PostRestoreActionExecuteRequest) returns (Empty)
-}
-```
-
-Once these are written, then a client and server implementation can be written in `pkg/plugin/framework/post_restore_action_client.go` and `pkg/plugin/framework/post_restore_action_server.go`, respectively.
-
-### Restartable Delete Plugins
-
-Similar to the `RestoreItemAction` and `BackupItemAction` plugins, restartable processes will need to be implemented (with the difference that there is no `AppliedTo()` method).
-
-In `pkg/plugin/clientmgmt/`, add
-
-1. `restartable_pre_backup_action.go`, creating the following unexported type:
-
-```go
-type restartablePreBackupAction struct {
-    key                 kindAndName
-    sharedPluginProcess RestartableProcess
-}
-
-func newRestartablePreBackupAction(name string, sharedPluginProcess RestartableProcess) *restartablePreBackupAction {
-    // ...
-}
-
-func (r *restartablePreBackupAction) getPreBackupAction() (velero.PreBackupAction, error) {
-    // ...
-}
-
-func (r *restartablePreBackupAction) getDelegate() (velero.PreBackupAction, error) {
-    // ...
-}
-
-// Execute restarts the plugin's process if needed, then delegates the call.
-func (r *restartablePreBackupAction) Execute(input *velero.PreBackupActionInput) (error) {
-    // ...
-}
-```
-
-2. `restartable_post_backup_action.go`, creating the following unexported type:
-
-```go
-type restartablePostBackupAction struct {
-    key                 kindAndName
-    sharedPluginProcess RestartableProcess
-}
-
-func newRestartablePostBackupAction(name string, sharedPluginProcess RestartableProcess) *restartablePostBackupAction {
-    // ...
-}
-
-func (r *restartablePostBackupAction) getPostBackupAction() (velero.PostBackupAction, error) {
-    // ...
-}
-
-func (r *restartablePostBackupAction) getDelegate() (velero.PostBackupAction, error) {
-    // ...
-}
-
-// Execute restarts the plugin's process if needed, then delegates the call.
-func (r *restartablePostBackupAction) Execute(input *velero.PostBackupActionInput) (error) {
-    // ...
-}
-```
-
-3. `restartable_pre_restore_action.go`, creating the following unexported type:
-
-```go
-type restartablePreRestoreAction struct {
-    key                 kindAndName
-    sharedPluginProcess RestartableProcess
-}
-
-func newRestartablePreRestoreAction(name string, sharedPluginProcess RestartableProcess) *restartablePreRestoreAction {
-    // ...
-}
-
-func (r *restartablePreRestoreAction) getPreRestoreAction() (velero.PreRestoreAction, error) {
-    // ...
-}
-
-func (r *restartablePreRestoreAction) getDelegate() (velero.PreRestoreAction, error) {
-    // ...
-}
-
-// Execute restarts the plugin's process if needed, then delegates the call.
-func (r *restartablePreRestoreAction) Execute(input *velero.PreRestoreActionInput) (error) {
-    // ...
-}
-```
-
-4. `restartable_post_restore_action.go`, creating the following unexported type:
-
-```go
-type restartablePostRestoreAction struct {
-    key                 kindAndName
-    sharedPluginProcess RestartableProcess
-}
-
-func newRestartablePostRestoreAction(name string, sharedPluginProcess RestartableProcess) *restartablePostRestoreAction {
-    // ...
-}
-
-func (r *restartablePostRestoreAction) getPostRestoreAction() (velero.PostRestoreAction, error) {
-    // ...
-}
-
-func (r *restartablePostRestoreAction) getDelegate() (velero.PostRestoreAction, error) {
-    // ...
-}
-
-// Execute restarts the plugin's process if needed, then delegates the call.
-func (r *restartablePostRestoreAction) Execute(input *velero.PostRestoreActionInput) (error) {
-    // ...
-}
-```
-
-### Plugin Manager Changes
-
-Add the following methods to the `Manager` interface in `pkg/plugin/clientmgmt/manager.go`:
-
-```go
-type Manager interface {
-    ...
-    // Get PreBackupAction returns a PreBackupAction plugin for name.
-    GetPreBackupAction(name string) (PreBackupAction, error)
-
-    // Get PreBackupActions returns the all PreBackupAction plugins.
-    GetPreBackupActions() ([]PreBackupAction, error)
-
-    // Get PostBackupAction returns a PostBackupAction plugin for name.
-    GetPostBackupAction(name string) (PostBackupAction, error)
-
-    // GetPostBackupActions returns the all PostBackupAction plugins.
-    GetPostBackupActions() ([]PostBackupAction, error)
-
-    // Get PreRestoreAction returns a PreRestoreAction plugin for name.
-    GetPreRestoreAction(name string) (PreRestoreAction, error)
-
-    // Get PreRestoreActions returns the all PreRestoreAction plugins.
-    GetPreRestoreActions() ([]PreRestoreAction, error)
-
-    // Get PostRestoreAction returns a PostRestoreAction plugin for name.
-    GetPostRestoreAction(name string) (PostRestoreAction, error)
-
-    // GetPostRestoreActions returns the all PostRestoreAction plugins.
-    GetPostRestoreActions() ([]PostRestoreAction, error)
-
-}
-```
-
-`GetPreBackupAction` and `GetPreBackupActions` will invoke the `restartablePreBackupAction` implementations.
-`GetPostBackupAction` and `GetPostBackupActions` will invoke the `restartablePostBackupAction` implementations.
-`GetPreRestoreAction` and `GetPreRestoreActions` will invoke the `restartablePreRestoreAction` implementations.
-`GetPostRestoreAction` and `GetPostRestoreActions` will invoke the `restartablePostRestoreAction` implementations.
-
-### How to invoke the Plugins
-
-#### Getting Pre/Post Backup Actions
-
-Getting Actions on `backup_controller.go` in `runBackup`:
-
-```go
-
-    backupLog.Info("Getting PreBackup actions")
-    preBackupActions, err := pluginManager.GetPreBackupActions()
-    if err != nil {
-        return err
-    }
-
-    backupLog.Info("Getting PostBackup actions")
-    postBackupActions, err := pluginManager.GetPostBackupActions()
-    if err != nil {
-        return err
-    }
-```
-
-#### Pre Backup Actions Plugins
-
-Calling the Pre Backup actions:
-
-```go
-    for _, preBackupAction := range preBackupActions {
-        err := preBackupAction.Execute(backup.Backup)
-        if err != nil {
-            backup.Backup.Status.Phase = velerov1api.BackupPhaseFailedPreBackupActions
-            return err
-        }
-    }
-```
-
-#### Post Backup Actions Plugins
-
-Calling the Post Backup actions:
-
-```go
-    for _, postBackupAction := range postBackupActions {
-        err := postBackupAction.Execute(backup.Backup)
-        if err != nil {
-            postBackupLog.Error(err)
-        }
-    }
-```
-
-#### Getting Pre/Post Restore Actions
-
-Getting Actions on `restore_controller.go` in `runValidatedRestore`:
-
-```go
-
-    restoreLog.Info("Getting PreRestore actions")
-    preRestoreActions, err := pluginManager.GetPreRestoreActions()
-    if err != nil {
-        return errors.Wrap(err, "error getting pre-restore actions")
-    }
-
-    restoreLog.Info("Getting PostRestore actions")
-    postRestoreActions, err := pluginManager.GetPostRestoreActions()
-    if err != nil {
-        return errors.Wrap(err, "error getting post-restore actions")
-    }
-```
-
-#### Pre Restore Actions Plugins
-
-Calling the Pre Restore actions:
-
-```go
-    for _, preRestoreAction := range preRestoreActions {
-        err := preRestoreAction.Execute(restoreReq.Restore)
-        if err != nil {
-            restoreReq.Restore.Status.Phase = velerov1api.RestorePhaseFailedPreRestoreActions
-            return errors.Wrap(err, "error executing pre-restore action")
-        }
-    }
-```
-
-#### Post Restore Actions Plugins
-
-Calling the Post Restore actions:
-
-```go
-    for _, postRestoreAction := range postRestoreActions {
-        err := postRestoreAction.Execute(restoreReq.Restore)
-        if err != nil {
-            postRestoreLog.Error(err.Error())
-        }
-    }
-```
-
-### Giving the User the Option to Skip the Execution of the Plugins
-
-Velero plugins are loaded as init containers. If plugins are unloaded, they trigger a restart of the Velero controller.
-Not mentioning if one plugin does get loaded for any reason (i.e., docker hub image pace limit), Velero does not start.
-In other words, the constant load/unload of plugins can disrupt the Velero controller, and they cannot be the only method to run the actions from these plugins selectively.
-As part of this proposal, we want to give the velero user the ability to skip the execution of the plugins via annotations on the Velero CR backup and restore objects.
-If one of these exists, the given plugin, referenced below as `plugin-name`, will be skipped.
-
-Backup Object Annotations:
-
-```
-   <plugin-name>/prebackup=skip
-   <plugin-name>/postbackup=skip
-```
-
-Restore Object Annotations:
-
-```
-   <plugin-name>/prerestore=skip
-   <plugin-name>/postrestore=skip
-```
-
-## Alternatives Considered
-
-An alternative to these plugin hooks is to implement all the pre/post backup/restore logic _outside_ Velero.
-In this case, one would need to write an external controller that works similar to what [Konveyor Crane](https://github.com/konveyor/mig-controller/blob/master/pkg/controller/migmigration/quiesce.go) does today when quiescing applications.
-We find this a viable way, but we think that Velero users can benefit from Velero having greater embedded capabilities, which will allow users to write or load plugins extensions without relying on an external components.
-
-## Security Considerations
-
-The plugins will only be invoked if loaded per a user's discretion.
-It is recommended to check security vulnerabilities before execution.
-
-## Compatibility
-
-In terms of backward compatibility, this design should stay compatible with most Velero installations that are upgrading.
-If plugins are not present, then the backup/restore process should proceed the same way it worked before their inclusion.
-
-## Implementation
-
-The implementation dependencies are roughly in the order as they are described in the [Detailed Design](#detailed-design) section.
-
-## Open Issues

design/plugin-versioning.md

@@ -1,292 +0,0 @@
-# Plugin Versioning
-
-## Abstract
-This proposal outlines an approach to support versioning of Velero's plugin APIs to enable changes to those APIs.
-It will allow for backwards compatible changes to be made, such as the addition of new plugin methods, but also backwards incompatible changes such as method removal or method signature changes.
-
-
-## Background
-When changes are made to Velero’s plugin APIs, there is no mechanism for the Velero server to communicate the version of the API that is supported, or for plugins to communicate what version they implement.
-This means that any modification to a plugin API is a backwards incompatible change as it requires all plugins which implement the API to update and implement the new method.
-
-There are several components involved to use plugins within Velero.
-From the perspective of the core Velero codebase, all plugin kinds (e.g. `ObjectStore`, `BackupItemAction`) are defined by a single API interface and all interactions with plugins are managed by a plugin manager which provides an implementation of the plugin API interface for Velero to use.
-
-Velero communicates with plugins via gRPC.
-The core Velero project provides a framework (using the [go-plugin project](https://github.com/hashicorp/go-plugin)) for plugin authors to use to implement their plugins which manages the creation of gRPC servers and clients.
-Velero plugins import the Velero plugin library in order to use this framework.
-When a change is made to a plugin API, it needs to be made to the Go interface used by the Velero codebase, and also to the rpc service definition which is compiled to form part of the framework.
-As each plugin kind is defined by a single interface, when a plugin imports the latest version of the Velero framework, it will need to implement the new APIs in order to build and run successfully.
-If a plugin does not use the latest version of the framework, and is used with a newer version of Velero that expects the plugin to implement those methods, this will result in a runtime error as the plugin is incompatible.
-
-With this proposal, we aim to break this coupling and introduce plugin API versions.
-
-## Scenarios to Support
-The following describes interactions between Velero and its plugins that will be supported with the implementation of this proposal.
-For the purposes of this list, we will refer to existing Velero and plugin versions as `v1` and all following versions as version `n`.
-
-Velero client communicating with plugins or plugin client calling other plugins:
-
-- Version `n` client will be able to communicate with Version `n` plugin
-- Version `n` client will be able to communicate with all previous versions of the plugin (Version `n-1` back to `v1`)
-
-Velero plugins importing Velero framework:
-- `v1` plugin built against Version `n` Velero framework
-    - A plugin may choose to only implement a `v1` API, but it must be able to be built using Version `n` of the Velero framework
-
-
-## Goals
-
-- Allow plugin APIs to change without requiring all plugins to implement the latest changes (even if they upgrade the version of Velero that is imported)
-- Allow plugins to choose which plugin versions they support and enable them to support multiple versions
-- Support breaking changes in the plugin APIs such as method removal or method signature changes
-- Establish a design process for modifying plugin APIs such as method addition and removal and signature changes
-- Establish a process for newer Velero clients to use older versions of a plugin API through adaptation
-
-## Non Goals
-
-- Change how plugins are managed or added
-- Allow older plugin clients to communicate with new versions of plugins
-
-## High-Level Design
-
-With each change to a plugin API, a new version of the plugin interface and the proto service definition will be created which describes the new plugin API.
-The plugin framework will be adapted to allow these new plugin versions to be registered.
-Plugins can opt to implement any or all versions of an API, however Velero will always attempt to use the latest version, and the plugin management will be modified to adapt earlier versions of a plugin to be compatible with the latest API where possible.
-Under the existing plugin framework, any new plugin version will be treated as a new plugin with a new kind.
-The plugin manager (which provides implementations of a plugin to Velero) will include an adapter layer which will manage the different versions and provide the adaptation for versions which do not implement the latest version of the plugin API.
-Providing an adaptation layer enables Velero and other plugin clients to use an older version of a plugin if it can be safely adapted.
-As the plugins will be able to introduce backwards incompatible changes, it will _not_ be possible for older version of Velero to use plugins which only support the latest versions of the plugin APIs.
-
-Although adding new rpc methods to a service is considered a backwards compatible change within gRPC, due to the way the proto definitions are compiled and included in the framework used by plugins, this will require every plugin to implement the new methods.
-Instead, we are opting to treat the addition of a method to an API as one requiring versioning.
-
-The addition of optional fields to existing structs which are used as parameters to or return values of API methods will not be considered as a change requiring versioning.
-These kinds of changes do not modify method signatures and have been safely made in the past with no impact on existing plugins.
-
-## Detailed Design
-
-The following areas will need to be adapted to support plugin versioning.
-
-### Plugin Interface Definitions
-
-To provide versioned plugins, any change to a plugin interface (method addition, removal, or signature change) will require a new versioned interface to be created.
-Currently, all plugin interface definitions reside in `pkg/plugin/velero` in a file corresponding to their plugin kind.
-These files will be rearranged to be grouped by kind and then versioned: `pkg/plugin/velero/<plugin_kind>/<version>/`.
-
-The following are examples of how each change may be treated:
-
-#### Complete Interface Change
-If the entire `ObjectStore` interface is being changed such that no previous methods are being included, a file would be added to `pkg/plugin/velero/objectstore/v2/` and would contain the new interface definition:
-
-```
-type ObjectStore interface {
-	// Only include new methods that the new API version will support
-	
-	NewMethod()
-	// ...
-}
-```
-
-#### Method Addition
-If a method is being added to the `ObjectStore` API, a file would be added to `pkg/plugin/velero/objectstore/v2/` and may contain a new API definition as follows:
-
-```
-import "github.com/vmware-tanzu/velero/pkg/plugin/velero/objectstore/v1"
-
-type ObjectStore interface {
-    // Import all the methods from the previous version of the API if they are to be included as is
-    v1.ObjectStore
-
-    // Provide definitions of any new methods
-    NewMethod()
-```
-
-#### Method Removal
-If a method is being removed from the `ObjectStore` API, a file would be added to `pkg/plugin/velero/objectstore/v2/` and may contain a new API definition as follows:
-
-```
-type ObjectStore interface {
-	// Methods which are required from the previous API version must be included, for example
-	Init(config)
-	PutObject(bucket, key, body)
-    // ...
-
-    // Methods which are to be removed are not included
-```
-
-#### Method Signature modification
-If a method signature in the `ObjectStore` API is being modified, a file would be added to `pkg/plugin/velero/objectstore/v2/` and may contain a new API definition as follows:
-
-```
-type ObjectStore interface {
-	// Methods which are required from the previous API version must be included, for example
-	Init(config)
-	PutObject(bucket, key, body)
-    // ...	
-
-    // Provide new definitions for methods which are being modified
-	List(bucket, prefix, newParameter)
-	
-}
-```
-
-### Proto Service Definitions
-
-The proto service definitions of the plugins will also be versioned and arranged by their plugin kind.
-Currently, all the proto definitions reside under `pkg/plugin/proto` in a file corresponding to their plugin kind.
-These files will be rearranged to be grouped by kind and then versioned: `pkg/plugin/proto/<plugin_kind>/<version>`,
-except for the current v1 plugins. Those will remain in their current package/location for backwards compatibility.
-This will allow plugin images built with earlier versions of velero to work with the latest velero (for v1 plugins
-only). The go_package option will be added to all proto service definitions to allow the proto compilation script
-to place the generated go code for each plugin api version in the proper go package directory.
-
-It is not possible to import an existing proto service into a new one, so any methods will need to be duplicated across versions if they are required by the new version.
-The message definitions can be shared however, so these could be extracted from the service definition files and placed in a file that can be shared across all versions of the service.
-
-### Plugin Framework
-
-To allow plugins to register which versions of the API they implement, the plugin framework will need to be adapted to accept new versions.
-Currently, the plugin manager stores a [`map[string]RestartableProcess`](https://github.com/vmware-tanzu/velero/blob/main/pkg/plugin/clientmgmt/manager.go#L69), where the string key is the binary name for the plugin process (e.g. "velero-plugin-for-aws").
-Each `RestartableProcess` contains a [`map[kindAndName]interface{}`](https://github.com/vmware-tanzu/velero/blob/main/pkg/plugin/clientmgmt/restartable_process.go#L60) which represents each of the unique plugin implementations provided by that binary.
-[`kindAndName`](https://github.com/vmware-tanzu/velero/blob/main/pkg/plugin/clientmgmt/registry.go#L42) is a struct which combines the plugin kind (`ObjectStore`, `VolumeSnapshotter`) and the plugin name ("velero.io/aws", "velero.io/azure").
-
-Each plugin version registration must be unique (to allow for multiple versions to be implemented within the same plugin binary).
-This will be achieved by adding a specific registration method for each version to the Server interface in the plugin framework.
-For example, if adding a V2 `RestoreItemAction` plugin, the Server interface would be modified to add the `RegisterRestoreItemActionV2` method.
-This would require [adding a new plugin Kind const](https://github.com/vmware-tanzu/velero/blob/main/pkg/plugin/framework/plugin_kinds.go#L28-L46) to represent the new plugin version, e.g. `PluginKindRestoreItemActionV2`.
-It also requires the creation of a new implementation of the go-plugin interface ([example](https://github.com/vmware-tanzu/velero/blob/main/pkg/plugin/framework/object_store.go)) to support that version and use the generated gRPC code from the proto definition (including a client and server implementation).
-The Server will also need to be adapted to recognize this new plugin Kind and to serve the new implementation.
-
-Existing plugin Kind consts and registration methods will be left unchanged and will correspond to the current version of the plugin APIs (assumed to be v1).
-
-### Plugin Manager
-
-The plugin manager is responsible for managing the lifecycle of plugins.
-It provides an interface which is used by Velero to retrieve an instance of a plugin kind with a specific name (e.g. `ObjectStore` with the name "velero.io/aws").
-The manager contains a registry of all available plugins which is populated during the main Velero server startup.
-When the plugin manager is requested to provide a particular plugin, it checks the registry for that plugin kind and name.
-If it is available in the registry, the manager retrieves a `RestartableProcess` for the plugin binary, creating it if it does not already exist.
-That `RestartableProcess` is then used by individual restartable implementations of a plugin kind (e.g. `restartableObjectStore`, `restartableVolumeSnapshotter`).
-
-As new plugin versions are added, the plugin manager will be modified to always retrieve the latest version of a plugin kind.
-This is to allow the remainder of the Velero codebase to assume that it will always interact with the latest version of a plugin.
-If the latest version of a plugin is not available, it will attempt to fall back to previous versions and use an implementation adapted to the latest version if available.
-It will be up to the author of new plugin versions to determine whether a previous version of a plugin can be adapted to work with the interface of the new version.
-
-For each plugin kind, a new `Restartable<PluginKind>` struct will be introduced which will contain the plugin Kind and a function, `Get`, which will instantiate a restartable instance of that plugin kind and perform any adaptation required to make it compatible with the latest version.
-For example, `RestartableObjectStore` or `RestartableVolumeSnapshotter`.
-For each restartable plugin kind, a new function will be introduced which will return a slice of `Restartable<PluginKind>` objects, sorted by version in descending order.
-
-The manager will iterate through the list of `Restartable<PluginKind>`s and will check the registry for the given plugin kind and name.
-If the requested version is not found, it will skip and continue to iterate, attempting to fetch previous versions of the plugin kind.
-Once the requested version is found, the `Get` function will be called, returning the restartable implementation of the latest version of that plugin Kind.
-
-```
-type RestartableObjectStore struct {
-	kind framework.PluginKind
-	
-	// Get returns a restartable ObjectStore for the given name and process, wrapping if necessary
-	Get func(name string, restartableProcess RestartableProcess) v2.ObjectStore
-}
-
-func (m *manager) restartableObjectStores() []RestartableObjectStore {
-	return []RestartableObjectStore{
-		{
-			kind: framework.PluginKindObjectStoreV2,
-			Get: newRestartableObjectStoreV2,
-		},
-		{
-			kind: framework.PluginKindObjectStore,
-			Get: func(name string, restartableProcess RestartableProcess) v2.ObjectStore {
-				// Adapt the existing restartable v1 plugin to be compatible with the v2 interface
-				return newAdaptedV1ObjectStore(newRestartableObjectStore(name, restartableProcess))
-			},
-		},
-	}
-}
-
-// GetObjectStore returns a restartableObjectStore for name.
-func (m *manager) GetObjectStore(name string) (v2.ObjectStore, error) {
-	name = sanitizeName(name)
-
-	for _, restartableObjStore := range m.restartableObjectStores() {
-		restartableProcess, err := m.getRestartableProcess(restartableObjStore.kind, name)
-		if err != nil {
-			// Check if plugin was not found
-			if errors.Is(err, &pluginNotFoundError{}) {
-				continue
-			}
-			return nil, err
-		}
-		return restartableObjStore.Get(name, restartableProcess), nil
-	}
-
-	return nil, fmt.Errorf("unable to get valid ObjectStore for %q", name)
-}
-```
-
-If the previous version is not available, or can not be adapted to the latest version, it should not be included in the `restartableObjectStores` slice.
-This will result in an error being returned as is currently the case when a plugin implementation for a particular kind and provider can not be found.
-
-There are situations where it may be beneficial to check at the point where a plugin API call is made whether it implements a specific version of the API.
-This is something that can be addressed with future amendments to this design, however it does not seem to be necessary at this time.
-
-#### Plugin Adaptation
-
-When a new plugin API version is being proposed, it will be up to the author and the maintainer team to determine whether older versions of an API can be safely adapted to the latest version.
-An adaptation will implement the latest version of the plugin API interface but will use the methods from the version that is being adapted.
-In cases where the methods signatures remain the same, the adaptation layer will call through to the same method in the version being adapted.
-
-Examples where an adaptation may be safe:
-- A method signature is being changed to add a new parameter but the parameter could be optional (for example, adding a context parameter). The adaptation could call through to the method provided in the previous version but omit the parameter.
-- A method signature is being changed to remove a parameter, but it is safe to pass a default value to the previous version. The adaptation could call through to the method provided in the previous version but use a default value for the parameter.
-- A new method is being added but does not impact any existing behaviour of Velero (for example, a new method which will allow Velero to [wait for additional items to be ready](https://github.com/vmware-tanzu/velero/blob/main/design/wait-for-additional-items.md)). The adaptation would return a value which allows the existing behaviour to be performed.
-- A method is being deleted as it is no longer used. The adaptation would call through to any methods which are still included but would omit the deleted method in the adaptation.
-
-Examples where an adaptation may not be safe:
-- A new method is added which is used to provide new critical functionality in Velero. If this functionality can not be replicated using existing plugin methods in previous API versions, this should not be adapted and instead the plugin manager should return an error indicating that the plugin implementation can not be found.
-
-### Restartable Plugin Process
-
-As new versions of plugins are added, new restartable implementations of plugins will also need to be created.
-These are currently located within "pkg/plugin/clientmgmt" but will be rearranged to be grouped by kind and version like other plugin files.
-
-## Versioning Considerations
-
-It should be noted that if changes are being made to a plugin's API, it will only be necessary to bump the API version once within a release cycle, regardless of how many changes are made within that cycle.
-This is because the changes will only be available to consumers when they upgrade to the next minor version of the Velero library.
-New plugin API versions will not be introduced or backported to patch releases.
-
-Once a new minor or major version of Velero has been released however, any further changes will need to follow the process above and use a new API version.
-
-## Alternatives Considered
-
-### Relying on gRPC’s backwards compatibility when adding new methods
-
-One approach for adapting the plugin APIs would have been to rely on the fact that adding methods to gRPC services is a backwards compatible change.
-This approach would allow older clients to communicate with newer plugins as the existing interface would still be provided.
-This was considered but ruled out as our current framework would require any plugin that recompiles using the latest version of the framework to adapt to the new version.
-Also, without specific versioned interfaces, it would require checking plugin implementations at runtime for the specific methods that are supported.
-
-## Compatibility
-
-This design doc aims to allow plugin API changes to be made in a manner that may provide some backwards compatibility.
-Older versions of Velero will not be able to make use of new plugin versions however may continue to use previous versions of a plugin API if supported by the plugin.
-
-All compatibility concerns are addressed earlier in the document.
-
-## Implementation
-
-This design document primarily outlines an approach to allow future plugin API changes to be made.
-However, there are changes to the existing code base that will be made to allow plugin authors to more easily propose and introduce changes to these APIs.
-
-* Plugin interface definitions (currently in `pkg/plugin/velero`) will be rearranged to be grouped by kind and then versioned: `pkg/plugin/velero/<plugin_kind>/<version>/`.
-* Proto definitions (currently in `pkg/plugin/proto`) will be rearranged to be grouped by kind and then versioned: `pkg/plugin/proto/<plugin_kind>/<version>`.
-  * This will also require changes to the `make update` build task to correctly find the new proto location and output to the versioned directories.
-
-It is anticipated that changes to the plugin APIs will be made as part of the 1.9 release cycle.
-To assist with this work, an additional follow-up task to the ones listed above would be to prepare a V2 version of each of the existing plugins.
-These new versions will not yet provide any new API methods but will provide a layout for new additions to be made
-
-## Open Issues

design/restore-with-EnableAPIGroupVersions-feature.md

@@ -1,6 +1,6 @@
 # Restore API Group Version by Priority Level When EnableAPIGroupVersions Feature is Set
 
-Status: Accepted
+Status: Draft
 
 ## Abstract
 

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

@@ -1,483 +0,0 @@
-# Unified Repository & Kopia Integration Design
-
-## 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 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.   
-**RTO**: Recovery Time Objective. This is the duration of time that users’ business can recover after a disaster.  
-
-## 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:  
-
-- Move data from various production workloads. The data mover has this role. Depending on the type of workload, Velero needs different data movers. For example, file system data mover, block data mover, and data movers for specific applications. At present, Velero supports moving file system data from PVs through Restic, which plays the role of the File System Data Mover.  
-- Persist data in backup storage. For a BR solution, this is the responsibility of the backup repository. Specifically, the backup repository is required to:  
-  - Efficiently save data so as to reduce TCO. For example, deduplicate and compress the data before saving it
-  - Securely save data so as to meet security criteria. For example, encrypt the data on rest, make the data immutable after backup, and detect/protect from ransomware
-  - Efficiently retrieve data during restore so as to meet RTO. For example, restore a small unit of data or data associated with a small span of time 
-  - Effectively manage data from all kinds of data movers in all kinds of backup storage. This means 2 things: first, apparently, backup storages are different from each other; second, some data movers may save quite different data from others, for example, some data movers save a portion of the logical object for each backup and need to visit and manage the portions as an entire logic object, aka. incremental backup. The backup repository needs to provide unified functionalities to eliminate the differences from the both ends
-  - Provide scalabilities so that users could assign resources (CPU, memory, network, etc.) in a flexible way to the backup repository since backup repository contains resource consuming modules
-
-At present, Velero provides some of these capabilities by leveraging Restic (e.g., deduplication and  encryption on rest). This means that in addition to being a data mover for file system level data, Restic also plays the role of a backup repository, albeit one that is incomplete and limited:  
-
-- Restic is an inseparable unit made up of a file system data mover and a repository. This means that the repository capabilities are only available for Restic file system backup. We cannot provide the same capabilities to other data movers using Restic.
-- The backup storage Velero supports through our Restic backup path depends on the storage Restic supports. As a result, if there is a requirement to introduce backup storage that Restic doesn’t support, we have no way to make it.
-- There is no way to enhance or extend the repository capabilities, because of the same reason – Restic is an inseparable unit, we cannot insert one or more customized layers to make the enhancements and extensions.
-
-Moreover, as reflected by user-reported issues, Restic seems to have many performance issues on both the file system data mover side and the repository side.  
-
-On the other hand, based on a previous analysis and testing, we found that Kopia has better performance, with more features and more suitable to fulfill Velero’s repository targets (Kopia’s architecture divides modules more clearly according to their responsibilities, every module plays a complete role with clear interfaces. This makes it easier to take individual modules to Velero without losing critical functionalities).  
-
-## Goals
-
-- Define a Unified Repository Interface that various data movers could interact with. This is for below purposes:
-  - All kinds of data movers acquire the same set of backup repository capabilities very easily
-  - Provide the possibility to plugin in different backup repositories/backup storages without affecting the upper layers
-  - Provide the possibility to plugin in modules between data mover and backup repository, so as to extend the repository capabilities
-  - Provide the possibility to scale the backup repository without affecting the upper layers
-- Use Kopia repository to implement the Unified Repository
-- Use Kopia uploader as the file system data mover for Pod Volume Backup
-- Have Kopia uploader calling the Unified Repository Interface and save/retrieve data to/from the Unified Repository
-- Make Kopia uploader generic enough to move any file system data so that other data movement cases could use it
-- Use the existing logic or add new logic to manage the unified repository and Kopia uploader
-- Preserve the legacy Restic path, this is for the consideration of backward compatibility
-
-## Non-Goals
-
-- The Unified Repository supports all kinds of data movers to save logic objects into it. How these logic objects are organized for a specific data mover (for example, how a volume’s block data is organized and represented by a unified repository object) should be included in the related data mover design.
-- At present, Velero saves Kubernetes resources, backup metedata, debug logs separately. Eventually, we want to save them in the Unified Repository. How to organize these data into the Unified Repository should be included in a separate design.
-- For PodVolume BR, this design focuses on the data path only, other parts beyond the data read/write and data persistency are irrelevant and kept unchanged. 
-- Kopia uploader is made generic enough to move any file system data. How it is integrated in other cases, is irrelevant to this design. Take CSI snapshot backup for example, how the snapshot is taken and exposed to Kopia uploader should be included in the related data mover design.
-- The adanced modes of the Unified Repository, for example, backup repository/storage plugin, backup repository extension, etc. are not included in this design. We will have separate designs to cover them whenever necessary.
-
-## Architecture of Unified Repository
-
-Below shows the primary modules and their responsibilities:
-
-- Kopia uploader, as been well isolated, could move all file system data either from the production PV (as Velero’s PodVolume BR does), or from any kind of snapshot (i.e., CSI snapshot).
-- Unified Repository Interface, data movers call the Unified Repository Interface to write/read data to/from the Unified Repository.
-- Kopia repository layers, CAOS and CABS, work as the backup repository and expose the Kopia Repository interface.
-- A Kopia Repository Library works as an adapter between Unified Repository Interface and Kopia Repository interface. Specifically, it implements Unified Repository Interface and calls Kopia Repository interface.
-- At present, there is only one kind of backup repository -- Kopia Repository. If a new backup repository/storage is required, we need to create a new Library as an adapter to the Unified Repository Interface
-- At present, the Kopia Repository works as a single piece in the same process of the caller, in future, we may run its CABS into a dedicated process or node.
-- At present, we don’t have a requirement to extend the backup repository, if needed, an extra module could be added as an upper layer into the Unified Repository without changing the data movers.  
-
-Neither Kopia uploader nor Kopia Repository is invoked through CLI, instead, they are invoked through code interfaces, because we need to do lots of customizations.  
-
-The Unified Repository takes two kinds of data:
-- Unified Repository Object: This is the user's logical data, for example, files/directories, blocks of a volume, data of a database, etc.
-- Unified Repository Manifest: This could include all other data to maintain the object data, for example, snapshot information, etc.  
-
-For Unified Repository Object/Manifest, a brief guidance to data movers are as below:
-- Data movers treat the simple unit of data they recognize as an Object. For example, file system data movers treat a file or a directory as an Object; block data movers treat a volume as an Object. However, it is unnecessary that every data mover has a unique data format in the Unified Repository, to the opposite, it is recommended that data movers could share the data formats unless there is any reason not to, in this way, the data generated by one data mover could be used by other data movers.
-- Data movers don't need to care about the differences between full and incremental backups regarding the data organization. Data movers always have full views of their objects, if an object is partially written, they use the object writer's Seek function to skip the unchanged parts
-- Unified Repository may divide the data movers' logical Object into sub-objects or slices, or append internal metadata, but they are transparent to data movers 
-- Every Object has an unified identifier, in order to retrieve the Object later, data movers need to save the identifiers into the snapshot information. The snapshot information is saved as a Manifest.
-- Manifests could hold any kind of small piece data in a K-V manner. Inside the backup repository, these kinds of data may be processed differently from Object data, but it is transparent to data movers.
-- A Manifest also has an unified identifier, the Unified Repository provides the capabilities to list all the Manifests or a specified Manifest by its identifier, or a specified Manifest by its name, or a set of Manifests by their labels.
- 
-![A Unified Repository Architecture](unified-repo.png)
-
-Velero by default uses the Unified Repository for all kinds of data movement, it is also able to integrate with other data movement paths from any party, for any purpose. Details are concluded as below:
-
-- Built-in Data Path: this is the default data movement path, which uses Velero built-in data movers to backup/restore workloads, the data is written to/read from the Unified Repository.
-- Data Mover Replacement: Any party could write its own data movers and plug them into Velero. Meanwhile, these plugin data movers could also write/read data to/from Velero’s Unified Repository so that these data movers could expose the same capabilities that provided by the Unified Repository. In order to do this, the data mover providers need to call the Unified Repository Interface from inside their plugin data movers.
-- Data Path Replacement: Some vendors may already have their own data movers and backup repository and they want to replace Velero’s entire data path (including data movers and backup repository). In this case, the providers only need to implement their plugin data movers, all the things downwards are a black box to Velero and managed by providers themselves (including API call, data transport, installation, life cycle management, etc.). Therefore, this case is out of the scope of Unified Repository.  
-![A Scope](scope.png)  
-
-# Detailed Design
-
-## The Unified Repository Interface  
-Below are the definitions of the Unified Repository Interface. All the functions are synchronization functions.   
-```
-// BackupRepoService is used to initialize, open or maintain a backup repository
-type BackupRepoService interface {
-	// Init creates a backup repository or connect to an existing backup repository.
-	// repoOption: option to the backup repository and the underlying backup storage.
-	// createNew: indicates whether to create a new or connect to an existing backup repository.
-	Init(ctx context.Context, repoOption RepoOptions, createNew bool) error
-
-	// Open opens an backup repository that has been created/connected.
-	// repoOption: options to open the backup repository and the underlying storage.
-	Open(ctx context.Context, repoOption RepoOptions) (BackupRepo, error)
-
-	// Maintain is periodically called to maintain the backup repository to eliminate redundant data.
-	// repoOption: options to maintain the backup repository.
-	Maintain(ctx context.Context, repoOption RepoOptions) error
-
-	// DefaultMaintenanceFrequency returns the defgault frequency of maintenance, callers refer this
-	// frequency to maintain the backup repository to get the best maintenance performance
-	DefaultMaintenanceFrequency() time.Duration
-}
-
-// BackupRepo provides the access to the backup repository
-type BackupRepo interface {
-	// OpenObject opens an existing object for read.
-	// id: the object's unified identifier.
-	OpenObject(ctx context.Context, id ID) (ObjectReader, error)
-
-	// GetManifest gets a manifest data from the backup repository.
-	GetManifest(ctx context.Context, id ID, mani *RepoManifest) error
-
-	// FindManifests gets one or more manifest data that match the given labels
-	FindManifests(ctx context.Context, filter ManifestFilter) ([]*ManifestEntryMetadata, error)
-
-	// NewObjectWriter creates a new object and return the object's writer interface.
-	// return: A unified identifier of the object on success.
-	NewObjectWriter(ctx context.Context, opt ObjectWriteOptions) ObjectWriter
-
-	// PutManifest saves a manifest object into the backup repository.
-	PutManifest(ctx context.Context, mani RepoManifest) (ID, error)
-
-	// DeleteManifest deletes a manifest object from the backup repository.
-	DeleteManifest(ctx context.Context, id ID) error
-
-	// Flush flushes all the backup repository data
-	Flush(ctx context.Context) error
-
-	// Time returns the local time of the backup repository. It may be different from the time of the caller
-	Time() time.Time
-
-	// Close closes the backup repository
-	Close(ctx context.Context) error
-
-type ObjectReader interface {
-	io.ReadCloser
-	io.Seeker
-
-	// Length returns the logical size of the object
-	Length() int64
-}
- 
-type ObjectWriter interface {
-	io.WriteCloser
-
-	// Seeker is used in the cases that the object is not written sequentially
-	io.Seeker
-
-	// Checkpoint is periodically called to preserve the state of data written to the repo so far.
-	// Checkpoint returns a unified identifier that represent the current state.
-	// An empty ID could be returned on success if the backup repository doesn't support this.
-	Checkpoint() (ID, error)
-
-	// Result waits for the completion of the object write.
-	// Result returns the object's unified identifier after the write completes.
-	Result() (ID, error)
-}
-```
- 
-Some data structure & constants used by the interfaces:  
-```
-type RepoOptions struct {
-	// StorageType is a repository specific string to identify a backup storage, i.e., "s3", "filesystem"
-	StorageType string
-	// RepoPassword is the backup repository's password, if any
-	RepoPassword string
-	// ConfigFilePath is a custom path to save the repository's configuration, if any
-	ConfigFilePath string
-	// GeneralOptions takes other repository specific options
-	GeneralOptions map[string]string
-	// StorageOptions takes storage specific options
-	StorageOptions map[string]string
-	// Description is a description of the backup repository/backup repository operation.
-	// It is for logging/debugging purpose only and doesn't control any behavior of the backup repository.
-	Description string
-}
-
-// ObjectWriteOptions defines the options when creating an object for write
-type ObjectWriteOptions struct {
-	FullPath    string // Full logical path of the object
-	DataType    int    // OBJECT_DATA_TYPE_*
-	Description string // A description of the object, could be empty
-	Prefix      ID     // A prefix of the name used to save the object
-	AccessMode  int    // OBJECT_DATA_ACCESS_*
-	BackupMode  int    // OBJECT_DATA_BACKUP_*
-}
-
-const (
-	// Below consts descrbe the data type of one object.
-	// Metadata: This type describes how the data is organized.
-	// For a file system backup, the Metadata describes a Dir or File.
-	// For a block backup, the Metadata describes a Disk and its incremental link.
-	ObjectDataTypeUnknown  int = 0
-	ObjectDataTypeMetadata int = 1
-	ObjectDataTypeData     int = 2
-
-	// Below consts defines the access mode when creating an object for write
-	ObjectDataAccessModeUnknown int = 0
-	ObjectDataAccessModeFile    int = 1
-	ObjectDataAccessModeBlock   int = 2
-
-	ObjectDataBackupModeUnknown int = 0
-	ObjectDataBackupModeFull    int = 1
-	ObjectDataBackupModeInc     int = 2
-)
-
-// ManifestEntryMetadata is the metadata describing one manifest data
-type ManifestEntryMetadata struct {
-	ID      ID                // The ID of the manifest data
-	Length  int32             // The data size of the manifest data
-	Labels  map[string]string // Labels saved together with the manifest data
-	ModTime time.Time         // Modified time of the manifest data
-}
- 
-type RepoManifest struct {
-	Payload  interface{}            // The user data of manifest
-	Metadata *ManifestEntryMetadata // The metadata data of manifest
-}
- 
-type ManifestFilter struct {
-    Labels map[string]string
-}
-```  
-
-## Workflow
-
-### Backup & Restore Workflow
-
-We preserve the bone of the existing BR workflow, that is:
-
-- Still use the Velero Server pod and VeleroNodeAgent daemonSet (originally called Restic daemonset) pods to hold the corresponding controllers and modules
-- Still use the Backup/Restore CR and BackupRepository CR (originally called ResticRepository CR) to drive the BR workflow
-
-The modules in gray color in below diagram are the existing modules and with no significant changes.  
-In the new design, we will have separate and independent modules/logics for backup repository and uploader (data mover), specifically:
-
-- Repository Provider provides functionalities to manage the backup repository. For example, initialize a repository, connect to a repository, manage the snapshots in the repository, maintain a repository, etc.
-- Uploader Provider provides functionalities to run a backup or restore.
-
-The Repository Provider and Uploader Provider use options to choose the path --- legacy path vs. new path (Kopia uploader + Unified Repository). Specifically, for legacy path, Repository Provider will manage Restic Repository only, otherwise, it manages Unified Repository only; for legacy path, Uploader Provider calls Restic to do the BR, otherwise, it calls Kopia uploader to do the BR.  
-
-In order to manage Restic Repository, the Repository Provider calls Restic Repository Provider, the latter invokes the existing Restic CLIs.  
-In order to manage Unified Repository, the Repository Provider calls Unified Repository Provider, the latter calls the Unified Repository module through the udmrepo.BackupRepoService interface. It doesn’t know how the Unified Repository is implemented necessarily.  
-In order to use Restic to do BR, the Uploader Provider calls Restic Uploader Provider, the latter invokes the existing Restic CLIs.  
-In order to use Kopia to do BR, the Uploader Provider calls Kopia Uploader Provider, the latter do the following things:
-
-- Call Unified Repository through the udmrepo.BackupRepoService interface to open the unified repository for read/write. Again, it doesn’t know how the Unified Repository is implemented necessarily. It gets a BackupRepo’s read/write handle after the call succeeds
-- Wrap the BackupRepo handle into a Kopia Shim which implements Kopia Repository interface
-- Call the Kopia Uploader. Kopia Uploader is a Kopia module without any change, so it only understands Kopia Repository interface
-- Kopia Uploader starts to backup/restore the corresponding PV’s file system data and write/read data to/from the provided Kopia Repository implementation, that is, Kopia Shim here
-- When read/write calls go into Kopia Shim, it in turn calls the BackupRepo handle for read/write
-- Finally, the read/write calls flow to Unified Repository module
-
-The Unified Repository provides all-in-one functionalities of a Backup Repository and exposes the Unified Repository Interface. Inside, Kopia Library is an adapter for Kopia Repository to translate the Unified Repository Interface calls to Kopia Repository interface calls.  
-Both Kopia Shim and Kopia Library rely on Kopia Repository interface, so we need to have some Kopia version control. We may need to change Kopia Shim and Kopia Library when upgrading Kopia to a new version and the Kopia Repository interface has some changes in the new version.
-![A BR Workflow](br-workflow.png)  
-The modules in blue color in below diagram represent the newly added modules/logics or reorganized logics.  
-The modules in yellow color in below diagram represent the called Kopia modules without changes.  
-
-### Delete Snapshot Workflow
-The Delete Snapshot workflow follows the similar manner with BR workflow, that is, we preserve the upper-level workflows until the calls reach to BackupDeletionController, then:
-- Leverage Repository Provider to switch between Restic implementation and Unified Repository implementation in the same mechanism as BR
-- For Restic implementation, the Restic Repository Provider invokes the existing “Forget” Restic CLI
-- For Unified Repository implementation, the Unified Repository Provider calls udmrepo.BackupRepo’s DeleteManifest to delete a snapshot
-![A Snapshot Deletion Workflow](snapshot-deletion-workflow.png) 
-
-### Maintenance Workflow
-Backup Repository/Backup Storage may need to periodically reorganize its data so that it could guarantee its QOS during the long-time service. Some Backup Repository/Backup Storage does this in background automatically, so the user doesn’t need to interfere; some others need the caller to explicitly call their maintenance interface periodically. Restic and Kopia both go with the second way, that is, Velero needs to periodically call their maintenance interface.  
-Velero already has an existing workflow to call Restic maintenance (it is called “Prune” in Restic, so Velero uses the same word). The existing workflow is as follows:
-- The Prune is triggered at the time of the backup
-- When a BackupRepository CR (originally called ResticRepository CR) is created by PodVolumeBackup/Restore Controller, the BackupRepository controller checks if it reaches to the Prune Due Time, if so, it calls PruneRepo  
-- In the new design, the Repository Provider implements PruneRepo call, it uses the same way to switch between Restic Repository Provider and Unified Repository Provider, then:
-  - For Restic Repository, Restic Repository Provider invokes the existing “Prune” CLI of Restic
-  - For Unified Repository, Unified Repository Provider calls udmrepo.BackupRepoService’s Maintain function
-
-Kopia has two maintenance modes – the full maintenance and quick maintenance. There are many differences between full and quick mode, but briefly speaking, quick mode only processes the hottest data (primarily, it is the metadata and index data), so quick maintenance is much faster than full maintenance. On the other hand, quick maintenance also scatters the burden of full maintenance so that the full maintenance could finish fastly and make less impact. We will also take this quick maintenance into Velero.  
-We will add a new Due Time to Velero, finally, we have two Prune Due Time:
-- Normal Due Time: For Restic, this will invoke Restic Prune; for Unified Repository, this will invoke udmrepo.BackupRepoService’s Maintain(full) call and finally call Kopia’s full maintenance
-- Quick Due Time: For Restic, this does nothing; for Unified Repository, this will invoke udmrepo.BackupRepoService’s Maintain(quick) call and finally call Kopia’s quick maintenance  
-
-We assign different values to Normal Due Time and Quick Due Time, as a result of which, the quick maintenance happens more frequently than full maintenance.  
-![A Maintenance Workflow](maintenance-workflow.png) 
-
-### Progress Update
-Because Kopia Uploader is an unchanged Kopia module, we need to find a way to get its progress during the BR.  
-Kopia Uploader accepts a Progress interface to update rich information during the BR, so the Kopia Uploader Provider will implement a Kopia’s Progress interface and then pass it to Kopia Uploader during its initialization.  
-In this way, Velero will be able to get the progress as shown in the diagram below.  
-![A Progress Update](progress-update.png) 
-
-### Logs
-In the current design, Velero is using two unchanged Kopia modules --- the Kopia Uploader and the Kopia Repository. Both will generate debug logs during their run. Velero will collect these logs in order to aid the debug.  
-Kopia’s Uploader and Repository both get the Logger information from the current GO Context, therefore, the Kopia Uploader Provider/Kopia Library could set the Logger interface into the current context and pass the context to Kopia Uploader/Kopia Repository.  
-Velero will set Logger interfaces separately for Kopia Uploader and Kopia Repository. In this way, the Unified Repository could serve other data movers without losing the debug log capability; and the Kopia Uploader could write to any repository without losing the debug log capability.  
-Kopia’s debug logs will be written to the same log file as Velero server or VeleroNodeAgent daemonset, so Velero doesn’t need to upload/download these debug logs separately.  
-![A Debug Log for Uploader](debug-log-uploader.png) 
-![A Debug Log for Repository](debug-log-repository.png) 
-
-## Path Switch & Coexist
-As mentioned above, There will be two paths. The related controllers need to identify the path during runtime and adjust its working mode.  
-According to the requirements, path changing is fulfilled at the backup/restore level. In order to let the controllers know the path, we need to add some option values. Specifically, there will be option/mode values for path selection in two places:
-- Add the “uploader-type” option as a parameter of the Velero server. The parameters will be set by the installation. Currently the option has two values, either "restic" or "kopia" (in future, we may add other file system uploaders, then we will have more values).
-- Add a "uploaderType" value in the PodVolume Backup/Restore CR and a "repositoryType" value in the BackupRepository CR. "uploaderType" currently has two values , either "restic" or "kopia";  "repositoryType" currently has two values, either "restic" or "kopia" (in future, the Unified Repository could opt among multiple backup repository/backup storage, so there may be more values. This is a good reason that repositoryType is a multivariate flag, however, in which way to opt among the backup repository/backup storage is not covered in this PR). If the values are missing in the CRs, it by default means "uploaderType=restic" and "repositoryType=restic", so the legacy CRs are handled correctly by Restic.  
-
-The corresponding controllers handle the CRs by checking the CRs' path value. Some examples are as below:
-- The PodVolume BR controller checks the "uploaderType" value from PodVolume CRs and decide its working path
-- The BackupRepository controller checks the "repositoryType" value from BackupRepository CRs and decide its working path
-- The Backup controller that runs in Velero server checks its “uploader-type” parameter to decide the path for the Backup it is going to create and then create the PodVolume Backup CR and BackupRepository CR
-- The Restore controller checks the Backup, from which it is going to restore, for the path and then create the PodVolume Restore CR and BackupRepository CR
-
-As described above, the “uploader-type” parameter of the Velero server is only used to decide the path when creating a new Backup, for other cases, the path selection is driven by the related CRs. Therefore, we only need to add this parameter to the Velero server.  
-
-## Velero CR Name Changes
-We will change below CRs' name to make them more generic:
-- "ResticRepository" CR to "BackupRepository" CR  
-
-This means, we add a new CR type and deprecate the old one. As a result, if users upgrade from the old release, the old CRs will be orphaned, Velero will neither refer to it nor manage it, users need to delete these CRs manually.  
-As a side effect, when upgrading from an old release, even though the path is not changed, the BackupRepository gets created all the time, because Velero will not refer to the old CR's status. This seems to cause the repository to initialize more than once, however, it won't happen. In the BackupRepository controller, before initializing a repository, it always tries to connect to the repository first, if it is connectable, it won't do the initialization.  
-When backing up with the new release, Velero always creates BackupRepository CRs instead of ResticRepository CRs.  
-When restoring from an old backup, Velero always creates BackupRepository CRs instead of ResticRepository CRs.  
-When there are already backups or restores running during the upgrade, since after upgrade, the Velero server pods and VeleroNodeAgent daemonset pods are restarted, the existing backups/restores will fail immediately. 
-
-## Storage Configuration
-The backup repository needs some parameters to connect to various backup storage. For example, for a S3 compatible storage, the parameters may include bucket name, region, endpoint, etc. Different backup storage have totally different parameters. BackupRepository CRs, PodVolume Backup CRs and PodVolume Restore CRs save these parameters in their spec, as a string called repoIdentififer. The format of the string is for S3 storage only, it meets Restic CLI's requirements but is not enough for other backup repository. On the other hand, the parameters that are used to generate the repoIdentififer all come from the BackupStorageLocation. The latter has a map structure that could take parameters from any storage kind.  
-Therefore, for the new path, Velero uses the information in the BackupStorageLocation directly. That is, whenever Velero needs to initialize/connect to the Unified Repository, it acquires the storage configuration from the corresponding BackupStorageLocation. Then no more elements will be added in BackupRepository CRs, PodVolume Backup CRs or PodVolume Restore CRs.  
-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
- - 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
-
- 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:
- ```
-    spec:
-      containers:
-      - args:
-        - server
-        - --features=
-        - --uploader-type=restic
-        command:
-        - /velero
-```
-The BackupRepository CRs and PodVolume Backup/Restore CRs created in this case are as below:
-```
-spec:
-  backupStorageLocation: default
-  maintenanceFrequency: 168h0m0s
-  repositoryType: restic
-  volumeNamespace: nginx-example
-```
-```
-spec:
-  backupStorageLocation: default
-  node: aks-agentpool-27359964-vmss000000
-  pod:
-    kind: Pod
-    name: nginx-stateful-0
-    namespace: nginx-example
-    uid: 86aaec56-2b21-4736-9964-621047717133   
-  tags:
-    ...
-  uploaderType: restic
-  volume: nginx-log
-```
-```
-spec:
-  backupStorageLocation: default
-  pod:
-    kind: Pod
-    name: nginx-stateful-0
-    namespace: nginx-example
-    uid: e56d5872-3d94-4125-bfe8-8a222bf0fcf1
-  snapshotID: 1741e5f1
-  uploaderType: restic
-  volume: nginx-log
-```
- **"Kopia"**: it means Velero will use Kopia uploader to do the pod volume backup (so it will use Unified Repository as the backup target). Therefore, the Velero server deployment will be created as below:
-  ```
-    spec:
-      containers:
-      - args:
-        - server
-        - --features=
-        - --uploader-type=kopia
-        command:
-        - /velero
-```
-The BackupRepository CRs created in this case are hard set with "kopia" at present, sice Kopia is the only option as a backup repository. The PodVolume Backup/Restore CRs are created with "kopia" as well:
-```
-spec:
-  backupStorageLocation: default
-  maintenanceFrequency: 168h0m0s
-  repositoryType: kopia
-  volumeNamespace: nginx-example
-```
-```
-spec:
-  backupStorageLocation: default
-  node: aks-agentpool-27359964-vmss000000
-  pod:
-    kind: Pod
-    name: nginx-stateful-0
-    namespace: nginx-example
-    uid: 86aaec56-2b21-4736-9964-621047717133   
-  tags:
-    ...
-  uploaderType: kopia
-  volume: nginx-log
-```
-```
-spec:
-  backupStorageLocation: default
-  pod:
-    kind: Pod
-    name: nginx-stateful-0
-    namespace: nginx-example
-    uid: e56d5872-3d94-4125-bfe8-8a222bf0fcf1
-  snapshotID: 1741e5f1
-  uploaderType: kopia
-  volume: nginx-log
-```
-We will add the flag for both CLI installation and Helm Chart Installation. Specifically:
-- Helm Chart Installation: add the "--pod-volume-backup-uploader" flag into its value.yaml and then generate the deployments according to the value. Value.yaml is the user-provided configuration file, therefore, users could set this value at the time of installation. The changes in Value.yaml are as below:
-```
-          command:
-            - /velero
-          args:
-            - server
-          {{- with .Values.configuration }}
-            {{- if .pod-volume-backup-uploader "restic" }}
-            - --legacy
-            {{- end }} 
-```     
-- CLI Installation: add the "--pod-volume-backup-uploader" flag into the installation command line, and then create the two deployments accordingly. Users could change the option at the time of installation. The CLI is as below:  
-```velero install --pod-volume-backup-uploader=restic```  
-```velero install --pod-volume-backup-uploader=kopia``` 
-
-## Upgrade
-For upgrade, we allow users to change the path by specifying "--pod-volume-backup-uploader" flag in the same way as the fresh installation. Therefore, the flag change should be applied to the Velero server after upgrade. Additionally, We need to add a label to Velero server to indicate the current path, so as to provide an easy for querying it.  
-Moreover, if users upgrade from the old release, we need to change the existing Restic Daemonset name to VeleroNodeAgent daemonSet. The name change should be applied after upgrade.  
-The recommended way for upgrade is to modify the related Velero resource directly through kubectl, the above changes will be applied in the same way. We need to modify the Velero doc for all these changes.  
-
-## CLI
-Below Velero CLI or its output needs some changes:  
-- ```Velero backup describe```: the output should indicate the path  
-- ```Velero restore describe```: the output should indicate the path  
-- ```Velero restic repo get```: the name of this CLI should be changed to a generic one, for example, "Velero repo get"; the output of this CLI should print all the backup repository if Restic repository and Unified Repository exist at the same time  
-
-At present, we don't have a requirement for selecting the path during backup, so we don't change the ```Velero backup create``` CLI for now. If there is a requirement in future, we could simply add a flag similar to "--pod-volume-backup-uploader" to select the path.  
-
-## CR Example
-Below sample files demonstrate complete CRs with all the changes mentioned above:
-- BackupRepository CR: https://gist.github.com/Lyndon-Li/f38ad69dd8c4785c046cd7ed0ef2b6ed#file-backup-repository-sample-yaml
-- PodVolumeBackup CR: https://gist.github.com/Lyndon-Li/f38ad69dd8c4785c046cd7ed0ef2b6ed#file-pvb-sample-yaml
-- PodVolumeRestore CR: https://gist.github.com/Lyndon-Li/f38ad69dd8c4785c046cd7ed0ef2b6ed#file-pvr-sample-yaml
-
-## 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
-- 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
-
-Below user experiences are changed for this design:
-- Installation CLI change: a new option is added to the installation CLI, see the Installation section for details
-- CR change: One or more existing CRs have been renamed, see the Velero CR Changes section for details
-- Velero CLI name and output change, see the CLI section for details
-- Velero daemonset name change
-- Wording Alignment: as the existing situation, many places are using the word of "Restic", for example, "default-volume-to-restic" option, most of them are not accurate anymore, we will change these words and give a detailed list of the changes  

go.mod

@@ -1,152 +1,47 @@
 module github.com/vmware-tanzu/velero
 
-go 1.18
+go 1.16
 
 require (
-	cloud.google.com/go/storage v1.21.0
-	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/azure-sdk-for-go v42.0.0+incompatible
 	github.com/Azure/go-autorest/autorest v0.11.21
 	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/bombsimon/logrusr/v3 v3.0.0
-	github.com/evanphx/json-patch v5.6.0+incompatible
+	github.com/Azure/go-autorest/autorest/validation v0.2.0 // indirect
+	github.com/aws/aws-sdk-go v1.28.2
+	github.com/evanphx/json-patch v4.11.0+incompatible
 	github.com/fatih/color v1.13.0
 	github.com/gobwas/glob v0.2.3
+	github.com/gofrs/uuid v3.2.0+incompatible
 	github.com/golang/protobuf v1.5.2
-	github.com/google/go-cmp v0.5.8
-	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/google/uuid v1.1.2
+	github.com/hashicorp/go-hclog v0.12.0
+	github.com/hashicorp/go-plugin v0.0.0-20190610192547-a1bc61569a26
 	github.com/joho/godotenv v1.3.0
-	github.com/kopia/kopia v0.10.7
-	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/kubernetes-csi/external-snapshotter/client/v4 v4.0.0
+	github.com/onsi/ginkgo v1.16.4
+	github.com/onsi/gomega v1.16.0
 	github.com/pkg/errors v0.9.1
-	github.com/prometheus/client_golang v1.12.2
+	github.com/prometheus/client_golang v1.11.0
 	github.com/robfig/cron v1.1.0
 	github.com/sirupsen/logrus v1.8.1
 	github.com/spf13/afero v1.6.0
-	github.com/spf13/cobra v1.4.0
+	github.com/spf13/cobra v1.2.1
 	github.com/spf13/pflag v1.0.5
-	github.com/stretchr/testify v1.7.1
+	github.com/stretchr/testify v1.7.0
 	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
-	k8s.io/apiextensions-apiserver v0.24.2
-	k8s.io/apimachinery v0.24.2
-	k8s.io/cli-runtime v0.24.0
-	k8s.io/client-go v0.24.2
-	k8s.io/klog/v2 v2.60.1
+	golang.org/x/mod v0.4.2
+	golang.org/x/net v0.0.0-20210520170846-37e1c6afe023
+	google.golang.org/grpc v1.40.0
+	k8s.io/api v0.22.2
+	k8s.io/apiextensions-apiserver v0.22.2
+	k8s.io/apimachinery v0.22.2
+	k8s.io/cli-runtime v0.22.2
+	k8s.io/client-go v0.22.2
+	k8s.io/klog v1.0.0
 	k8s.io/kube-aggregator v0.19.12
-	k8s.io/utils v0.0.0-20220210201930-3a6ce19ff2f9
-	sigs.k8s.io/controller-runtime v0.12.2
-	sigs.k8s.io/yaml v1.3.0
+	sigs.k8s.io/cluster-api v1.0.0
+	sigs.k8s.io/controller-runtime v0.10.2
 )
 
-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
-	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/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/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/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/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/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/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/pgzip v1.2.5 // indirect
-	github.com/kr/pretty v0.3.0 // 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-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/minio/md5-simd v1.1.2 // indirect
-	github.com/minio/minio-go/v7 v7.0.23 // 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
-	github.com/moby/spdystream v0.2.0 // indirect
-	github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd // indirect
-	github.com/modern-go/reflect2 v1.0.2 // indirect
-	github.com/munnerz/goautoneg v0.0.0-20191010083416-a7dc8b61c822 // indirect
-	github.com/natefinch/atomic v1.0.1 // indirect
-	github.com/nxadm/tail v1.4.8 // indirect
-	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/vladimirvivien/gexe v0.1.1 // indirect
-	github.com/zeebo/blake3 v0.2.3 // indirect
-	go.opencensus.io v0.23.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
-	golang.org/x/time v0.0.0-20220609170525-579cf78fd858 // indirect
-	golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1 // 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
-	gopkg.in/inf.v0 v0.9.1 // indirect
-	gopkg.in/ini.v1 v1.66.2 // 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
-)
+replace github.com/gogo/protobuf => github.com/gogo/protobuf v1.3.2

golangci.yaml

@@ -25,8 +25,8 @@ run:
   # from this option's value (see skip-dirs-use-default).
   # "/" will be replaced by current OS file path separator to properly work
   # on Windows.
-  skip-dirs:
-    - test/e2e/*
+  #skip-dirs:
+  #  - src/external_libs
   #  - autogenerated_by_my_lib
 
   # default is true. Enables skipping of directories:
@@ -39,8 +39,8 @@ run:
   # autogenerated files. If it's not please let us know.
   # "/" will be replaced by current OS file path separator to properly work
   # on Windows.
-  skip-files:
-    - ".*_test.go$"
+  # skip-files:
+  #  - ".*\\.my\\.go$"
   #  - lib/bad.go
 
   # by default isn't set. If set we pass it to "go list -mod={option}". From "go help modules":
@@ -117,7 +117,7 @@ linters-settings:
     # minimal length of string constant, 3 by default
     min-len: 3
     # minimal occurrences count to trigger, 3 by default
-    min-occurrences: 5
+    min-occurrences: 3
   gocritic:
     # Which checks should be enabled; can't be combined with 'disabled-checks';
     # See https://go-critic.github.io/overview#checks-overview
@@ -320,7 +320,7 @@ linters:
   fast: false
 
 
-issues:
+#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
@@ -359,7 +359,7 @@ issues:
   # 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
+  exclude-use-default: false
 
   # The default value is false. If set to true exclude and exclude-rules
   # regular expressions become case sensitive.

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 golang:1.16
 
 ARG GOPROXY
 
@@ -20,30 +20,34 @@ ENV GO111MODULE=on
 # Use a proxy for go modules to reduce the likelihood of various hosts being down and breaking the build
 ENV GOPROXY=${GOPROXY}
 
-# kubebuilder test bundle is separated from kubebuilder. Need to setup it for CI test.
-RUN curl -sSLo envtest-bins.tar.gz https://go.kubebuilder.io/test-tools/1.22.1/linux/amd64 && \
-    mkdir /usr/local/kubebuilder && \
-    tar -C /usr/local/kubebuilder --strip-components=1 -zvxf envtest-bins.tar.gz
+# get code-generation tools (for now keep in GOPATH since they're not fully modules-compatible yet)
+RUN mkdir -p /go/src/k8s.io
+WORKDIR /go/src/k8s.io
+RUN git config --global advice.detachedHead false
+RUN git clone -b v0.18.4 https://github.com/kubernetes/code-generator
 
-RUN wget --quiet https://github.com/kubernetes-sigs/kubebuilder/releases/download/v3.2.0/kubebuilder_linux_amd64 && \
-    mv kubebuilder_linux_amd64 /usr/local/kubebuilder/bin/kubebuilder && \
-    chmod +x /usr/local/kubebuilder/bin/kubebuilder
+RUN wget --quiet https://github.com/kubernetes-sigs/kubebuilder/releases/download/v2.3.1/kubebuilder_2.3.1_linux_amd64.tar.gz && \
+    tar -zxvf kubebuilder_2.3.1_linux_amd64.tar.gz && \
+    mv kubebuilder_2.3.1_linux_amd64 /usr/local/kubebuilder && \
+    chmod +x /usr/local/kubebuilder && \
+    export PATH=$PATH:/usr/local/kubebuilder/bin && \
+    rm kubebuilder_2.3.1_linux_amd64.tar.gz
 
 # get controller-tools
-RUN go install sigs.k8s.io/controller-tools/cmd/controller-gen@v0.7.0
+RUN go get sigs.k8s.io/controller-tools/cmd/controller-gen@v0.3.0
 
 # get goimports (the revision is pinned so we don't indiscriminately update, but the particular commit
 # is not important)
-RUN go install golang.org/x/tools/cmd/goimports@11e9d9cc0042e6bd10337d4d2c3e5d9295508e7d
+RUN go get golang.org/x/tools/cmd/goimports@11e9d9cc0042e6bd10337d4d2c3e5d9295508e7d
 
 # get protoc compiler and golang plugin
 WORKDIR /root
 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 && \
+RUN wget --quiet https://github.com/protocolbuffers/protobuf/releases/download/v3.9.1/protoc-3.9.1-linux-x86_64.zip && \
+    unzip protoc-3.9.1-linux-x86_64.zip && \
     mv bin/protoc /usr/bin/protoc && \
     chmod +x /usr/bin/protoc
-RUN go install github.com/golang/protobuf/protoc-gen-go@v1.4.3
+RUN go get github.com/golang/protobuf/protoc-gen-go@v1.0.0
 
 # get goreleaser
 RUN wget --quiet https://github.com/goreleaser/goreleaser/releases/download/v0.120.8/goreleaser_Linux_x86_64.tar.gz && \
@@ -52,7 +56,7 @@ RUN wget --quiet https://github.com/goreleaser/goreleaser/releases/download/v0.1
     chmod +x /usr/bin/goreleaser
 
 # get golangci-lint
-RUN curl -sSfL https://raw.githubusercontent.com/golangci/golangci-lint/master/install.sh | sh -s -- -b $(go env GOPATH)/bin v1.51.0
+RUN curl -sSfL https://raw.githubusercontent.com/golangci/golangci-lint/master/install.sh | sh -s -- -b $(go env GOPATH)/bin v1.27.0
 
 # install kubectl
 RUN curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl

hack/ci/build_util.sh

@@ -1,9 +0,0 @@
-#!/bin/bash
-set -x
-
-set -e
-
-function uploader {
-    gsutil cp $1 gs://$2/$1
-    gsutil -D setacl public-read gs://$2/$1 &> /dev/null
-}

hack/crd-gen/v1beta1/main.go

@@ -0,0 +1,136 @@
+/*
+Copyright the Velero contributors.
+
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+    http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+*/
+
+// This code embeds the CRD manifests in config/crd/v1beta1/bases in
+// config/crd/v1beta1/crds/crds.go.
+
+package main
+
+import (
+	"bytes"
+	"compress/gzip"
+	"fmt"
+	"io"
+	"io/ioutil"
+	"log"
+	"os"
+	"text/template"
+)
+
+// This is relative to config/crd/crds
+const goHeaderFile = "../../../../hack/boilerplate.go.txt"
+
+const tpl = `{{.GoHeader}}
+// Code generated by crds_generate.go; DO NOT EDIT.
+
+package crds
+
+import (
+	"bytes"
+	"compress/gzip"
+	"io/ioutil"
+
+	apiextinstall "k8s.io/apiextensions-apiserver/pkg/apis/apiextensions/install"
+	apiextv1beta1 "k8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1beta1"
+	"k8s.io/client-go/kubernetes/scheme"
+)
+
+var rawCRDs = [][]byte{
+{{- range .RawCRDs }}
+	[]byte({{ . }}),
+{{- end }}
+}
+
+var CRDs = crds()
+
+func crds() []*apiextv1beta1.CustomResourceDefinition {
+	apiextinstall.Install(scheme.Scheme)
+	decode := scheme.Codecs.UniversalDeserializer().Decode
+	var objs []*apiextv1beta1.CustomResourceDefinition
+	for _, crd := range rawCRDs {
+		gzr, err := gzip.NewReader(bytes.NewReader(crd))
+		if err != nil {
+			panic(err)
+		}
+		bytes, err := ioutil.ReadAll(gzr)
+		if err != nil {
+			panic(err)
+		}
+		gzr.Close()
+
+		obj, _, err := decode(bytes, nil, nil)
+		if err != nil {
+			panic(err)
+		}
+		objs = append(objs, obj.(*apiextv1beta1.CustomResourceDefinition))
+	}
+	return objs
+}
+`
+
+type templateData struct {
+	GoHeader string
+	RawCRDs  []string
+}
+
+func main() {
+	headerBytes, err := ioutil.ReadFile(goHeaderFile)
+	if err != nil {
+		log.Fatalln(err)
+	}
+
+	data := templateData{
+		GoHeader: string(headerBytes),
+	}
+
+	// This is relative to config/crd/crds
+	manifests, err := ioutil.ReadDir("../bases")
+	if err != nil {
+		log.Fatalln(err)
+	}
+
+	for _, crd := range manifests {
+		file, err := os.Open("../bases/" + crd.Name())
+		if err != nil {
+			log.Fatalln(err)
+		}
+
+		// gzip compress manifest
+		var buf bytes.Buffer
+		gzw := gzip.NewWriter(&buf)
+		if _, err := io.Copy(gzw, file); err != nil {
+			log.Fatalln(err)
+		}
+		file.Close()
+		gzw.Close()
+
+		data.RawCRDs = append(data.RawCRDs, fmt.Sprintf("%q", buf.Bytes()))
+	}
+
+	t, err := template.New("crd").Parse(tpl)
+	if err != nil {
+		log.Fatalln(err)
+	}
+
+	out, err := os.Create("crds.go")
+	if err != nil {
+		log.Fatalln(err)
+	}
+
+	if err := t.Execute(out, data); err != nil {
+		log.Fatalln(err)
+	}
+}

hack/docker-push.sh

@@ -56,36 +56,26 @@ elif [[ "$triggeredBy" == "tags" ]]; then
     TAG=$(echo $GITHUB_REF | cut -d / -f 3)
 fi
 
-# if both BRANCH and TAG are empty, then it's triggered by PR. Use target branch instead.
-# BRANCH is needed in docker buildx command to set as image tag.
-# When action is triggered by PR, just build container without pushing, so set type to local.
-# When action is triggered by PUSH, need to push container, so set type to registry.
-if [[ -z $BRANCH && -z $TAG ]]; then
-    echo "Test Velero container build without pushing, when Dockerfile is changed by PR."
-    BRANCH="${GITHUB_BASE_REF}-container"
-    OUTPUT_TYPE="local,dest=."
-else
-    OUTPUT_TYPE="registry"
-fi
-
-TAG_LATEST=false
-if [[ ! -z "$TAG" ]]; then
-    echo "We're building tag $TAG"
-    VERSION="$TAG"
+if [[ "$BRANCH" == "main" ]]; then
+    VERSION="$BRANCH"
+elif [[ ! -z "$TAG" ]]; then
     # Explicitly checkout tags when building from a git tag.
     # This is not needed when building from main
     git fetch --tags
     # Calculate the latest release if there's a tag.
     highest_release
-    if [[ "$TAG" == "$HIGHEST" ]]; then
-      TAG_LATEST=true
-    fi
+    VERSION="$TAG"
 else
-    echo "We're on branch $BRANCH"
-    VERSION="$BRANCH"
-    if [[ "$VERSION" == release-* ]]; then
-      VERSION=${VERSION}-dev
-    fi
+    echo "We're not on main and we're not building a tag, exit early."
+    exit 0
+fi
+
+# Assume we're not tagging `latest` by default, and never on main.
+TAG_LATEST=false
+if [[ "$BRANCH" == "main" ]]; then
+    echo "Building main, not tagging latest."
+elif [[ "$TAG" == "$HIGHEST" ]]; then
+    TAG_LATEST=true
 fi
 
 if [[ -z "$BUILDX_PLATFORMS" ]]; then
@@ -97,14 +87,15 @@ echo "Highest tag found: $HIGHEST"
 echo "BRANCH: $BRANCH"
 echo "TAG: $TAG"
 echo "TAG_LATEST: $TAG_LATEST"
-echo "VERSION: $VERSION"
 echo "BUILDX_PLATFORMS: $BUILDX_PLATFORMS"
 
 echo "Building and pushing container images."
 
+# The use of "registry" as the buildx output type below instructs
+# Docker to push the image
 
 VERSION="$VERSION" \
 TAG_LATEST="$TAG_LATEST" \
 BUILDX_PLATFORMS="$BUILDX_PLATFORMS" \
-BUILDX_OUTPUT_TYPE=$OUTPUT_TYPE \
+BUILDX_OUTPUT_TYPE="registry" \
 make all-containers

hack/download-restic.sh

@@ -22,7 +22,6 @@ set -o pipefail
 # is the path expected by the Velero Dockerfile.
 output_dir=${OUTPUT_DIR:-/output/usr/bin}
 restic_bin=${output_dir}/restic
-build_path=$(dirname "$PWD")
 
 if [[ -z "${BIN}" ]]; then
     echo "BIN must be set"
@@ -47,10 +46,8 @@ if [[ -z "${RESTIC_VERSION}" ]]; then
     exit 1
 fi
 
-mkdir ${build_path}/restic
-git clone -b v${RESTIC_VERSION} https://github.com/restic/restic.git ${build_path}/restic
-pushd ${build_path}/restic
-git apply /go/src/github.com/vmware-tanzu/velero/hack/fix_restic_cve.txt
-go run build.go --goos "${GOOS}" --goarch "${GOARCH}" --goarm "${GOARM}" -o ${restic_bin}
+curl -s -L https://github.com/restic/restic/releases/download/v${RESTIC_VERSION}/restic_${RESTIC_VERSION}_${GOOS}_${GOARCH}.bz2 -O
+bunzip2 restic_${RESTIC_VERSION}_${GOOS}_${GOARCH}.bz2
+mv restic_${RESTIC_VERSION}_${GOOS}_${GOARCH} ${restic_bin}
+
 chmod +x ${restic_bin}
-popd

hack/fix_restic_cve.txt

@@ -1,60 +0,0 @@
-diff --git a/go.mod b/go.mod
-index 5f939c481..6f281b45d 100644
---- a/go.mod
-+++ b/go.mod
-@@ -25,12 +25,12 @@ require (
- 	github.com/spf13/cobra v1.6.1
- 	github.com/spf13/pflag v1.0.5
- 	golang.org/x/crypto v0.5.0
--	golang.org/x/net v0.5.0
-+	golang.org/x/net v0.7.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
- 	google.golang.org/api v0.106.0
- )
- 
-diff --git a/go.sum b/go.sum
-index 026e1d2fa..da35b7a6c 100644
---- a/go.sum
-+++ b/go.sum
-@@ -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/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=
-@@ -214,17 +214,17 @@ golang.org/x/sys v0.0.0-20211216021012-1d35b9e2eb4e/go.mod h1:oPkhp1MJrh7nUepCBc
- golang.org/x/sys v0.0.0-20220408201424-a24fb2fb8a0f/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.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/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/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/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/release-tools/chk_version.go

@@ -24,7 +24,6 @@ import (
 
 // This regex should match both our GA format (example: v1.4.3) and pre-release formats (v1.2.4-beta.2, v1.5.0-rc.1)
 // The following sub-capture groups are defined:
-//
 //	major
 //	minor
 //	patch

hack/release-tools/tag-release.sh

@@ -38,9 +38,6 @@
 # This script is meant to be a combination of documentation and executable.
 # If you have questions at any point, please stop and ask!
 
-# Fail on any error.
-set -eo pipefail
-
 # Directory in which the script itself resides, so we can use it for calling programs that are in the same directory.
 DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" >/dev/null 2>&1 && pwd )"
 
@@ -95,7 +92,7 @@ eval $(go run $DIR/chk_version.go)
 printf "To clarify, you've provided a version string of $VELERO_VERSION.\n"
 printf "Based on this, the following assumptions have been made: \n"
 
-# $VELERO_PATCH gets populated by the chk_version.go script that parses and verifies the given version format
+# $VELERO_PATCH gets populated by the chk_version.go scrip that parses and verifies the given version format
 # If we've got a patch release, we assume the tag is on release branch.
 if [[ "$VELERO_PATCH" != 0 ]]; then
     printf "*\t This is a patch release.\n"
@@ -138,8 +135,8 @@ if [[ -n $release_branch_name ]]; then
     remote_release_branch_name="$remote/$release_branch_name"
 
     # Determine whether the local and remote release branches already exist
-    local_branch=$(git branch | { grep "$release_branch_name" || true; })
-    remote_branch=$(git branch -r | { grep "$remote_release_branch_name" || true;})
+    local_branch=$(git branch | grep "$release_branch_name")
+    remote_branch=$(git branch -r | grep "$remote_release_branch_name")
     if [[ -z $remote_branch ]]; then
         echo "The branch $remote_release_branch_name must be created before you tag the release."
         exit 1

hack/restore-crd-patch-v1.json

@@ -0,0 +1,3 @@
+[
+    { "op": "replace", "path": "/spec/versions/0/schema/openAPIV3Schema/properties/spec/properties/hooks/properties/resources/items/properties/postHooks/items/properties/init/properties/initContainers/items/properties/ports/items/required", "value": [ "containerPort", "protocol"] }
+]

hack/restore-crd-patch-v1beta1.json

@@ -0,0 +1,3 @@
+[
+    { "op": "replace", "path": "/spec/validation/openAPIV3Schema/properties/spec/properties/hooks/properties/resources/items/properties/postHooks/items/properties/init/properties/initContainers/items/properties/ports/items/required", "value": [ "containerPort", "protocol"] }
+]

hack/test.sh

@@ -43,5 +43,5 @@ fi
 # but the user and group don't exist inside the container, when the code(https://github.com/kubernetes-sigs/controller-runtime/blob/v0.10.2/pkg/internal/testing/addr/manager.go#L44)
 # tries to get the cache directory, it gets the directory "/" and then get the permission error when trying to create directory under "/".
 # Specifying the cache directory by environment variable "XDG_CACHE_HOME" to workaround it
-XDG_CACHE_HOME=/tmp/ go test -installsuffix "static" -short -timeout 60s -coverprofile=coverage.out "${TARGETS[@]}"
+XDG_CACHE_HOME=/tmp/ go test -installsuffix "static" -short -timeout 60s "${TARGETS[@]}"
 echo "Success!"

hack/update-3generated-crd-code.sh

@@ -1,59 +0,0 @@
-#!/bin/bash
-#
-# Copyright the Velero contributors.
-#
-# Licensed under the Apache License, Version 2.0 (the "License");
-# you may not use this file except in compliance with the License.
-# You may obtain a copy of the License at
-#
-#     http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing, software
-# distributed under the License is distributed on an "AS IS" BASIS,
-# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-# See the License for the specific language governing permissions and
-# limitations under the License.
-
-set -o errexit
-set -o nounset
-set -o pipefail
-set -o xtrace
-
-# this script expects to be run from the root of the Velero repo.
-
-if [[ -z "${GOPATH}" ]]; then
-  GOPATH=~/go
-fi
-
-if ! command -v controller-gen > /dev/null; then
-  echo "controller-gen is missing"
-  exit 1
-fi
-
-# get code-generation tools (for now keep in GOPATH since they're not fully modules-compatible yet)
-mkdir -p ${GOPATH}/src/k8s.io
-pushd ${GOPATH}/src/k8s.io
-git clone -b v0.22.2 https://github.com/kubernetes/code-generator
-popd
-
-${GOPATH}/src/k8s.io/code-generator/generate-groups.sh \
-  all \
-  github.com/vmware-tanzu/velero/pkg/generated \
-  github.com/vmware-tanzu/velero/pkg/apis \
-  "velero:v1" \
-  --go-header-file ./hack/boilerplate.go.txt \
-  --output-base ../../.. \
-  $@
-
-# Generate apiextensions.k8s.io/v1
-# Generate manifests e.g. CRD, RBAC etc.
-controller-gen \
-  crd:crdVersions=v1 \
-  paths=./pkg/apis/velero/v1/... \
-  rbac:roleName=velero-perms \
-  paths=./pkg/controller/... \
-  output:crd:artifacts:config=config/crd/v1/bases \
-  object \
-  paths=./pkg/apis/velero/v1/...
-
-go generate ./config/crd/v1/crds

hack/update-generated-crd-code.sh

@@ -0,0 +1,67 @@
+#!/bin/bash
+#
+# Copyright the Velero contributors.
+#
+# Licensed under the Apache License, Version 2.0 (the "License");
+# you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+#
+#     http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+
+set -o errexit
+set -o nounset
+set -o pipefail
+set -o xtrace
+
+# this script expects to be run from the root of the Velero repo.
+
+if [[ -z "${GOPATH}" ]]; then
+  GOPATH=~/go
+fi
+
+if [[ ! -d "${GOPATH}/src/k8s.io/code-generator" ]]; then
+  echo "k8s.io/code-generator missing from GOPATH"
+  exit 1
+fi
+
+if ! command -v controller-gen > /dev/null; then
+  echo "controller-gen is missing"
+  exit 1
+fi
+
+${GOPATH}/src/k8s.io/code-generator/generate-groups.sh \
+  all \
+  github.com/vmware-tanzu/velero/pkg/generated \
+  github.com/vmware-tanzu/velero/pkg/apis \
+  "velero:v1" \
+  --go-header-file ./hack/boilerplate.go.txt \
+  --output-base ../../.. \
+  $@
+
+# Generate both apiextensions.k8s.io/v1beta1 and apiextensions.k8s.io/v1
+for version in v1beta1 v1
+do
+  # Generate manifests e.g. CRD, RBAC etc.
+  controller-gen \
+    crd:crdVersions=$version,preserveUnknownFields=false,trivialVersions=true \
+    paths=./pkg/apis/velero/v1/... \
+    paths=./pkg/controller/... \
+    output:crd:artifacts:config=config/crd/$version/bases
+
+  # this is a super hacky workaround for https://github.com/kubernetes/kubernetes/issues/91395
+  # which a result of fixing the validation on CRD objects. The validation ensures the fields that are list map keys, are either marked
+  # as required or have default values to ensure merging of list map items work as expected.
+  # With "containerPort" and "protocol" being considered as x-kubernetes-list-map-keys in the container ports, and "protocol" was not
+  # a required field, the CRD would fail validation with errors similar to the one reported in https://github.com/kubernetes/kubernetes/issues/91395.
+  # once controller-gen (above) is able to generate CRDs with `protocol` as a required field, this hack can be removed.
+  kubectl patch -f config/crd/$version/bases/velero.io_restores.yaml -p "$(cat hack/restore-crd-patch-$version.json)" --type=json --local=true -o yaml > /tmp/velero.io_restores-yaml.patched
+  mv /tmp/velero.io_restores-yaml.patched config/crd/$version/bases/velero.io_restores.yaml
+
+  go generate ./config/crd/$version/crds
+done