Merge remote-tracking branch 'upstream/main'

Signed-off-by: MatthieuFin <matthieu2717@gmail.com>
This commit is contained in:
MatthieuFin
2022-02-23 15:03:15 +01:00
442 changed files with 25774 additions and 6017 deletions
+5 -2
View File
@@ -10,10 +10,13 @@ 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**:
**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 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`
_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>`
+2
View File
@@ -15,6 +15,8 @@ reviewers:
- sseago
- reasonerjt
- ywk253100
- blackpiglet
- qiuming-best
tech-writer:
- a-mccarthy
+1 -1
View File
@@ -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`.
- [ ] [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.
- [ ] Updated the corresponding documentation in `site/content/docs/main`.
+6
View File
@@ -14,9 +14,15 @@ 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
-1
View File
@@ -57,7 +57,6 @@ 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
+15 -2
View File
@@ -14,7 +14,7 @@ jobs:
- name: Set up Go
uses: actions/setup-go@v2
with:
go-version: 1.16
go-version: 1.17
id: go
# Look for a CLI that's made for this PR
- name: Fetch built CLI
@@ -69,8 +69,14 @@ jobs:
- 1.20.2
- 1.21.1
- 1.22.0
- 1.23.0
fail-fast: false
steps:
- name: Set up Go
uses: actions/setup-go@v2
with:
go-version: 1.17
id: go
- name: Check out the code
uses: actions/checkout@v2
- name: Install MinIO
@@ -116,4 +122,11 @@ jobs:
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 VELERO_IMAGE=velero:pr-test \
make -C test/e2e run
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*
+1 -1
View File
@@ -8,7 +8,7 @@ jobs:
- name: Set up Go
uses: actions/setup-go@v2
with:
go-version: 1.16
go-version: 1.17
id: go
- name: Check out the code
uses: actions/checkout@v2
+1 -1
View File
@@ -16,7 +16,7 @@ jobs:
- name: Set up Go
uses: actions/setup-go@v2
with:
go-version: 1.16
go-version: 1.17
id: go
- name: Check out code into the Go module directory
+1 -3
View File
@@ -27,11 +27,9 @@ builds:
- arm64
- ppc64le
ignore:
# don't build arm/arm64 for darwin or windows
# don't build arm for darwin and arm/arm64 for windows
- goos: darwin
goarch: arm
- goos: darwin
goarch: arm64
- goos: darwin
goarch: ppc64le
- goos: windows
+9 -3
View File
@@ -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
@@ -56,8 +56,11 @@ 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.
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>
## 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].
@@ -110,3 +113,6 @@ 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/
+3 -1
View File
@@ -1,7 +1,8 @@
## Current release:
* [CHANGELOG-1.6.md][16]
* [CHANGELOG-1.7.md][17]
## Older releases:
* [CHANGELOG-1.6.md][16]
* [CHANGELOG-1.5.md][15]
* [CHANGELOG-1.4.md][14]
* [CHANGELOG-1.3.md][13]
@@ -19,6 +20,7 @@
* [CHANGELOG-0.3.md][1]
[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
[14]: https://github.com/vmware-tanzu/velero/blob/main/changelogs/CHANGELOG-1.4.md
+1 -1
View File
@@ -11,7 +11,7 @@
# 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.
FROM --platform=$BUILDPLATFORM golang:1.16 as builder-env
FROM --platform=$BUILDPLATFORM golang:1.17 as builder-env
ARG GOPROXY
ARG PKG
+6 -3
View File
@@ -6,12 +6,13 @@
| Maintainer | GitHub ID | Affiliation |
| --------------- | --------- | ----------- |
| 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/) |
| Dave Smith-Uchida | [dsu-igeek](https://github.com/dsu-igeek) | [Kasten](https://github.com/kastenhq/) |
| 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/) |
## Emeritus Maintainers
* Adnan Abdulhussein ([prydonius](https://github.com/prydonius))
@@ -21,12 +22,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))
## Velero Contributors & Stakeholders
| Feature Area | Lead |
| ----------------------------- | :---------------------: |
| Technical Lead | Dave Smith-Uchida (dsu-igeek) |
| Architect | Dave Smith-Uchida (dsu-igeek) |
| Technical Lead | Daniel Jiang (reasonerjt) |
| Kubernetes CSI Liaison | |
| Deployment | JenTing Hsiao (jenting) |
| Community Management | Jonas Rosland (jonasrosland) |
+7 -7
View File
@@ -81,10 +81,10 @@ buildx not enabled, refusing to run this recipe
see: https://velero.io/docs/main/build-from-source/#making-images-and-updating-velero for more info
endef
# The version of restic binary to be downloaded for power architecture
RESTIC_VERSION ?= 0.12.0
# The version of restic binary to be downloaded
RESTIC_VERSION ?= 0.12.1
CLI_PLATFORMS ?= linux-amd64 linux-arm linux-arm64 darwin-amd64 windows-amd64 linux-ppc64le
CLI_PLATFORMS ?= linux-amd64 linux-arm linux-arm64 darwin-amd64 darwin-arm64 windows-amd64 linux-ppc64le
BUILDX_PLATFORMS ?= $(subst -,/,$(ARCH))
BUILDX_OUTPUT_TYPE ?= docker
@@ -338,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
@@ -359,11 +359,11 @@ 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
.PHONY: test-e2e
test-e2e: local
$(MAKE) -C test/e2e run
$(MAKE) -e VERSION=$(VERSION) -C test/e2e run
-7
View File
@@ -1,7 +0,0 @@
domain: io
repo: github.com/vmware-tanzu/velero
resources:
- group: velero
kind: BackupStorageLocation
version: v1
version: "2"
+12
View File
@@ -34,6 +34,18 @@ 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 | Kubernetes versions|
|----------------|--------------------|
| 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 |
[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
+22 -27
View File
@@ -15,33 +15,28 @@ We work with and rely on community feedback to focus our efforts to improve Vele
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: July 2021`
`Last Updated: October 2021`
#### 1.7.0 Roadmap (to be delivered early fall)
The release roadmap is split into Core items that are required for the release and desired items that may slip the release.
#### 1.8.0 Roadmap (to be delivered January/February 2021)
##### Core items
The top priority of 1.7 is to increase the technical health of Velero and be more efficient with Velero developer time by streamlining the release process and automating and expanding the E2E test suite.
|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.|
|Issue|Description|
|---|---|
||Streamline release process|
||Automate the running of the E2E tests|
||Convert pre-release manual tests to automated E2E tests|
|[3493](https://github.com/vmware-tanzu/velero/issues/3493)|[Carvel](https://github.com/vmware-tanzu/velero/issues/3493) based installation (in addition to the existing *velero install* CLI).|
|[675](https://github.com/vmware-tanzu/velero/issues/675)|Velero command to generate debugging information. Will integrate with [Crashd - Crash Diagnostics](https://github.com/vmware-tanzu/velero/issues/675)|
|[3285](https://github.com/vmware-tanzu/velero/issues/3285)|Design doc for Velero plugin versioning|
|[1975](https://github.com/vmware-tanzu/velero/issues/1975)|IPV6 support|
|[3533](https://github.com/vmware-tanzu/velero/issues/3533)|Upload Progress Monitoring|
|[3500](https://github.com/vmware-tanzu/velero/issues/3500)|Use distroless containers as a base|
##### Items formerly in 1.7 that will slip due to staffing changes
|Issue|Description|
|---|---|
|[3536](https://github.com/vmware-tanzu/velero/issues/3536)|Manifest for backup/restore|
|[2066](https://github.com/vmware-tanzu/velero/issues/2066)|CSI Snapshots GA|
|[3535](https://github.com/vmware-tanzu/velero/issues/3535)|Design doc for multiple cluster support|
|[2922](https://github.com/vmware-tanzu/velero/issues/2922)|Plugin timeouts|
|[3531](https://github.com/vmware-tanzu/velero/issues/3531)|Test plan for Velero|
Other work may make it into the 1.8 release, but this is the work that will be prioritized first.
+5 -5
View File
@@ -16,7 +16,7 @@ k8s_yaml([
# default values
settings = {
"default_registry": "",
"default_registry": "docker.io/velero",
"enable_restic": False,
"enable_debug": False,
"debug_continue_on_start": True, # Continue the velero process by default when in debug mode
@@ -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.16.6 as tilt-helper
FROM golang:1.17 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 && \
@@ -90,20 +90,20 @@ def get_debug_flag():
# Set up a local_resource build of the Velero binary. The binary is written to _tiltbuild/velero.
local_resource(
"velero_server_binary",
cmd = 'cd ' + '.' + ';mkdir -p _tiltbuild;PKG=. BIN=velero GOOS=linux GOARCH=amd64 GIT_SHA=' + git_sha + ' VERSION=main GIT_TREE_STATE=dirty OUTPUT_DIR=_tiltbuild ' + get_debug_flag() + ' ./hack/build.sh',
cmd = 'cd ' + '.' + ';mkdir -p _tiltbuild;PKG=. BIN=velero GOOS=linux GOARCH=amd64 GIT_SHA=' + git_sha + ' VERSION=main GIT_TREE_STATE=dirty OUTPUT_DIR=_tiltbuild ' + get_debug_flag() + ' REGISTRY=' + settings.get("default_registry") + ' ./hack/build.sh',
deps = ["cmd", "internal", "pkg"],
ignore = ["pkg/cmd"],
)
local_resource(
"velero_local_binary",
cmd = 'cd ' + '.' + ';mkdir -p _tiltbuild/local;PKG=. BIN=velero GOOS=' + local_goos + ' GOARCH=amd64 GIT_SHA=' + git_sha + ' VERSION=main GIT_TREE_STATE=dirty OUTPUT_DIR=_tiltbuild/local ' + get_debug_flag() + ' ./hack/build.sh',
cmd = 'cd ' + '.' + ';mkdir -p _tiltbuild/local;PKG=. BIN=velero GOOS=' + local_goos + ' GOARCH=amd64 GIT_SHA=' + git_sha + ' VERSION=main GIT_TREE_STATE=dirty OUTPUT_DIR=_tiltbuild/local ' + get_debug_flag() + ' REGISTRY=' + settings.get("default_registry") + ' ./hack/build.sh',
deps = ["internal", "pkg/cmd"],
)
local_resource(
"restic_binary",
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',
cmd = 'cd ' + '.' + ';mkdir -p _tiltbuild/restic; BIN=velero GOOS=linux 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
+80
View File
@@ -0,0 +1,80 @@
## v1.7.0
### 2021-09-07
### Download
https://github.com/vmware-tanzu/velero/releases/tag/v1.7.0
### Container Image
`velero/velero:v1.7.0`
### Documentation
https://velero.io/docs/v1.7/
### Upgrading
https://velero.io/docs/v1.7/upgrade-to-1.7/
### Highlights
#### Distroless images
The Velero container images now use [distroless base images](https://github.com/GoogleContainerTools/distroless).
Using distroless images as the base ensures that only the packages and programs necessary for running Velero are included.
Unrelated libraries and OS packages, that often contain security vulnerabilities, are now excluded.
This change reduces the size of both the server and restic restore helper image by approximately 62MB.
As the [distroless](https://github.com/GoogleContainerTools/distroless) images do not contain a shell, it will no longer be possible to exec into Velero containers using these images.
#### New "debug" command
This release introduces the new `velero debug` command.
This command collects information about a Velero installation, such as pod logs and resources managed by Velero, in a tarball which can be provided to the Velero maintainer team to help diagnose issues.
### All changes
* Distinguish between different unnamed node ports when preserving (#4026, @sseago)
* Validate namespace in Velero backup create command (#4057, @codegold79)
* Empty the "ClusterIPs" along with "ClusterIP" when "ClusterIP" isn't "None" (#4101, @ywk253100)
* Add a RestoreItemAction plugin (`velero.io/apiservice`) which skips the restore of any `APIService` which is managed by Kubernetes. These are identified using the `kube-aggregator.kubernetes.io/automanaged` label. (#4028, @zubron)
* Change the base image to distroless (#4055, @ywk253100)
* Updated the version of velero/velero-plugin-for-aws version from v1.2.0 to v1.2.1 (#4064, @kahirokunn)
* Skip the backup and restore of DownwardAPI volumes when using restic. (#4076, @zubron)
* Bump up Go to 1.16 (#3990, @reasonerjt)
* Fix restic error when volume is emptyDir and Pod not running (#3993, @mahaupt)
* Select the velero deployment with both label and container name (#3996, @ywk253100)
* Wait for the namespace to be deleted before removing the CRDs during uninstall. This deprecates the `--wait` flag of the `uninstall` command (#4007, @ywk253100)
* Use the cluster preferred CRD API version when polling for Velero CRD readiness. (#4015, @zubron)
* Implement velero debug (#4022, @reasonerjt)
* Skip the restore of volumes that originally came from a projected volume when using restic. (#3877, @zubron)
* Run the E2E test with kind(provision various versions of k8s cluster) and MinIO on Github Action (#3912, @ywk253100)
* Fix -install-velero flag for e2e tests (#3919, @jaidevmane)
* Upgrade Velero ClusterRoleBinding to use v1 API (#3926, @jenting)
* enable e2e tests to choose crd apiVersion (#3941, @sseago)
* Fixing multipleNamespaceTest bug - Missing expect statement in test (#3983, @jaidevmane)
* Add --client-page-size flag to server to allow chunking Kubernetes API LIST calls across multiple requests on large clusters (#3823, @dharmab)
* Fix CR restore regression introduced in 1.6 restore progress. (#3845, @sseago)
* Use region specified in the BackupStorageLocation spec when getting restic repo identifier. Originally fixed by @jala-dx in #3617. (#3857, @zubron)
* skip backuping projected volume when using restic (#3866, @alaypatel07)
* Install Kubernetes preferred CRDs API version (v1beta1/v1). (#3614, @jenting)
* Add Label to BackupSpec so that labels can explicitly be provided to Schedule.Spec.Template.Metadata.Labels which will be reflected on the backups created. (#3641, @arush-sal)
* Add PVC UID label to PodVolumeRestore (#3792, @sseago)
* Support pulling plugin images by digest (#3803, @2uasimojo)
* Added BackupPhaseUploading and BackupPhaseUploadingPartialFailure backup phases as part of Upload Progress Monitoring. (#3805, @dsmithuchida)
Uploading (new)
The "Uploading" phase signifies that the main part of the backup, including
snapshotting has completed successfully and uploading is continuing. In
the event of an error during uploading, the phase will change to
UploadingPartialFailure. On success, the phase changes to Completed. The
backup cannot be restored from when it is in the Uploading state.
UploadingPartialFailure (new)
The "UploadingPartialFailure" phase signifies that the main part of the backup,
including snapshotting has completed, but there were partial failures either
during the main part or during the uploading. The backup cannot be restored
from when it is in the UploadingPartialFailure state.
* 🐛 Fix plugin name derivation from image name (#3711, @ashish-amarnath)
* ✨ ⚠️ Remove CSI volumesnapshot artifact deletion
This change requires https://github.com/vmware-tanzu/velero-plugin-for-csi/pull/86 for Velero to continue
deleting of CSI volumesnapshots when the corresponding backups are deleted. (#3734, @ashish-amarnath)
* use unstructured to marshal selective fields for service restore action (#3789, @alaypatel07)
+110
View File
@@ -0,0 +1,110 @@
## 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 cohabitating (#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)
-1
View File
@@ -1 +0,0 @@
Install Kubernetes preferred CRDs API version (v1beta1/v1).
-1
View File
@@ -1 +0,0 @@
Add Label to BackupSpec so that labels can explicitly be provided to Schedule.Spec.Template.Metadata.Labels which will be reflected on the backups created.
@@ -1 +0,0 @@
🐛 Fix plugin name derivation from image name
@@ -1,4 +0,0 @@
✨ ⚠️ Remove CSI volumesnapshot artifact deletion
This change requires https://github.com/vmware-tanzu/velero-plugin-for-csi/pull/86 for Velero to continue
deleting of CSI volumesnapshots when the corresponding backups are deleted.
-1
View File
@@ -1 +0,0 @@
use unstructured to marshal selective fields for service restore action
-1
View File
@@ -1 +0,0 @@
Add PVC UID label to PodVolumeRestore
-1
View File
@@ -1 +0,0 @@
Support pulling plugin images by digest
-16
View File
@@ -1,16 +0,0 @@
Added BackupPhaseUploading and BackupPhaseUploadingPartialFailure backup phases as part of Upload Progress Monitoring
Uploading (new)
The "Uploading" phase signifies that the main part of the backup, including
snapshotting has completed successfully and uploading is continuing. In
the event of an error during uploading, the phase will change to
UploadingPartialFailure. On success, the phase changes to Completed. The
backup cannot be restored from when it is in the Uploading state.
UploadingPartialFailure (new)
The "UploadingPartialFailure" phase signifies that the main part of the backup,
including snapshotting has completed, but there were partial failures either
during the main part or during the uploading. The backup cannot be restored
from when it is in the UploadingPartialFailure state.
-1
View File
@@ -1 +0,0 @@
Add --client-page-size flag to server to allow chunking Kubernetes API LIST calls across multiple requests on large clusters
-1
View File
@@ -1 +0,0 @@
Fix CR restore regression introduced in 1.6 restore progress.
-1
View File
@@ -1 +0,0 @@
Use region specified in the BackupStorageLocation spec when getting restic repo identifier. Originally fixed by @jala-dx in #3617.
-1
View File
@@ -1 +0,0 @@
skip backuping projected volume when using restic
-1
View File
@@ -1 +0,0 @@
Skip the restore of volumes that originally came from a projected volume when using restic.
-1
View File
@@ -1 +0,0 @@
Run the E2E test with kind(provision various versions of k8s cluster) and MinIO on Github Action
-1
View File
@@ -1 +0,0 @@
Fix -install-velero flag for e2e tests
-1
View File
@@ -1 +0,0 @@
Upgrade Velero ClusterRoleBinding to use v1 API
-1
View File
@@ -1 +0,0 @@
enable e2e tests to choose crd apiVersion
-1
View File
@@ -1 +0,0 @@
Fixing multipleNamespaceTest bug - Missing expect statement in test
-1
View File
@@ -1 +0,0 @@
Bump up Go to 1.16
-1
View File
@@ -1 +0,0 @@
Fix restic error when volume is emptyDir and Pod not running
-1
View File
@@ -1 +0,0 @@
Select the velero deployment with both label and container name
-1
View File
@@ -1 +0,0 @@
Wait for the namespace to be deleted before removing the CRDs during uninstall. This deprecates the `--wait` flag of the `uninstall` command
-1
View File
@@ -1 +0,0 @@
Use the cluster preferred CRD API version when polling for Velero CRD readiness.
-1
View File
@@ -1 +0,0 @@
Implement velero debug
-1
View File
@@ -1 +0,0 @@
Add a RestoreItemAction plugin (`velero.io/apiservice`) which skips the restore of any `APIService` which is managed by Kubernetes. These are identified using the `kube-aggregator.kubernetes.io/automanaged` label.
-1
View File
@@ -1 +0,0 @@
Change the base image to distroless
-1
View File
@@ -1 +0,0 @@
Updated the version of velero/velero-plugin-for-aws version from v1.2.0 to v1.2.1
+1
View File
@@ -0,0 +1 @@
Skip not mounted volumes when backing up
+1
View File
@@ -0,0 +1 @@
Update doc for v1.8
+1
View File
@@ -0,0 +1 @@
Add E2E test of backups sync from BSL
+1
View File
@@ -0,0 +1 @@
Fix: OrderedResources in Schedules
+1
View File
@@ -0,0 +1 @@
Skip volumes of non-running pods when backing up
+1
View File
@@ -0,0 +1 @@
E2E SSR test add retry mechanism and logs
+1
View File
@@ -0,0 +1 @@
Fix E2E backup namespaces test
+1
View File
@@ -0,0 +1 @@
Update image used by E2E test to gcr.io
+1
View File
@@ -0,0 +1 @@
Support regional pv for GKE
+1
View File
@@ -0,0 +1 @@
Add GINKGO_SKIP to support skip specific case in e2e test.
+1 -1
View File
@@ -4,7 +4,7 @@ apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
annotations:
controller-gen.kubebuilder.io/version: v0.3.0
controller-gen.kubebuilder.io/version: v0.7.0
creationTimestamp: null
name: backups.velero.io
spec:
@@ -4,7 +4,7 @@ apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
annotations:
controller-gen.kubebuilder.io/version: v0.3.0
controller-gen.kubebuilder.io/version: v0.7.0
creationTimestamp: null
name: backupstoragelocations.velero.io
spec:
@@ -4,7 +4,7 @@ apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
annotations:
controller-gen.kubebuilder.io/version: v0.3.0
controller-gen.kubebuilder.io/version: v0.7.0
creationTimestamp: null
name: deletebackuprequests.velero.io
spec:
@@ -4,7 +4,7 @@ apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
annotations:
controller-gen.kubebuilder.io/version: v0.3.0
controller-gen.kubebuilder.io/version: v0.7.0
creationTimestamp: null
name: downloadrequests.velero.io
spec:
@@ -46,6 +46,7 @@ spec:
- BackupLog
- BackupContents
- BackupVolumeSnapshots
- BackupItemSnapshots
- BackupResourceList
- RestoreLog
- RestoreResults
@@ -4,7 +4,7 @@ apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
annotations:
controller-gen.kubebuilder.io/version: v0.3.0
controller-gen.kubebuilder.io/version: v0.7.0
creationTimestamp: null
name: podvolumebackups.velero.io
spec:
@@ -4,7 +4,7 @@ apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
annotations:
controller-gen.kubebuilder.io/version: v0.3.0
controller-gen.kubebuilder.io/version: v0.7.0
creationTimestamp: null
name: podvolumerestores.velero.io
spec:
@@ -4,7 +4,7 @@ apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
annotations:
controller-gen.kubebuilder.io/version: v0.3.0
controller-gen.kubebuilder.io/version: v0.7.0
creationTimestamp: null
name: resticrepositories.velero.io
spec:
+121 -21
View File
@@ -2,7 +2,7 @@ apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
annotations:
controller-gen.kubebuilder.io/version: v0.3.0
controller-gen.kubebuilder.io/version: v0.7.0
creationTimestamp: null
name: restores.velero.io
spec:
@@ -205,8 +205,10 @@ spec:
are expanded using the container''s environment.
If a variable cannot be resolved, the
reference in the input string will be
unchanged. The $(VAR_NAME) syntax can
be escaped with a double $$, ie: $$(VAR_NAME).
unchanged. Double $$ are reduced to a
single $, which allows for escaping the
$(VAR_NAME) syntax: i.e. "$$(VAR_NAME)"
will produce the string literal "$(VAR_NAME)".
Escaped references will never be expanded,
regardless of whether the variable exists
or not. Cannot be updated. More info:
@@ -221,12 +223,14 @@ spec:
references $(VAR_NAME) are expanded using
the container''s environment. If a variable
cannot be resolved, the reference in the
input string will be unchanged. The $(VAR_NAME)
syntax can be escaped with a double $$,
ie: $$(VAR_NAME). Escaped references will
never be expanded, regardless of whether
the variable exists or not. Cannot be
updated. More info: https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#running-a-command-in-a-shell'
input string will be unchanged. Double
$$ are reduced to a single $, which allows
for escaping the $(VAR_NAME) syntax: i.e.
"$$(VAR_NAME)" will produce the string
literal "$(VAR_NAME)". Escaped references
will never be expanded, regardless of
whether the variable exists or not. Cannot
be updated. More info: https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#running-a-command-in-a-shell'
items:
type: string
type: array
@@ -244,17 +248,19 @@ spec:
value:
description: 'Variable references
$(VAR_NAME) are expanded using the
previous defined environment variables
previously defined environment variables
in the container and any service
environment variables. If a variable
cannot be resolved, the reference
in the input string will be unchanged.
The $(VAR_NAME) syntax can be escaped
with a double $$, ie: $$(VAR_NAME).
Escaped references will never be
expanded, regardless of whether
the variable exists or not. Defaults
to "".'
Double $$ are reduced to a single
$, which allows for escaping the
$(VAR_NAME) syntax: i.e. "$$(VAR_NAME)"
will produce the string literal
"$(VAR_NAME)". Escaped references
will never be expanded, regardless
of whether the variable exists or
not. Defaults to "".'
type: string
valueFrom:
description: Source for the environment
@@ -804,6 +810,30 @@ spec:
required:
- port
type: object
terminationGracePeriodSeconds:
description: Optional duration in seconds
the pod needs to terminate gracefully
upon probe failure. The grace period
is the duration in seconds after the
processes running in the pod are sent
a termination signal and the time
when the processes are forcibly halted
with a kill signal. Set this value
longer than the expected cleanup time
for your process. If this value is
nil, the pod's terminationGracePeriodSeconds
will be used. Otherwise, this value
overrides the value provided by the
pod spec. Value must be non-negative
integer. The value zero indicates
stop immediately via the kill signal
(no opportunity to shut down). This
is a beta field and requires enabling
ProbeTerminationGracePeriod feature
gate. Minimum value is 1. spec.terminationGracePeriodSeconds
is used if unset.
format: int64
type: integer
timeoutSeconds:
description: 'Number of seconds after
which the probe times out. Defaults
@@ -862,6 +892,7 @@ spec:
by services.
type: string
protocol:
default: TCP
description: Protocol for port. Must
be UDP, TCP, or SCTP. Defaults to
"TCP".
@@ -1006,6 +1037,30 @@ spec:
required:
- port
type: object
terminationGracePeriodSeconds:
description: Optional duration in seconds
the pod needs to terminate gracefully
upon probe failure. The grace period
is the duration in seconds after the
processes running in the pod are sent
a termination signal and the time
when the processes are forcibly halted
with a kill signal. Set this value
longer than the expected cleanup time
for your process. If this value is
nil, the pod's terminationGracePeriodSeconds
will be used. Otherwise, this value
overrides the value provided by the
pod spec. Value must be non-negative
integer. The value zero indicates
stop immediately via the kill signal
(no opportunity to shut down). This
is a beta field and requires enabling
ProbeTerminationGracePeriod feature
gate. Minimum value is 1. spec.terminationGracePeriodSeconds
is used if unset.
format: int64
type: integer
timeoutSeconds:
description: 'Number of seconds after
which the probe times out. Defaults
@@ -1017,7 +1072,7 @@ spec:
resources:
description: 'Compute Resources required
by this container. Cannot be updated.
More info: https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/'
More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/'
properties:
limits:
additionalProperties:
@@ -1028,7 +1083,7 @@ spec:
x-kubernetes-int-or-string: true
description: 'Limits describes the maximum
amount of compute resources allowed.
More info: https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/'
More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/'
type: object
requests:
additionalProperties:
@@ -1043,12 +1098,14 @@ spec:
a container, it defaults to Limits
if that is explicitly specified, otherwise
to an implementation-defined value.
More info: https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/'
More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/'
type: object
type: object
securityContext:
description: 'Security options the pod should
run with. More info: https://kubernetes.io/docs/concepts/policy/security-context/
description: 'SecurityContext defines the
security options the container should
be run with. If set, the fields of SecurityContext
override the equivalent fields of PodSecurityContext.
More info: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/'
properties:
allowPrivilegeEscalation:
@@ -1217,6 +1274,25 @@ spec:
is the name of the GMSA credential
spec to use.
type: string
hostProcess:
description: HostProcess determines
if a container should be run as
a 'Host Process' container. This
field is alpha-level and will
only be honored by components
that enable the WindowsHostProcessContainers
feature flag. Setting this field
without the feature flag will
result in errors when validating
the Pod. All of a Pod's containers
must have the same effective HostProcess
value (it is not allowed to have
a mix of HostProcess containers
and non-HostProcess containers). In
addition, if HostProcess is true
then HostNetwork must also be
set to true.
type: boolean
runAsUserName:
description: The UserName in Windows
to run the entrypoint of the container
@@ -1369,6 +1445,30 @@ spec:
required:
- port
type: object
terminationGracePeriodSeconds:
description: Optional duration in seconds
the pod needs to terminate gracefully
upon probe failure. The grace period
is the duration in seconds after the
processes running in the pod are sent
a termination signal and the time
when the processes are forcibly halted
with a kill signal. Set this value
longer than the expected cleanup time
for your process. If this value is
nil, the pod's terminationGracePeriodSeconds
will be used. Otherwise, this value
overrides the value provided by the
pod spec. Value must be non-negative
integer. The value zero indicates
stop immediately via the kill signal
(no opportunity to shut down). This
is a beta field and requires enabling
ProbeTerminationGracePeriod feature
gate. Minimum value is 1. spec.terminationGracePeriodSeconds
is used if unset.
format: int64
type: integer
timeoutSeconds:
description: 'Number of seconds after
which the probe times out. Defaults
+1 -1
View File
@@ -4,7 +4,7 @@ apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
annotations:
controller-gen.kubebuilder.io/version: v0.3.0
controller-gen.kubebuilder.io/version: v0.7.0
creationTimestamp: null
name: schedules.velero.io
spec:
@@ -4,7 +4,7 @@ apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
annotations:
controller-gen.kubebuilder.io/version: v0.3.0
controller-gen.kubebuilder.io/version: v0.7.0
creationTimestamp: null
name: serverstatusrequests.velero.io
spec:
@@ -4,7 +4,7 @@ apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
annotations:
controller-gen.kubebuilder.io/version: v0.3.0
controller-gen.kubebuilder.io/version: v0.7.0
creationTimestamp: null
name: volumesnapshotlocations.velero.io
spec:
File diff suppressed because one or more lines are too long
@@ -1,439 +0,0 @@
---
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: []
@@ -1,179 +0,0 @@
---
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: []
@@ -1,73 +0,0 @@
---
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: []
@@ -1,96 +0,0 @@
---
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: []
@@ -1,162 +0,0 @@
---
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: []
@@ -1,145 +0,0 @@
---
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: []
@@ -1,89 +0,0 @@
---
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: []
File diff suppressed because it is too large Load Diff
@@ -1,401 +0,0 @@
---
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: []
@@ -1,89 +0,0 @@
---
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: []
@@ -1,74 +0,0 @@
---
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: []
File diff suppressed because one or more lines are too long
-4
View File
@@ -1,4 +0,0 @@
// Package crds embeds the controller-tools generated CRD manifests
package crds
//go:generate go run ../../../../hack/crd-gen/v1beta1/main.go
@@ -0,0 +1,40 @@
# 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.
@@ -1,6 +1,6 @@
# Restore API Group Version by Priority Level When EnableAPIGroupVersions Feature is Set
Status: Draft
Status: Accepted
## Abstract
+122
View File
@@ -0,0 +1,122 @@
# `velero debug` command for gathering troubleshooting information
## Abstract
To simplify the communication between velero users and developers, this document proposes the `velero debug` command to generate a tarball including the logs needed for debugging.
Github issue: https://github.com/vmware-tanzu/velero/issues/675
## Background
Gathering information to troubleshoot a Velero deployment is currently spread across multiple commands, and is not very efficient. Logs for the Velero server itself are accessed via a kubectl logs command, while information on specific backups or restores are accessed via a Velero subcommand. Restic logs are even more complicated to retrieve, since one must gather logs for every instance of the daemonset, and theres currently no good mechanism to locate which node a particular restic backup ran against.
A dedicated subcommand can lower this effort and reduce back-and-forth between user and developer for collecting the logs.
## Goals
- Enable efficient log collection for Velero and associated components, like plugins and restic.
## Non Goals
- Collecting logs for components that do not belong to velero such as storage service.
- Automated log analysis.
## High-Level Design
With the introduction of the new command `velero debug`, the command would download all of the following information:
- velero deployment logs
- restic DaemonSet logs
- plugin logs
- All the resources in the group `velero.io` that are created such as:
- Backup
- Restore
- BackupStorageLocation
- PodVolumeBackup
- PodVolumeRestore
- *etc ...*
- Log of the backup and restore, if specified in the param
A project called `crash-diagnostics` (or `crashd`) (https://github.com/vmware-tanzu/crash-diagnostics) implements the Kubernetes API queries and provides Starlark scripting language to abstract details, and collect the information into a local copy. It can be used as a standalone CLI executing a Starlark script file.
With the capabilities of embedding files in Go 1.16, we can define a Starlark script gathering the necessary information, embed the script at build time, then the velero debug command will invoke `crashd`, passing in the scripts text contents.
## Detailed Design
### Triggering the script
The Starlark script to be called by crashd:
```python
def capture_backup_logs(cmd, namespace):
if args.backup:
log("Collecting log and information for backup: {}".format(args.backup))
backupDescCmd = "{} --namespace={} backup describe {} --details".format(cmd, namespace, args.backup)
capture_local(cmd=backupDescCmd, file_name="backup_describe_{}.txt".format(args.backup))
backupLogsCmd = "{} --namespace={} backup logs {}".format(cmd, namespace, args.backup)
capture_local(cmd=backupLogsCmd, file_name="backup_{}.log".format(args.backup))
def capture_restore_logs(cmd, namespace):
if args.restore:
log("Collecting log and information for restore: {}".format(args.restore))
restoreDescCmd = "{} --namespace={} restore describe {} --details".format(cmd, namespace, args.restore)
capture_local(cmd=restoreDescCmd, file_name="restore_describe_{}.txt".format(args.restore))
restoreLogsCmd = "{} --namespace={} restore logs {}".format(cmd, namespace, args.restore)
capture_local(cmd=restoreLogsCmd, file_name="restore_{}.log".format(args.restore))
ns = args.namespace if args.namespace else "velero"
output = args.output if args.output else "bundle.tar.gz"
cmd = args.cmd if args.cmd else "velero"
# Working dir for writing during script execution
crshd = crashd_config(workdir="./velero-bundle")
set_defaults(kube_config(path=args.kubeconfig, cluster_context=args.kubecontext))
log("Collecting velero resources in namespace: {}". format(ns))
kube_capture(what="objects", namespaces=[ns], groups=['velero.io'])
capture_local(cmd="{} version -n {}".format(cmd, ns), file_name="version.txt")
log("Collecting velero deployment logs in namespace: {}". format(ns))
kube_capture(what="logs", namespaces=[ns])
capture_backup_logs(cmd, ns)
capture_restore_logs(cmd, ns)
archive(output_file=output, source_paths=[crshd.workdir])
log("Generated debug information bundle: {}".format(output))
```
The sample command to trigger the script via crashd:
```shell
./crashd run ./velero.cshd --args
'backup=harbor-backup-2nd,namespace=velero,basedir=,restore=,kubeconfig=/home/.kube/minikube-250-224/config,output='
```
To trigger the script in `velero debug`, in the package `pkg/cmd/cli/debug` a struct `option` will be introduced
```go
type option struct {
// currCmd the velero command
currCmd string
// workdir for crashd will be $baseDir/velero-debug
baseDir string
// the namespace where velero server is installed
namespace string
// the absolute path for the log bundle to be generated
outputPath string
// the absolute path for the kubeconfig file that will be read by crashd for calling K8S API
kubeconfigPath string
// the kubecontext to be used for calling K8S API
kubeContext string
// optional, the name of the backup resource whose log will be packaged into the debug bundle
backup string
// optional, the name of the restore resource whose log will be packaged into the debug bundle
restore string
// optional, it controls whether to print the debug log messages when calling crashd
verbose bool
}
```
The code will consolidate the input parameters and execution context of the `velero` CLI to form the option struct, which can be transformed into the `argsMap` that can be used when calling the func `exec.Execute` in `crashd`:
https://github.com/vmware-tanzu/crash-diagnostics/blob/v0.3.4/exec/executor.go#L17
## Alternatives Considered
The collection could be done via the kubernetes client-go API, but such integration is not necessarily trivial to implement, therefore, `crashd` is preferred approach
## Security Considerations
- The starlark script will be embedded into the velero binary, and the byte slice will be passed to the `exec.Execute` func directly, so theres little risk that the script will be modified before being executed.
## Compatibility
As the `crashd` project evolves the behavior of the internal functions used in the Starlark script may change. Well ensure the correctness of the script via regular E2E tests.
## Implementation
1. Bump up to use Go v1.16 to compile velero
2. Embed the starlark script
3. Implement the `velero debug` sub-command to call the script
4. Add E2E test case
## Open Questions
- **Command dependencies:** In the Starlark script, for collecting version info and backup logs, it calls the `velero backup logs` and `velero version`, which makes the call stack like velero debug -> crashd -> velero xxx. We need to make sure this works under different PATH settings.
- **Progress and error handling:** The log collection may take a relatively long time, log messages should be printed to indicate the progress when different items are being downloaded and packaged. Additionally, when an error happens, `crashd` may omit some errors, so before the script is executed we'll do some validation and make sure the `debug` command fail early if some parameters are incorrect.
+219
View File
@@ -0,0 +1,219 @@
# Object Graph Manifest for Velero
## Abstract
One to two sentences that describes the goal of this proposal and the problem being solved by the proposed change.
The reader should be able to tell by the title, and the opening paragraph, if this document is relevant to them.
Currently, Velero does not have a complete manifest of everything in the backup, aside from the backup tarball itself.
This change introduces a new data structure to be stored with a backup in object storage which will allow for more efficient operations in reporting of what a backup contains.
Additionally, this manifest should enable advancements in Velero's features and architecture, enabling dry-run support, concurrent backup and restore operations, and reliable restoration of complex applications.
## Background
Right now, Velero backs up items one at a time, sorted by API Group and namespace.
It also restores items one at a time, using the restoreResourcePriorities flag to indicate which order API Groups should have their objects restored first.
While this does work currently, it presents challenges for more complex applications that have their dependencies in the form of a graph rather than strictly linear.
For example, Cluster API clusters are a set of complex Kubernetes objects that require that the "root" objects are restored first, before their "leaf" objects.
If a Cluster that a ClusterResourceSetBinding refers to does not exist, then a restore of the CAPI cluster will fail.
Additionally, Velero does not have a reliable way to communicate what objects will be affected in a backup or restore operation without actually performing the operation.
This complicates dry-run tasks, because a user must simply perform the action without knowing what will be touched.
It also complicates allowing backups and restores to run in parallel, because there is currently no way to know if a single Kubernetes object is included in multiple backups or restores, which can lead to unreliability, deadlocking, and race conditions were Velero made to be more concurrent today.
## Goals
- Introduce a manifest data structure that defines the contents of a backup.
- Store the manifest data into object storage alongside existing backup data.
## Non Goals
This proposal seeks to enable, but not define, the following.
- Implementing concurrency beyond what already exists in Velero.
- Implementing a dry-run feature.
- Implementing a new restore ordering procedure.
While the data structure should take these scenarios into account, they will not be implemented alongside it.
## High-Level Design
To uniquely identify a Kubernetes object within a cluster or backup, the following fields are sufficient:
- API Group and Version (example: backup.velero.io/v1)
- Namespace
- Name
- Labels
This criteria covers the majority of Velero's inclusion or exclusion logic.
However, some additional fields enable further use cases.
- Owners, which are other Kubernetes objects that have some relationship to this object. They may be strict or soft dependencies.
- Annotations, which provide extra metadata about the object that might be useful for other programs to consume.
- UUID generated by Kubernetes. This is useful in defining Owner relationships, providing a single, immutable key to find an object. This is _not_ considered at restore time, only internally for defining links.
All of this information already exists within a Velero backup's tarball of resources, but extracting such data is inefficient.
The entire tarball must be downloaded and extracted, and then JSON within parsed to read labels, owners, annotations, and a UUID.
The rest of the information is encoded in the file system structure within the Velero backup tarball.
While doable, this is heavyweight in terms of time and potentially memory.
Instead, this proposal suggests adding a new manifest structure that is kept alongside the backup tarball.
This structure would contain the above fields only, and could be used to perform inclusion/exclusion logic on a backup, select a resource from within a backup, and do set operations over backup or restore contents to identify overlapping resources.
Here are some use cases that this data structure should enable, that have been difficult to implement prior to its existence:
- A dry-run operation on backup, informing the user what would be selected if they were to perform the operation.
A manifest could be created and saved, allowing for a user to do a dry-run, then accept it to perform the backup.
Restore operations can be treated similarly.
- Efficient, non-overlapping parallelization of backup and restore operations.
By building or reading a manifest before performing a backup or restore, Velero can determine if there are overlapping resources.
If there are no overlaps, the operations can proceed in parallel.
If there are overlaps, the operations can proveed serially.
- Graph-based restores for non-linear dependencies.
Not all resources in a Kubernetes cluster can be defined in a strict, linear way.
They may have multiple owners, and writing BackupItemActions or RestoreItemActions to simply return a chain of owners is not an efficient way to support the many Kubernetes operators/controllers being written.
Instead, by having a manifest with enough information, Velero can build a discrete list that ensures dependencies are restored before their dependents, with less input from plugin authors.
## Detailed Design
The Manifest data structure would look like this, in Go type structure:
```golang
// NamespacedItems maps a given namespace to all of its contained items.
type NamespacedItems map[string]*Item
// APIGroupNamespaces maps an API group/version to a map of namespaces and their items.
type KindNamespaces map[string]NamespacedItems
type Manifest struct {
// Kinds holds the top level map of all resources in a manifest.
Kinds KindNamespaces
// Index is used to look up an individual item quickly based on UUID.
// This enables fetching owners out of the maps more efficiently at the cost of memory space.
Index map[string]*Item
}
// Item represents a Kubernetes resource within a backup based on it's selectable criteria.
// It is not the whole Kubernetes resource as retrieved from the API server, but rather a collection of important fields needed for filtering.
type Item struct {
// Kubernetes API group which this Item belongs to.
// Could be a core resource, or a CustomResourceDefinition.
APIGroup string
// Version of the APIGroup that the Item belongs to.
APIVersion string
// Kubernetes namespace which contains this item.
// Empty string for cluster-level resource.
Namespace string
// Item's given name.
Name string
// Map of labels that the Item had at backup time.
Labels map[string]string
// Map of annotations that the Item had at Backup time.
// Useful for plugins that may decide to process only Items with specific annotations.
Annotations map[string]string
// Owners is a list of UUIDs to other items that own or refer to this item.
Owners []string
// Manifest is a pointer to the Manifest in which this object is contained.
// Useful for getting access to things like the Manifest.Index map.
Manifest *Manifest
}
```
In addition to the new types, the following Go interfaces would be provided for convenience.
```golang
type Itermer interface {
// Returns the Item as a string, following the current Velero backup version 1.1.0 tarball structure format.
// <APIGroup>/<Namespace>/<APIVersion>/<name>.json
String() string
// Owners returns a slice of realized Items that own or refer to the current Item.
// Useful for building out a full graph of Items to restore.
// Will use the UUIDs in Item.Owners to look up the owner Items in the Manifest.
Owners() []*Item
// Kind returns the Kind of an object, which is a combination of the APIGroup and APIVersion.
// Useful for verifying the needed CustomResourceDefinition exists before actually restoring this Item.
Kind() *Item
// Children returns a slice of all Items that refer to this item as an Owner.
Children() []*Items
}
// This error type is being created in order to make reliable sentinel errors.
// See https://dave.cheney.net/2019/06/10/constant-time for more details.
type ManifestError string
func (e ManifestError) Error() string {
return string(e)
}
const ItemAlreadyExists = ManifestError("item already exists in manifest")
type Manifester interface {
// Set returns the entire list of resources as a set of strings (using Itemer.String).
// This is useful for comparing two manifests and determining if they have any overlapping resources.
// In the future, when implementing concurrent operations, this can be used as a sanity check to ensure resources aren't being backed up or restored by two operations at once.
Set() sets.String
// Adds an item to the appropriate APIGroup and Namespace within a Manifest
// Returns (true, nil) if the Item is successfully added to the Manifest,
// Returns (false, ItemAlreadyExists) if the Item is already in the Manifest.
Add(*Item) (bool, error)
}
```
### Serialization
The entire `Manifest` should be serialized into the `manifest.json` file within the object storage for a single backup.
It is possible that this file could also be compressed for space efficiency.
### Memory Concerns
Because the `Manifest` is holding a minimal amount of data, memory sizes should not be a concern for most clusters.
TODO: Document known limits on API group name, resource name, and kind name character limits.
## Security Considerations
Introducing this manifest does not increase the attack surface of Velero, as this data is already present in the existing backups.
Storing the manifest.json file next to the existing backup data in the object storage does not change access patterns.
## Compatibility
The introduction of this file should trigger Velero backup version 1.2.0, but it will not interfere with Velero versions that do not support the `Manifest` as the file will be additive.
In time, this file will replace the `<backupname>-resource-list.json.gz` file, but for compatibility the two will appear side by side.
When first implemented, Velero should simply build the `Manifest` as it backs up items, and serialize it at the end.
Any logic changes that rely on the `Manifest` file must be introduced with their own design document, with their own compatibility concerns.
## Implementation
The `Manifest` object will _not_ be implemented as a Kubernetes CustomResourceDefinition, but rather one of Velero's own internal constructs.
Implementation for the data structure alone should be minimal - the types will need to be defined in a `manifest` package.
Then, the backup process should create a `Manifest`, passing it to the various `*Backuppers` in the `backup` package.
These methods will insert individual `Items` into the `Manifest`.
Finally, logic should be added to the `persistence` package to ensure that the new `manifest.json` file is uploadable and allowed.
## Alternatives Considered
None so far.
## Open Issues
- When should compatibility with the `<backupname>-resource-list.json.gz` file be dropped?
- What are some good test case Kubernetes resources and controllers to try this out with?
Cluster API seems like an obvious choice, but are there others?
- Since it is not implemented as a CustomResourceDefinition, how can a `Manifest` be retained so that users could issue a dry-run command, then perform their actual desire operation?
Could it be stored in Velero's temp directories?
Note that this is making Velero itself more stateful.
@@ -0,0 +1,735 @@
# 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
-120
View File
@@ -1,120 +0,0 @@
# `velero debug` command for gathering troubleshooting information
## Abstract
To simplify the communication between velero users and developers, this document proposes the `velero debug` command to generate a tarball including the logs needed for debugging.
Github issue: https://github.com/vmware-tanzu/velero/issues/675
## Background
Gathering information to troubleshoot a Velero deployment is currently spread across multiple commands, and is not very efficient. Logs for the Velero server itself are accessed via a kubectl logs command, while information on specific backups or restores are accessed via a Velero subcommand. Restic logs are even more complicated to retrieve, since one must gather logs for every instance of the daemonset, and theres currently no good mechanism to locate which node a particular restic backup ran against.
A dedicated subcommand can lower this effort and reduce back-and-forth between user and developer for collecting the logs.
## Goals
- Enable efficient log collection for Velero and associated components, like plugins and restic.
## Non Goals
- Collecting logs for components that do not belong to velero such as storage service.
- Automated log analysis.
## High-Level Design
With the introduction of the new command `velero debug`, the command would download all of the following information:
- velero deployment logs
- restic DaemonSet logs
- Plugin logs - need clarification for vSphere plugin see open quetions
- Resource and log of the backup and restore, if specified in the param
- Resources:
- BackupStorageLocation
- PodVolumeBackups
- PodVolumeRestores
A project called `crash-diagnostics` (or `crashd`) (https://github.com/vmware-tanzu/crash-diagnostics) implements the Kubernetes API queries and provides Starlark scripting language to abstract details, and collect the information into a local copy. It can be used as a standalone CLI executing a Starlark script file.
With the capabilities of embedding files in Go 1.16, we can define a Starlark script gathering the necessary information, embed the script at build time, then the velero debug command will invoke `crashd`, passing in the scripts text contents.
## Detailed Design
### Triggering the script
The Starlark script to be called by crashd:
```python
def capture_backup_logs():
if args.backup:
kube_capture(what="objects", kinds=['backups'], names=[args.backup])
backupLogsCmd = "velero backup logs {}".format(args.backup)
capture_local(cmd=backupLogsCmd)
def capture_restore_logs():
if args.restore:
kube_capture(what="objects", kinds=['restores'], names=[args.restore])
restoreLogsCmd = "velero restore logs {}".format(args.restore)
capture_local(cmd=restoreLogsCmd)
ns = args.namespace if args.namespace else "velero"
basedir = args.basedir if args.basedir else os.home
output = args.output if args.output else "bundle.tar.gz"
# Working dir for writing during script execution
crshd = crashd_config(workdir="{0}/velero-bundle".format(basedir))
set_defaults(kube_config(path=args.kubeconfig))
capture_local(cmd="velero version -n {}".format(ns))
capture_backup_logs()
capture_restore_logs()
kube_capture(what="logs", namespaces=[ns])
kube_capture(what="objects", namespaces=[ns], kinds=['backupstoragelocations', 'podvolumebackups', 'podvolumerestores'])
archive(output_file=output, source_paths=[crshd.workdir])
```
The sample command to trigger the script via crashd:
```shell
./crashd run ./velero.cshd --args
'backup=harbor-backup-2nd,namespace=velero,basedir=,restore=,kubeconfig=/home/.kube/minikube-250-224/config,output='
```
To trigger the script in `velero debug`, in the package `pkg/cmd/cli/debug` a struct `option` will be introduced
```go
type option struct {
// workdir for crashd will be $baseDir/tmp/crashd
baseDir string
// the namespace where velero server is installed
namespace string
// the absolute path for the log bundle to be generated
outputPath string
// the absolute path for the kubeconfig file that will be read by crashd for calling K8S API
kubeconfigPath string
// optional, the name of the backup resource whose log will be packaged into the debug bundle
backup string
// optional, the name of the restore resource whose log will be packaged into the debug bundle
restore string
}
```
The code will consolidate the input parameters and execution context of the `velero` CLI to form the option struct, which can be transformed into the `args` string for `crashd`
### kubeconfig
When it comes to accessing the API of k8s, `crashd` has a limitation that it can only accept a path of kubeconfig file, without customizing the `context`, and it does not honor the environment variables such as `KUBECONFIG`. `velero` does honor the environment variables and allow user to customize the path to kubeconfig and the `context`
There are two ways to make crashd have consistent behavior as velero in terms of getting the kube configuration:
1. Modify crashd to make it honor the environment variable and allow user to set context while calling k8s APIs. This is a preferred approach and it does make `crashd` better, but it may take longer time because we need to convince the maintainers of `crashd`, and double check the change will not break their current use cases.
There are 2 issues opened:
https://github.com/vmware-tanzu/crash-diagnostics/issues/208
https://github.com/vmware-tanzu/crash-diagnostics/issues/122
I'll try to contact the maintainers of `crashd` to see the feasibility for velero v1.7
2. Before calling the `crashd` script velero CLI will use `client-go` to generate a temp `kubeconfig` file honoring the environment variable and global flags, and pass it to crashd. Although theres no permission elevation and the temp file will be removed, theres still some security concern because the temp file is accessible by other programs before its deleted, or it may not be deleted if an error happens.
Therefore, we should consider `option 1` the better choice, and see `option 2` as the backup.
## Alternatives Considered
The collection could be done via the kubernetes client-go API, but such integration is not necessarily trivial to implement, therefore, `crashd` is preferred approach
## Security Considerations
- The current released version of `crashd` depends on `client-go v0.19.0` which has a known CVE, we need to make sure that when its compiled into velero it uses the version that has the CVE fixed. We should write a PR or push crashd maintainer to fix the CVE-2021-3121 in 0.19.0
- The starlark script will be embedded into the velero binary, so theres little risk that the script will be modified before being called.
- There may be minor security issues if we choose to create a temp `kubeconfig` file for `crashd` and remove it afterwards. If we have to choose this option, we need to review it with security experts to better understand the risks.
## Compatibility
As the `crashd` project evolves the behavior of the internal functions used in the Starlark script may change. Well ensure the correctness of the script via regular E2E tests.
## Implementation
1. Bump up to use Go v1.16 to compile velero
2. Embed the starlark script
3. Implement the `velero debug` sub-command to call the script
4. Add E2E test case
## Open Questions
- **Log collection for vsphere plugin:** Per the design of vsphere plugin: https://github.com/vmware-tanzu/velero-plugin-for-vsphere#architecture when user backup resource on a guest cluster the code in component in the supervisor cluster may be called. Per discussion in v1.7 we will only support collecting logs of process running in one k8s cluster. In terms of implementation, we will do investigate the possibility to call extra script in crashd and ask vsphere plugin developer to provide a script to do the log collection, but the details remain TBD.
- **Command dependencies:** In the Starlark script, for collecting version info and backup logs, it calls the `velero backup logs` and `velero version`, which makes the call stack like velero debug -> crashd -> velero xxx. We need to make sure this works under different PATH settings.
- **Progress and error handling:** The log collection may take a relatively long time, log messages should be printed to indicate the progress when different items are being downloaded and packaged. Additionally, when an error happens, we need to double check if its omitted by crashd.
+106 -29
View File
@@ -1,49 +1,126 @@
module github.com/vmware-tanzu/velero
go 1.16
go 1.17
require (
cloud.google.com/go/storage v1.10.0
github.com/Azure/azure-pipeline-go v0.2.3
github.com/Azure/azure-sdk-for-go v42.0.0+incompatible
github.com/Azure/go-autorest/autorest v0.11.1
github.com/Azure/go-autorest/autorest/azure/auth v0.4.2
github.com/Azure/azure-storage-blob-go v0.14.0
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/Azure/go-autorest/autorest/validation v0.2.0 // indirect
github.com/aws/aws-sdk-go v1.28.2
github.com/docker/spdystream v0.0.0-20170912183627-bc6354cbbc29 // indirect
github.com/evanphx/json-patch v4.9.0+incompatible
github.com/fatih/color v1.10.0
github.com/bombsimon/logrusr v1.1.0
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.4.3
github.com/google/uuid v1.1.2
github.com/hashicorp/go-hclog v0.0.0-20180709165350-ff2cf002a8dd
github.com/golang/protobuf v1.5.2
github.com/google/uuid v1.2.0
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/kubernetes-csi/external-snapshotter/client/v4 v4.0.0
github.com/onsi/ginkgo v1.16.4
github.com/onsi/gomega v1.10.2
github.com/onsi/ginkgo v1.16.5
github.com/onsi/gomega v1.16.0
github.com/pkg/errors v0.9.1
github.com/prometheus/client_golang v1.7.1
github.com/prometheus/client_golang v1.11.0
github.com/robfig/cron v1.1.0
github.com/sirupsen/logrus v1.7.0
github.com/spf13/afero v1.2.2
github.com/spf13/cobra v1.1.1
github.com/sirupsen/logrus v1.8.1
github.com/spf13/afero v1.6.0
github.com/spf13/cobra v1.2.1
github.com/spf13/pflag v1.0.5
github.com/stretchr/testify v1.6.1
github.com/vmware-tanzu/crash-diagnostics v0.3.4
golang.org/x/mod v0.3.0
golang.org/x/net v0.0.0-20201110031124-69a78807bb2b
google.golang.org/grpc v1.31.0
k8s.io/api v0.20.9
k8s.io/apiextensions-apiserver v0.19.12
k8s.io/apimachinery v0.20.9
k8s.io/cli-runtime v0.20.9
k8s.io/client-go v0.20.9
github.com/stretchr/testify v1.7.0
github.com/vmware-tanzu/crash-diagnostics v0.3.7
golang.org/x/mod v0.4.2
golang.org/x/net v0.0.0-20210520170846-37e1c6afe023
google.golang.org/api v0.56.0
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
sigs.k8s.io/cluster-api v0.3.11-0.20210106212952-b6c1b5b3db3d
sigs.k8s.io/controller-runtime v0.7.1-0.20201215171748-096b2e07c091
sigs.k8s.io/yaml v1.2.0
sigs.k8s.io/cluster-api v1.0.0
sigs.k8s.io/controller-runtime v0.10.2
sigs.k8s.io/yaml v1.3.0
)
require (
cloud.google.com/go v0.93.3 // indirect
github.com/Azure/go-autorest v14.2.0+incompatible // indirect
github.com/Azure/go-autorest/autorest/adal v0.9.14 // 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/blang/semver v3.5.1+incompatible // indirect
github.com/cespare/xxhash/v2 v2.1.1 // indirect
github.com/davecgh/go-spew v1.1.1 // indirect
github.com/dimchansky/utfbom v1.1.1 // indirect
github.com/form3tech-oss/jwt-go v3.2.3+incompatible // indirect
github.com/fsnotify/fsnotify v1.5.1 // indirect
github.com/go-logr/logr v0.4.0 // indirect
github.com/go-logr/zapr v0.4.0 // indirect
github.com/gobuffalo/flect v0.2.3 // indirect
github.com/gogo/protobuf v1.3.2 // indirect
github.com/golang/groupcache v0.0.0-20210331224755-41bb18bfe9da // indirect
github.com/google/go-cmp v0.5.6 // indirect
github.com/google/gofuzz v1.2.0 // indirect
github.com/googleapis/gax-go/v2 v2.1.0 // indirect
github.com/googleapis/gnostic v0.5.5 // indirect
github.com/hashicorp/yamux v0.0.0-20180604194846-3520598351bb // indirect
github.com/imdario/mergo v0.3.12 // indirect
github.com/inconshreveable/mousetrap v1.0.0 // indirect
github.com/jmespath/go-jmespath v0.0.0-20180206201540-c2b33e8439af // indirect
github.com/json-iterator/go v1.1.11 // indirect
github.com/liggitt/tabwriter v0.0.0-20181228230101-89fcab3d43de // indirect
github.com/mattn/go-colorable v0.1.9 // 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/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.1 // indirect
github.com/nxadm/tail v1.4.8 // indirect
github.com/oklog/run v1.0.0 // indirect
github.com/pmezard/go-difflib v1.0.0 // indirect
github.com/prometheus/client_model v0.2.0 // indirect
github.com/prometheus/common v0.26.0 // indirect
github.com/prometheus/procfs v0.6.0 // indirect
github.com/stretchr/objx v0.2.0 // indirect
github.com/vladimirvivien/gexe v0.1.1 // indirect
go.opencensus.io v0.23.0 // indirect
go.starlark.net v0.0.0-20201006213952-227f4aabceb5 // indirect
go.uber.org/atomic v1.7.0 // indirect
go.uber.org/multierr v1.6.0 // indirect
go.uber.org/zap v1.19.0 // indirect
golang.org/x/crypto v0.0.0-20210817164053-32db794688a5 // indirect
golang.org/x/oauth2 v0.0.0-20210819190943-2bc19b11175f // indirect
golang.org/x/sys v0.0.0-20211019181941-9d821ace8654 // indirect
golang.org/x/term v0.0.0-20210220032956-6a3ed077a48d // indirect
golang.org/x/text v0.3.7 // indirect
golang.org/x/time v0.0.0-20210723032227-1f47c861a9ac // indirect
gomodules.xyz/jsonpatch/v2 v2.2.0 // indirect
google.golang.org/appengine v1.6.7 // indirect
google.golang.org/genproto v0.0.0-20210828152312-66f60bf46e71 // indirect
google.golang.org/protobuf v1.27.1 // indirect
gopkg.in/inf.v0 v0.9.1 // 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.0-20210107192922-496545a6307b // indirect
k8s.io/component-base v0.22.2 // indirect
k8s.io/klog/v2 v2.9.0 // indirect
k8s.io/kube-openapi v0.0.0-20210421082810-95288971da7e // indirect
k8s.io/utils v0.0.0-20210930125809-cb0fa318a74b // indirect
sigs.k8s.io/structured-merge-diff/v4 v4.1.2 // indirect
)
replace github.com/gogo/protobuf => github.com/gogo/protobuf v1.3.2
+462 -249
View File
File diff suppressed because it is too large Load Diff
+11 -9
View File
@@ -12,7 +12,7 @@
# See the License for the specific language governing permissions and
# limitations under the License.
FROM golang:1.16
FROM golang:1.17
ARG GOPROXY
@@ -24,17 +24,19 @@ ENV GOPROXY=${GOPROXY}
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 git clone -b v0.22.2 https://github.com/kubernetes/code-generator
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
# 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
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
# get controller-tools
RUN go get sigs.k8s.io/controller-tools/cmd/controller-gen@v0.3.0
RUN go get sigs.k8s.io/controller-tools/cmd/controller-gen@v0.7.0
# get goimports (the revision is pinned so we don't indiscriminately update, but the particular commit
# is not important)
-136
View File
@@ -1,136 +0,0 @@
/*
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)
}
}
+28 -38
View File
@@ -38,6 +38,9 @@
# 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 )"
@@ -89,18 +92,31 @@ fi
# Since we're past the validation of the VELERO_VERSION, parse the version's individual components.
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" != 0 ]] && printf "*\t This is a patch release.\n"
# $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"
ON_RELEASE_BRANCH=TRUE
fi
# $VELERO_PRERELEASE gets populated by the chk_version.go script that parses and verifies the given version format
# $VELERO_PRERELEASE gets populated by the chk_version.go script that parses and verifies the given version format
# If we've got a GA release, we assume the tag is on release branch.
# -n is "string is non-empty"
[[ -n $VELERO_PRERELEASE ]] && printf "*\t This is a pre-release.\n"
# -z is "string is empty"
[[ -z $VELERO_PRERELEASE ]] && printf "*\t This is a GA release.\n"
if [[ -z $VELERO_PRERELEASE ]]; then
printf "*\t This is a GA release.\n"
ON_RELEASE_BRANCH=TRUE
fi
if [[ "$ON_RELEASE_BRANCH" == "TRUE" ]]; then
release_branch_name=release-$VELERO_MAJOR.$VELERO_MINOR
printf "*\t The commit to tag is on branch: %s. Please make sure this branch has been created.\n" $release_branch_name
fi
if [[ $publish == "TRUE" ]]; then
echo "If this is all correct, press enter/return to proceed to TAG THE RELEASE and UPLOAD THE TAG TO GITHUB."
@@ -117,55 +133,29 @@ echo "Alright, let's go."
echo "Pulling down all git tags and branches before doing any work."
git fetch "$remote" --tags
# $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'll need to create a release branch for it.
if [[ "$VELERO_PATCH" > 0 ]]; then
release_branch_name=release-$VELERO_MAJOR.$VELERO_MINOR
if [[ -n $release_branch_name ]]; then
# Tag on release branch
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")
remote_branch=$(git branch -r | grep "$remote_release_branch_name")
if [[ -n $remote_branch ]]; then
if [[ -z $local_branch ]]; then
if [[ -z $remote_branch ]]; then
echo "The branch $remote_release_branch_name must be created before you tag the release."
exit 1
fi
if [[ -z $local_branch ]]; then
# Remote branch exists, but does not exist locally. Checkout and track the remote branch.
git checkout --track "$remote_release_branch_name"
else
else
# Checkout the local release branch and ensure it is up to date with the remote
git checkout "$release_branch_name"
git pull --set-upstream "$remote" "$release_branch_name"
fi
else
if [[ -z $local_branch ]]; then
# Neither the remote or local release branch exists, create it
git checkout -b $release_branch_name
else
# The local branch exists so check it out.
git checkout $release_branch_name
fi
fi
echo "Now you'll need to cherry-pick any relevant git commits into this release branch."
echo "Either pause this script with ctrl-z, or open a new terminal window and do the cherry-picking."
if [[ $publish == "TRUE" ]]; then
read -p "Press enter when you're done cherry-picking. THIS WILL MAKE A TAG PUSH THE BRANCH TO $remote"
else
read -p "Press enter when you're done cherry-picking."
fi
# TODO can/should we add a way to review the cherry-picked commits before the push?
if [[ $publish == "TRUE" ]]; then
echo "Pushing $release_branch_name to \"$remote\" remote"
git push --set-upstream "$remote" $release_branch_name
fi
tag_and_push
else
echo "Checking out $remote/main."
git checkout "$remote"/main
tag_and_push
fi
+6 -1
View File
@@ -38,5 +38,10 @@ if [[ -n "${GOFLAGS:-}" ]]; then
echo "GOFLAGS: ${GOFLAGS}"
fi
go test -installsuffix "static" -short -timeout 60s "${TARGETS[@]}"
# After bumping up "sigs.k8s.io/controller-runtime" to v0.10.2, get the error "panic: mkdir /.cache/kubebuilder-envtest: permission denied"
# when running this script with "make test" command. This is caused by that "make test" runs inside a container with user and group specified,
# 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 "${TARGETS[@]}"
echo "Success!"
+16 -19
View File
@@ -44,24 +44,21 @@ ${GOPATH}/src/k8s.io/code-generator/generate-groups.sh \
--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
# Generate apiextensions.k8s.io/v1
# Generate manifests e.g. CRD, RBAC etc.
controller-gen \
crd:crdVersions=v1\
paths=./pkg/apis/velero/v1/... \
paths=./pkg/controller/... \
output:crd:artifacts:config=config/crd/v1/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
# 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/v1/bases/velero.io_restores.yaml -p "$(cat hack/restore-crd-patch-v1.json)" --type=json --local=true -o yaml > /tmp/velero.io_restores-yaml.patched
mv /tmp/velero.io_restores-yaml.patched config/crd/v1/bases/velero.io_restores.yaml
go generate ./config/crd/$version/crds
done
go generate ./config/crd/v1/crds
+7 -10
View File
@@ -19,14 +19,11 @@ HACK_DIR=$(dirname "${BASH_SOURCE}")
${HACK_DIR}/update-generated-crd-code.sh --verify-only
# ensure no changes to generated CRDs
for version in v1beta1 v1
do
if ! git diff --exit-code config/crd/$version/crds/crds.go >/dev/null; then
# revert changes to state before running CRD generation to stay consistent
# with code-generator `--verify-only` option which discards generated changes
git checkout config/crd
if ! git diff --exit-code config/crd/v1/crds/crds.go >/dev/null; then
# revert changes to state before running CRD generation to stay consistent
# with code-generator `--verify-only` option which discards generated changes
git checkout config/crd
echo "CRD verification - failed! Generated CRDs are out-of-date, please run 'make update' and 'git add' the generated file(s)."
exit 1
fi
done
echo "CRD verification - failed! Generated CRDs are out-of-date, please run 'make update' and 'git add' the generated file(s)."
exit 1
fi
+12 -74
View File
@@ -19,6 +19,8 @@ package delete
import (
"io"
"github.com/vmware-tanzu/velero/pkg/plugin/framework"
"github.com/pkg/errors"
"github.com/sirupsen/logrus"
"k8s.io/apimachinery/pkg/labels"
@@ -29,7 +31,6 @@ import (
"github.com/vmware-tanzu/velero/pkg/archive"
"github.com/vmware-tanzu/velero/pkg/discovery"
"github.com/vmware-tanzu/velero/pkg/plugin/velero"
"github.com/vmware-tanzu/velero/pkg/util/collections"
"github.com/vmware-tanzu/velero/pkg/util/filesystem"
)
@@ -41,14 +42,13 @@ type Context struct {
Filesystem filesystem.Interface
Log logrus.FieldLogger
DiscoveryHelper discovery.Helper
resolvedActions []resolvedAction
resolvedActions []framework.DeleteItemResolvedAction
}
func InvokeDeleteActions(ctx *Context) error {
var err error
ctx.resolvedActions, err = resolveActions(ctx.Actions, ctx.DiscoveryHelper)
resolver := framework.NewDeleteItemActionResolver(ctx.Actions)
ctx.resolvedActions, err = resolver.ResolveActions(ctx.DiscoveryHelper)
// No actions installed and no error means we don't have to continue;
// just do the backup deletion without worrying about plugins.
if len(ctx.resolvedActions) == 0 && err == nil {
@@ -74,15 +74,8 @@ func InvokeDeleteActions(ctx *Context) error {
processdResources := sets.NewString()
ctx.Log.Debugf("Trying to reconcile resource names with Kube API server.")
// Transform resource names based on what's canonical in the API server.
for resource := range backupResources {
gvr, _, err := ctx.DiscoveryHelper.ResourceFor(schema.ParseGroupResource(resource).WithVersion(""))
if err != nil {
return errors.Wrapf(err, "failed to resolve resource into complete group/version/resource: %v", resource)
}
groupResource := gvr.GroupResource()
groupResource := schema.ParseGroupResource(resource)
// We've already seen this group/resource, so don't process it again.
if processdResources.Has(groupResource.String()) {
@@ -92,8 +85,6 @@ func InvokeDeleteActions(ctx *Context) error {
// Get a list of all items that exist for this resource
resourceList := backupResources[groupResource.String()]
if resourceList == nil {
// After canonicalization from the API server, the resources may not exist in the tarball
// Skip them if that's the case.
continue
}
@@ -119,10 +110,10 @@ func InvokeDeleteActions(ctx *Context) error {
itemLog.Infof("invoking DeleteItemAction plugins")
for _, action := range actions {
if !action.selector.Matches(labels.Set(obj.GetLabels())) {
if !action.Selector.Matches(labels.Set(obj.GetLabels())) {
continue
}
err = action.Execute(&velero.DeleteItemActionExecuteInput{
err = action.DeleteItemAction.Execute(&velero.DeleteItemActionExecuteInput{
Item: obj,
Backup: ctx.Backup,
})
@@ -139,65 +130,12 @@ func InvokeDeleteActions(ctx *Context) error {
}
// getApplicableActions takes resolved DeleteItemActions and filters them for a given group/resource and namespace.
func (ctx *Context) getApplicableActions(groupResource schema.GroupResource, namespace string) []resolvedAction {
var actions []resolvedAction
func (ctx *Context) getApplicableActions(groupResource schema.GroupResource, namespace string) []framework.DeleteItemResolvedAction {
var actions []framework.DeleteItemResolvedAction
for _, action := range ctx.resolvedActions {
if !action.resourceIncludesExcludes.ShouldInclude(groupResource.String()) {
continue
if action.ShouldUse(groupResource, namespace, nil, ctx.Log) {
actions = append(actions, action)
}
if namespace != "" && !action.namespaceIncludesExcludes.ShouldInclude(namespace) {
continue
}
if namespace == "" && !action.namespaceIncludesExcludes.IncludeEverything() {
continue
}
actions = append(actions, action)
}
return actions
}
// resolvedActions are DeleteItemActions decorated with resource/namespace include/exclude collections, as well as label selectors for easy comparison.
type resolvedAction struct {
velero.DeleteItemAction
resourceIncludesExcludes *collections.IncludesExcludes
namespaceIncludesExcludes *collections.IncludesExcludes
selector labels.Selector
}
// resolveActions resolves the AppliesTo ResourceSelectors of DeleteItemActions plugins against the Kubernetes discovery API for fully-qualified names.
func resolveActions(actions []velero.DeleteItemAction, helper discovery.Helper) ([]resolvedAction, error) {
var resolved []resolvedAction
for _, action := range actions {
resourceSelector, err := action.AppliesTo()
if err != nil {
return nil, err
}
resources := collections.GetResourceIncludesExcludes(helper, resourceSelector.IncludedResources, resourceSelector.ExcludedResources)
namespaces := collections.NewIncludesExcludes().Includes(resourceSelector.IncludedNamespaces...).Excludes(resourceSelector.ExcludedNamespaces...)
selector := labels.Everything()
if resourceSelector.LabelSelector != "" {
if selector, err = labels.Parse(resourceSelector.LabelSelector); err != nil {
return nil, err
}
}
res := resolvedAction{
DeleteItemAction: action,
resourceIncludesExcludes: resources,
namespaceIncludesExcludes: namespaces,
selector: selector,
}
resolved = append(resolved, res)
}
return resolved, nil
}
+4
View File
@@ -46,4 +46,8 @@ const (
// APIGroupVersionsFeatureFlag is the feature flag string that defines whether or not to handle multiple API Group Versions
APIGroupVersionsFeatureFlag = "EnableAPIGroupVersions"
// UploadProgressFeatureFlag is the feature flag string that defines whether or not upload progress monitoring is enabled
// and whether or not ItemSnapshotters should be invoked
UploadProgressFeatureFlag = "EnableUploadProgress"
)
+2 -1
View File
@@ -25,13 +25,14 @@ type DownloadRequestSpec struct {
}
// DownloadTargetKind represents what type of file to download.
// +kubebuilder:validation:Enum=BackupLog;BackupContents;BackupVolumeSnapshots;BackupResourceList;RestoreLog;RestoreResults
// +kubebuilder:validation:Enum=BackupLog;BackupContents;BackupVolumeSnapshots;BackupItemSnapshots;BackupResourceList;RestoreLog;RestoreResults
type DownloadTargetKind string
const (
DownloadTargetKindBackupLog DownloadTargetKind = "BackupLog"
DownloadTargetKindBackupContents DownloadTargetKind = "BackupContents"
DownloadTargetKindBackupVolumeSnapshots DownloadTargetKind = "BackupVolumeSnapshots"
DownloadTargetKindBackupItemSnapshots DownloadTargetKind = "BackupItemSnapshots"
DownloadTargetKindBackupResourceList DownloadTargetKind = "BackupResourceList"
DownloadTargetKindRestoreLog DownloadTargetKind = "RestoreLog"
DownloadTargetKindRestoreResults DownloadTargetKind = "RestoreResults"
@@ -1,3 +1,4 @@
//go:build !ignore_autogenerated
// +build !ignore_autogenerated
/*

Some files were not shown because too many files have changed in this diff Show More