* k8s 1.18 import wip
backup, cmd, controller, generated, restic, restore, serverstatusrequest, test and util
Signed-off-by: Andrew Lavery <laverya@umich.edu>
* go mod tidy
Signed-off-by: Andrew Lavery <laverya@umich.edu>
* add changelog file
Signed-off-by: Andrew Lavery <laverya@umich.edu>
* go fmt
Signed-off-by: Andrew Lavery <laverya@umich.edu>
* update code-generator and controller-gen in CI
Signed-off-by: Andrew Lavery <laverya@umich.edu>
* checkout proper code-generator version, regen
Signed-off-by: Andrew Lavery <laverya@umich.edu>
* fix remaining calls
Signed-off-by: Andrew Lavery <laverya@umich.edu>
* regenerate CRDs with ./hack/update-generated-crd-code.sh
Signed-off-by: Andrew Lavery <laverya@umich.edu>
* use existing context in restic and server
Signed-off-by: Andrew Lavery <laverya@umich.edu>
* fix test cases by resetting resource version
also use main library go context, not golang.org/x/net/context, in pkg/restore/restore.go
Signed-off-by: Andrew Lavery <laverya@umich.edu>
* clarify changelog message
Signed-off-by: Andrew Lavery <laverya@umich.edu>
* use github.com/kubernetes-csi/external-snapshotter/v2@v2.2.0-rc1
Signed-off-by: Andrew Lavery <laverya@umich.edu>
* run 'go mod tidy' to remove old external-snapshotter version
Signed-off-by: Andrew Lavery <laverya@umich.edu>
The labels 'Documentation', 'Website', and 'Design' are all for PRs
exclusively related to those things, not code, so they don't need to be
checked for changelogs or have the extra label applied.
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* updated acceptable values on cron schedule for day of the week from 0-7 to 0-6
Signed-off-by: Daniel Thrasher <dannythrasher@gmail.com>
* added a changelog file to changelog directory
Signed-off-by: Daniel Thrasher <dannythrasher@gmail.com>
Co-authored-by: Daniel Thrasher <dannythrasher@gmail.com>
* Add linter to Makefile and build image
* Also make it part of verify step
Signed-off-by: Tony Batard <tbatard@pivotal.io>
* clean up of Makefile and permissions for .go/golangci-lint
Signed-off-by: Duffie Cooley <cooleyd@vmware.com>
* changed verify-lint.sh to lint.sh to avoid breaking ci
Signed-off-by: mtritabaugh <mtritabaugh@vmware.com>
* Add changelog
Signed-off-by: Tony Batard <tbatard@pivotal.io>
* Add LINTERS option to run only specific linters
* e.g. make lint LINTERS=unused,deadcode
Signed-off-by: Tony Batard <tbatard@pivotal.io>
* adding timeout to golangci-lint, and checking cache
Signed-off-by: Matyas Danter <mdanter@vmware.com>
* Fixed some formatting and added comments
Signed-off-by: Matyas Danter <mdanter@vmware.com>
* modifying lint script to use golangci.yaml
Signed-off-by: Matyas Danter <mdanter@vmware.com>
* update to move default linters to Makefile
Signed-off-by: mtritabaugh <mtritabaugh@vmware.com>
* Adding documentation for lint make targets.
Signed-off-by: Matyas Danter <mdanter@vmware.com>
* Update Copyright with current year
Signed-off-by: Tony Batard <tbatard@pivotal.io>
* initial git workflow commit
Signed-off-by: mtritabaugh <mtritabaugh@vmware.com>
* Added lint-all target and implemented -n as default
* Added a local-lint-all and lint-all target that will show lint errors
for all of the codebase
* changed the default of lint and local-lint to only show new lint
errors
Signed-off-by: Duffie Cooley <cooleyd@vmware.com>
* updated docs to reflect new target
Signed-off-by: mtritabaugh <mtritabaugh@vmware.com>
Co-authored-by: Duffie Cooley <cooleyd@vmware.com>
Co-authored-by: mtritabaugh <mtritabaugh@vmware.com>
Co-authored-by: Matyas Danter <mdanter@vmware.com>
* kubebuilder init - minimalist version
Signed-off-by: Carlisia <carlisia@vmware.com>
* Add back main.go, apparently kb needs it
Signed-off-by: Carlisia <carlisia@vmware.com>
* Tweak makefile to accomodate kubebuilder expectations
Signed-off-by: Carlisia <carlisia@vmware.com>
* Port BSL to kubebuilder api client
Signed-off-by: Carlisia <carlisia@vmware.com>
* s/cache/client bc client fetches from cache
And other naming improvements
Signed-off-by: Carlisia <carlisia@vmware.com>
* So, .GetAPIReader is how we bypass the cache
In this case, the cache hasn't started yet
Signed-off-by: Carlisia <carlisia@vmware.com>
* Oh that's what this code was for... adding back
We still need to embed the CRDs as binary data in the Velero binary to
access the generated CRDs at runtime.
Signed-off-by: Carlisia <carlisia@vmware.com>
* Tie in CRD/code generation w/ existing scripts
Signed-off-by: Carlisia <carlisia@vmware.com>
* Mostly result of running update-fmt, updated file formatting
Signed-off-by: Carlisia <carlisia@vmware.com>
* Just a copyright fix
Signed-off-by: Carlisia <carlisia@vmware.com>
* All the test fixes
Signed-off-by: Carlisia <carlisia@vmware.com>
* Add changelog + some cleanup
Signed-off-by: Carlisia <carlisia@vmware.com>
* Update backup manifest
Signed-off-by: Carlisia <carlisia@vmware.com>
* Remove unneeded auto-generated files
Signed-off-by: Carlisia <carlisia@vmware.com>
* Keep everything in the same (existing) package
Signed-off-by: Carlisia <carlisia@vmware.com>
* Fix/clean scripts, generated code, and calls
Deleting the entire `generated` directory and running `make update`
works. Modifying an api and running `make verify` works as expected.
Signed-off-by: Carlisia <carlisia@vmware.com>
* Clean up schema and client calls + code reviews
Signed-off-by: Carlisia <carlisia@vmware.com>
* Move all code gen to inside builder container
Signed-off-by: Carlisia <carlisia@vmware.com>
* Address code review
Signed-off-by: Carlisia <carlisia@vmware.com>
* Fix imports/aliases
Signed-off-by: Carlisia <carlisia@vmware.com>
* More code reviews
Signed-off-by: Carlisia <carlisia@vmware.com>
* Add waitforcachesync
Signed-off-by: Carlisia <carlisia@vmware.com>
* Have manager register ALL controllers
This will allow for proper cache management.
Signed-off-by: Carlisia <carlisia@vmware.com>
* Status subresource is now enabled; cleanup
Signed-off-by: Carlisia <carlisia@vmware.com>
* More code reviews
Signed-off-by: Carlisia <carlisia@vmware.com>
* Clean up
Signed-off-by: Carlisia <carlisia@vmware.com>
* Manager registers ALL controllers for restic too
Signed-off-by: Carlisia <carlisia@vmware.com>
* More code reviews
Signed-off-by: Carlisia <carlisia@vmware.com>
* Add deprecation warning/todo
Signed-off-by: Carlisia <carlisia@vmware.com>
* Add documentation
Signed-off-by: Carlisia <carlisia@vmware.com>
* Add helpful comments
Signed-off-by: Carlisia <carlisia@vmware.com>
* Address code review
Signed-off-by: Carlisia <carlisia@vmware.com>
* More idiomatic Runnable
Signed-off-by: Carlisia <carlisia@vmware.com>
* Clean up imports
Signed-off-by: Carlisia <carlisia@vmware.com>
* log a warning instead of erroring if additional item can't be found
Signed-off-by: Steve Kriss <krisss@vmware.com>
* always show backup warning/error count in get/describe
Signed-off-by: Steve Kriss <krisss@vmware.com>
* changelog
Signed-off-by: Steve Kriss <krisss@vmware.com>
* Use a helper function when querying w/ backup label
Setting or querying for a backup label name should always pass the value
through the GetValidName function. This change passes query uses of the
backup label value through the GetValidName function by introducing 2
new helpers, one for making a Selector, one for making a ListOptions.
It also removes functions returning the same data, but under
unecessarily specific names.
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Document using the label.GetValidName function
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Update copyright year
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Clarify labels.GetValidName and annotations
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Move functions to pkg/label
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Fix function comments
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Switch to backing up v1beta1 CRDs from API server
Instead of simply switching out the APIVersion string on a v1
CustomResourceDefinition object, re-download the object from the API
server entirely to get the correct fields.
This should fix validation errors upon restore.
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Fix existing tests
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Add full example CRDs to automated tests
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Move beta CRD lookup into helper function
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Add case for preserveUnknownFields CRDs
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Add PreserveUnknownFields case and refactor execute
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Add older prometheus CRD test cases
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Add changelog
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Backup all API Groups versions while keeping backward compatibility
Signed-off-by: Rafael Brito <rbrito@vmware.com>
* Backup all API Groups versions while keeping backward compatibility
Signed-off-by: Rafael Brito <rbrito@vmware.com>
* Adding feature flag to enable backup of multiple API group versions
Signed-off-by: Rafael Brito <rbrito@vmware.com>
* Install ca-certificates for ARM based container builds.
Signed-off-by: David Colon <dave@colon.dev>
* Adding changelog for PR 2481
Signed-off-by: David Colon <dave@colon.dev>
* Add documentation for --cacert feature
Signed-off-by: Sam Lucidi <slucidi@redhat.com>
* Document objectStorage/caCert field.
Signed-off-by: Sam Lucidi <slucidi@redhat.com>
* Add link to ca bundle docs in TOC and customize-installation
Signed-off-by: Sam Lucidi <slucidi@redhat.com>
* bug fix: don't remove unresolvable includes from includes-excludes lists
Signed-off-by: Steve Kriss <krisss@vmware.com>
* changelog
Signed-off-by: Steve Kriss <krisss@vmware.com>
* Disabling validation for volumesnapshotlocation if the backup has snapshotvolume set to false
Signed-off-by: mayank <mayank.patel@mayadata.io>
* adding a changelog
Signed-off-by: mayank <mayank.patel@mayadata.io>
* addressing review comment
Signed-off-by: mayank <mayank.patel@mayadata.io>
Infomers won't start if cancelFunc is invoked as soon as the newServer
function exits via the defer
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
All changes to go.mod/go.sum besides the external-snapshotter repo are a
result of its transitive dependencies.
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
Account for having CSI enabled or not, as well as having the snapshot
CRDs installed in the kubernetes cluster.
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Add --cacert flag to velero cli commands
Adds a --cacert flag to the log and describe commands
that takes a path to a PEM-encoded certificate bundle
as an alternative to --insecure-skip-tls-verify for
dealing with self-signed certificates.
Signed-off-by: Sam Lucidi <slucidi@redhat.com>
* Add --cacert flag to the installer
Allows setting the cacert field on the BSL during
the install process using the file at the path
specified by the --cacert field.
Signed-off-by: Sam Lucidi <slucidi@redhat.com>
* Add changelog for #2368
Signed-off-by: Sam Lucidi <slucidi@redhat.com>
CSI plugin for velero will use this to return secrets as additional
resource while backing up CSI objects
Signed-off-by: Ashish Amarnath <ashisham@vmware.com>
* Support setting a custom CA certificate for a BSL
Signed-off-by: Sam Lucidi <slucidi@redhat.com>
* update CRDS
Signed-off-by: Sam Lucidi <slucidi@redhat.com>
* Add changelog for #2353
Signed-off-by: Sam Lucidi <slucidi@redhat.com>
* Clean up temp file from TestTempCACertFile
Signed-off-by: Sam Lucidi <slucidi@redhat.com>
* Add builders for CRD schemas
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Add test case for #2319
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Add failing test case
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Remove unnecessary print and temporary variable
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Add some options for fixing the test case
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Switch to a JSON middle step to "fix" conversions
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Add comment and changelog
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Account for possible missing schemas on v1 CRDs
If a v1beta1 CRD without a Schema was submitted to a Kubernets v1.16
cluster, then Kubernetes will server it back as a v1 CRD without a
schema.
However, when Velero tries to restore this document, the request will be
rejected as a v1 CRD must have a schema.
This commit has some defensive coding on the restore side, as well as
potential fixes on the backup side for getting around this.
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Back up nonstructural CRDs as v1beta1
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Add tests for remapping plugin
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Add builders for v1 CRDs
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Address review feedback
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Remove extraneous log message
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Add changelog
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
The OpenEBS community uses Velero as a preferred tool to enable data protection strategies. And at MayaData, we have
been using Velero since its ark days to power DMaaS - Data Migration as a service. Thank you for an amazing product and
community.
Signed-off-by: kmova <kiran.mova@mayadata.io>
* Wait for CRDs to be available and ready
When restoring CRDs, we should wait for the definition to be ready and
available before moving on to restoring specific CRs.
While the CRDs are often ready by the time we get to restoring a CR,
there is a race condition where the CRD isn't ready.
This change waits on each CRD at restore time.
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Pruning unknown fields
In CRD apiversion v1beta1, default preserveUnknownFields=true.
In CRD apiversion v1, the preserveUnknownFields can only be false.
Otherwise, the k8s validation bumps out error message for the
invalid preserveUnknownFields value.
Deploy Velero on k8s 1.16+ with CRD apiversion v1beta1, the
k8s cluster converts apiversion from v1beta1 to v1 automatically.
Fully backup and restore the cluster, restore bumps out error message
due to the preserveUnknownFields=true is not allowed on k8s 1.16+.
Since the CRD structural schema had been defined, enable the preserveUnknownFields
to false to solves the restore bumps out error message on k8s 1.16+.
Signed-off-by: JenTing Hsiao <jenting.hsiao@suse.com>
* Add changelog
Signed-off-by: JenTing Hsiao <jenting.hsiao@suse.com>
(for some reason, basic Kubernetes is able to run a Debian based container with nobody:nobody but
docker run and VMware WCP fail which should be expected behavior)
Signed-off-by: Dave Smith-Uchida <dsmithuchida@vmware.com>
Velero client config file should have restricted file permissions to be
read/write-able for the user that creates it--similiar to files like
`.ssh/id_rsa`
Refer to OTG-CONFIG-009: Test File Permission
> Impoper file permission configuration may result in privilledge
escalation, information explousure, DLL injection, or unauthorized file
access.
Therefore, files permission must be properly configured with minium
access permission by default.
[source](https://www.owasp.org/index.php/Test_File_Permission_(OTG-CONFIG-009))
Ticket: #1758
Signed-off-by: John Naulty <johnnaulty@bitgo.com>
* Check for nil LastMaintenanceTime in dueForMaintenance
ResticRepository.dueForMaintenance causes a panic in the velero pod
("invalid memory address or nil pointer dereference") if
repository.Status.LastMaintenanceTime is nil. This fix returns 'true'
if it's nil, so the repository is due for maintenance if LastMaintenanceTime
is nil *or* the time elapsed since the last maintenance is greater than
repository.Spec.MaintenanceFrequency.Duration
Signed-off-by: Scott Seago <sseago@redhat.com>
* changelog for PR#2200
Signed-off-by: Scott Seago <sseago@redhat.com>
* update revision of go-hclog to match go.mod requirement
Signed-off-by: Steve Kriss <krisss@vmware.com>
* update prometheus dep to prepare for go module migration
Signed-off-by: Steve Kriss <krisss@vmware.com>
Install restic with CPU/Memory limits is optional.
If velero cannot parse resource requirements, use default value instead.
After that, the administrator won't get confused that something recovered failed.
Signed-off-by: JenTing Hsiao <jenting.hsiao@suse.com>
Migrate logic from NewUUID function into the pvRenamer function.
PR #2133 switched to a new NewUUID function that returns an error, but
the invocation of that function needs to happen within the pvRenamer
closure. Because the new function returns an error, the pvRenamer should
return the error, the signature needs to be changed and the return
checked.
Signed-off-by: John Naulty <johnnaulty@bitgo.com>
satori/go.uuid has a known issue with random uuid generation.
gofrs/uuid is still maintained and has fixed the random uuid generation
issue present in satori/go.uuid
Signed-off-by: John Naulty <johnnaulty@bitgo.com>
* Updating restic document for OpenShift cluster having version 4.1 or later
Signed-off-by: shashank855 <shashank.ranjan@mayadata.io>
* update documentation for velero-v1.2.0
Signed-off-by: shashank855 <shashank.ranjan@mayadata.io>
Fixes: #2094
Updates to site colours to align with VMware branding and improve contrast rations for site accessibility.
Update to youtube plugin for that it can will insert an iframes title as well. New usage of liquid template `{% youtube "<title>" %}
Updates to links to provide link text
Updates to images to add alt text.
Accessibility changes assist people visiting the site with visual impairments and improve the function of text to speech tools such as Jaws.
Signed-off-by: Brett Johnson <brett@sdbrett.com>
Fixes: #2092
Resolves: CVE-2019-13117
Updated gemfile.lock for security vulnerability.
Updated Gemfile to specify gem versions, providing more control over versions when using bundle update. Including the Jekyll version in the Gemfile tells Nelify which version to build with.
Signed-off-by: Brett Johnson <brett@sdbrett.com>
* remove fsfreeze-pause image, replace with ubuntu in nginx example
Signed-off-by: Steve Kriss <krisss@vmware.com>
* changelog
Signed-off-by: Steve Kriss <krisss@vmware.com>
* switch to sleep infinity for clarity
Signed-off-by: Steve Kriss <krisss@vmware.com>
* restic: don't try to restore PVBs with no snapshotID
Signed-off-by: Steve Kriss <krisss@vmware.com>
* changelog
Signed-off-by: Steve Kriss <krisss@vmware.com>
Without a GOPROXY, go modules are fetched from their respective hosts,
which increases the likelihood that any given host might be unavailable
and break builds.
Fixes#2036
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* restic: use restore cmd's env when getting snapshot size
Signed-off-by: Steve Kriss <krisss@vmware.com>
* restic: remove code that considers 0-byte backups an error
Signed-off-by: Steve Kriss <krisss@vmware.com>
* add --allow-partially-failed flag to velero restore create
Signed-off-by: Steve Kriss <krisss@vmware.com>
* remove extraneous client creation
Signed-off-by: Steve Kriss <krisss@vmware.com>
* add godoc to helper func
Signed-off-by: Steve Kriss <krisss@vmware.com>
* todo
Signed-off-by: Steve Kriss <krisss@vmware.com>
* WIP revised install overview
Signed-off-by: Steve Kriss <krisss@vmware.com>
* add info on different installing different VSL provider
Signed-off-by: Steve Kriss <krisss@vmware.com>
* address review and TODOs
Signed-off-by: Steve Kriss <krisss@vmware.com>
Related issue: https://github.com/heptio/velero/issues/1830
This accomplishes everything
that's needed, although there might be room for improvement in avoiding
a GET call for matching CRDs for each resource backed up. An alternative
could be a single call to get all CRDs prior to iterating over resources
and passing this into the backupResource function.
Signed-off-by: Scott Seago <sseago@redhat.com>
* feat: add azure china support
Signed-off-by: andyzhangx <xiazhang@microsoft.com>
* remove AZURE_CLOUD_NAME from required env var fetching
Signed-off-by: Steve Kriss <krisss@vmware.com>
* minor simplification of parseAzureEnvironment
Signed-off-by: Steve Kriss <krisss@vmware.com>
* changelog
Signed-off-by: Steve Kriss <krisss@vmware.com>
* remove cloudNameEnvVar from getRequiredValues call
Signed-off-by: Steve Kriss <krisss@vmware.com>
* just check for err != nil
Signed-off-by: Steve Kriss <krisss@vmware.com>
* Allow the velero server to be created on GCP even without a provided service account key in order to support workload identity and default compute engine credentials. Add option for adding service account annotations.
Signed-off-by: Joshua Wong <joshua99wong@gmail.com>
By default, git does not fetch tags on a checkout, so fetch those when
building a tag.
When the tags are not fetched and building master, both HIGHEST and
LATEST_TAG were "", which was equal. Thus, every master push was tagged
as latest. This is now handled correctly.
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* update import paths to github.com/vmware-tanzu/...
Signed-off-by: Steve Kriss <krisss@vmware.com>
* update other GH org refs to vmware-tanzu
Signed-off-by: Steve Kriss <krisss@vmware.com>
* site and docs: update GH org to vmware-tanzu
Signed-off-by: Steve Kriss <krisss@vmware.com>
* update travis badge links on docs readmes
Signed-off-by: Steve Kriss <krisss@vmware.com>
* backup sync controller: replace revision file with full diff each interval
Signed-off-by: Steve Kriss <krisss@vmware.com>
* remove getting/setting of metadata/revision file
Signed-off-by: Steve Kriss <krisss@vmware.com>
* changelog
Signed-off-by: Steve Kriss <krisss@vmware.com>
* tweak logging
Signed-off-by: Steve Kriss <krisss@vmware.com>
* don't keep podVolumeBackup log field around after syncing PVBs
Signed-off-by: Steve Kriss <krisss@vmware.com>
* update generated CRDs
Signed-off-by: Steve Kriss <krisss@vmware.com>
Using layers can simplify iteration on the builder image itself, and
shorten build times when only one command is changed
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* fail on make verify if generated CRDs differ
Signed-off-by: Adnan Abdulhussein <aadnan@vmware.com>
* make verification error more clear
Signed-off-by: Adnan Abdulhussein <aadnan@vmware.com>
* velero install: wait for restic daemonset to be ready
Signed-off-by: Steve Kriss <krisss@vmware.com>
* changelog
Signed-off-by: Steve Kriss <krisss@vmware.com>
A user encountered the following error on a GCP project:
An error occurred: some backup storage locations are invalid: error getting backup store for location "default": rpc error: code = Unknown desc = invalid character '-' in numeric literal
This error was ambiguous and took some time to track down to the fact
that their credentials file wasn't a JSON file, but instead the contents
of the private key field. This change makes the problem slightly easier
to debug.
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* change youtube embed to playlist
Signed-off-by: Steve Kriss <krisss@vmware.com>
* add blog post links to resources
Signed-off-by: Steve Kriss <krisss@vmware.com>
* Add script for pushing container images via Travis
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Explain the latest tag logic
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Add travis integration to deployment
* ensure $BRANCH is always the same value (borrowed from Sonobuoy)
* get gcloud SDK installed (borrowed from Sonobuoy)
* use deploy step to run GCR push script (borrowed from Sonobuoy)
* use gcloud's docker to do the image building/pushing
* placeholders for secure values
* rename $LATEST to $HIGHEST to more accurately reflect what it is
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Add encrypted GCR creds
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Remove unused env section
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Rearrange logic so that there's only one make call
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Review feedback
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Update gcloud and OS for Travis environment
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Remove redundant make dependencies
verify and test targets already run on the ci target, which must pass
before deploy.
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Re-encrypt file after testing
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
After discussing with the team, it doesn't make sense for all design proposals to have a draft/accepted status. Currently draft proposals can be kept open as PRs and all merged proposals are considered to be accepted. Removing the status field here removes the extra step of having to update the proposal status before merging.
Signed-off-by: Adnan Abdulhussein <aadnan@vmware.com>
* rename PV during restore when cloning a namespace
Signed-off-by: Steve Kriss <krisss@vmware.com>
* rename func and vars, switch to if..else
Signed-off-by: Steve Kriss <krisss@vmware.com>
* make pv renamer func configurable for testing purposes
Signed-off-by: Steve Kriss <krisss@vmware.com>
* add unit test cases
Signed-off-by: Steve Kriss <krisss@vmware.com>
* changelog
Signed-off-by: Steve Kriss <krisss@vmware.com>
* address review feedback
Signed-off-by: Steve Kriss <krisss@vmware.com>
* address review feedback
Signed-off-by: Steve Kriss <krisss@vmware.com>
* when backing up PVCs with restic, explicitly specify --parent
Signed-off-by: Steve Kriss <krisss@vmware.com>
* changelog
Signed-off-by: Steve Kriss <krisss@vmware.com>
* address review feedback
Signed-off-by: Steve Kriss <krisss@vmware.com>
* restic backup and restore progress proposal
Signed-off-by: Adnan Abdulhussein <aadnan@vmware.com>
* update approach to lookup based on files rather than total size
Signed-off-by: Adnan Abdulhussein <aadnan@vmware.com>
* typo
Signed-off-by: Adnan Abdulhussein <aadnan@vmware.com>
* record TotalBytes and BytesDone in PodVolumeBackup/Restore and calculate percentage in UI
Signed-off-by: Adnan Abdulhussein <aadnan@vmware.com>
* update to go with restic stats approach for restore
Signed-off-by: Adnan Abdulhussein <aadnan@vmware.com>
* typo
Signed-off-by: Adnan Abdulhussein <aadnan@vmware.com>
* update high-level design for restic stats
Signed-off-by: Adnan Abdulhussein <aadnan@vmware.com>
* wait for bytes_done
Signed-off-by: Adnan Abdulhussein <aadnan@vmware.com>
* change status to accepted
Signed-off-by: Adnan Abdulhussein <aadnan@vmware.com>
* patch velero to handle self-signed certs on client
you'll get this error otherwise:
x509: certificate signed by unknown authority
Signed-off-by: Steven Chung <schung@d2iq.com>
The Velero deployment did not have a way of exposing the namespace it
was installed in to the API client. This is a problem for plugins that
need to query for resources in that namespaces, such as the restic
restore process that needs to find PodVolume(Backup|Restore)s.
While the Velero client is consulted for a configured namespace, this
cannot be set in the server pod since there is no valid home directory
in which to place it.
This change provides the namespace to the deployment via the downward
API, and updates the API client factory to use the VELERO_NAMESPACE
before looking at the config file, so that any plugins using the client
will look at the appropriate namespace.
Fixes#1743
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Add SEO functionality to the site
Signed-off-by: Jonas Rosland <jrosland@vmware.com>
* Add some more SEO
Signed-off-by: Jonas Rosland <jrosland@vmware.com>
* use Backup CR labels as tags for snapshots
This allows users to define custom tags to be added to snapshots, by
specifying custom labels on the Backup CR with the `velero backup create
--labels` flag.
Signed-off-by: Adnan Abdulhussein <aadnan@vmware.com>
* print resource list metadata in velero backup describe details
Signed-off-by: Adnan Abdulhussein <aadnan@vmware.com>
* rewrite TestGetDownloadURL to test more scenarios
Signed-off-by: Adnan Abdulhussein <aadnan@vmware.com>
* move backup printer helpers to backup_printer.go
Signed-off-by: Adnan Abdulhussein <aadnan@vmware.com>
* move describe printer helpers back to backup_describer
and rename to prefix with describe* to indicate that they are used for the describe command
Signed-off-by: Adnan Abdulhussein <aadnan@vmware.com>
* split backup and restore tests for TestGetDownloadURL
Signed-off-by: Adnan Abdulhussein <aadnan@vmware.com>
* friendlier error message when backup resource list missing
Signed-off-by: Adnan Abdulhussein <aadnan@vmware.com>
* periodically check for stale restic repo locks
Signed-off-by: Steve Kriss <krisss@vmware.com>
* changelog
Signed-off-by: Steve Kriss <krisss@vmware.com>
* only try to init a restic repo if it doesn't already exist
Signed-off-by: Steve Kriss <krisss@vmware.com>
* reword comment
Signed-off-by: Steve Kriss <krisss@vmware.com>
* migrate pkg/backup restic tests to new structure
Signed-off-by: Steve Kriss <krisss@vmware.com>
* rename backup_new_test.go to backup_test.go
Signed-off-by: Steve Kriss <krisss@vmware.com>
* use pod volume backup builder
Signed-off-by: Steve Kriss <krisss@vmware.com>
* remove docs header about project rename
Signed-off-by: Steve Kriss <krisss@vmware.com>
* remove Upgrade to 1.0 page from master TOC
Signed-off-by: Steve Kriss <krisss@vmware.com>
* standardize TOC titles
Signed-off-by: Steve Kriss <krisss@vmware.com>
* add backup/restore docs for undocumented features
Signed-off-by: Steve Kriss <krisss@vmware.com>
Without the incremental switch, live rebuilds were taking 20s (on a
Linux host) for a single-line change. With the switch, they dropped to
8s.
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
Flags specifying the kubeconfig or kubecontext to use weren't actually
being used by the install command.
Fixes#1651
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Remove references to apps/v1beta1 API group
In Kubernetes v1.16, the apps/v1 API group will be the default served
for relevant resources.
Update any references to apps/v1beta1 for fowards compatibility.
Fixes#1672
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Update API group on plugin commands
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* add restore item action to change PVC/PV storage class name
Signed-off-by: Steve Kriss <krisss@vmware.com>
* code review
Signed-off-by: Steve Kriss <krisss@vmware.com>
* change existing plugin names to lowercase/hyphenated
Signed-off-by: Steve Kriss <krisss@vmware.com>
* add validation for new storage class name
Signed-off-by: Steve Kriss <krisss@vmware.com>
* add test cases
Signed-off-by: Steve Kriss <krisss@vmware.com>
* changelog
Signed-off-by: Steve Kriss <krisss@vmware.com>
* fix imports
Signed-off-by: Steve Kriss <krisss@vmware.com>
* update plugin names to be more consistent
Signed-off-by: Steve Kriss <krisss@vmware.com>
* update unit tests to use pkg/test object constructors
Signed-off-by: Steve Kriss <krisss@vmware.com>
CSI volumes are mounted one level deeper than "native" kubernetes
volumes, and this needs to be appended for proper restic support.
Fixes#1313.
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* allow users to specify additional Velero/restic pod annotations on the command line with the pod-annotations flag
Signed-off-by: Traci Kamp <traci.kamp@gmail.com>
* record PodVolumeBackup start and completion timestamps
adds startTimestamp and completionTimestamp fields to the
PodVolumeBackup status spec
Signed-off-by: Adnan Abdulhussein <aadnan@vmware.com>
* record PodVolumeRestore start and completion timestamps
Signed-off-by: Adnan Abdulhussein <aadnan@vmware.com>
* migrate hooks tests
Signed-off-by: Steve Kriss <krisss@vmware.com>
* add more test cases
Signed-off-by: Steve Kriss <krisss@vmware.com>
* refactor to strongly typed expectation, add pre+post hook test case
Signed-off-by: Steve Kriss <krisss@vmware.com>
* allow exclusion of resources using standard label
excludes any resources with the velero.io/exclude-from-backup=true label
Signed-off-by: Adnan Abdulhussein <aadnan@vmware.com>
* ensure backup item action modifications reflected in tarball filepath
This patch ensures the updated backup item's name and namespace are used
when constructing the filepath for the tarball.
Signed-off-by: Adnan Abdulhussein <aadnan@vmware.com>
* changelog
Signed-off-by: Adnan Abdulhussein <aadnan@vmware.com>
* added top spacing and reduced bottom
Signed-off-by: Ross Fenrick <rossf@heptio.com>
* added marign to h3's
Signed-off-by: Ross Fenrick <rossf@heptio.com>
* Add restic instructions for Enterprise PKS
Signed-off-by: Stephen Carter <carters@vmware.com>
* Add instructions to v1.0.0 docs
Signed-off-by: Stephen Carter <carters@vmware.com>
This fix initialises an empty map if the request object's Labels map
is nil, allowing the controller to later add and modify labels on the
object.
Signed-off-by: Adnan Abdulhussein <aadnan@vmware.com>
* migrate and enhance backup item action tests
Signed-off-by: Steve Kriss <krisss@vmware.com>
* migrate terminating resource test
Signed-off-by: Steve Kriss <krisss@vmware.com>
* add godoc for test functions
Signed-off-by: Steve Kriss <krisss@vmware.com>
* Adding in Jekyll site | Adjusting gitignore for Jekyll build | Moving docs to site folder
Signed-off-by: Lee Springer <lee@smalltalk.agency>
Adding in Jekyll site | Adjusting gitignore for Jekyll build | Moving docs to site folder
Signed-off-by: Lee Springer <lee@smalltalk.agency>
* Restore main.go to original location
Signed-off-by: Lee Springer <lee@smalltalk.agency>
* Updates to footer
Signed-off-by: Lee Springer <lee@smalltalk.agency>
* Updates to homepage links
Signed-off-by: Lee Springer <lee@smalltalk.agency>
* Content updates
Signed-off-by: Lee Springer <lee@smalltalk.agency>
`velero snapshot-location create` existed, but not `velero create
snapshot-location`; update subcommand for parity with backup-location
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
When using `velero install`, the image used should be a reasonable
default, even if buildinfo.Version is missing (such as when using `go
build` directly).
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
Velero should handle cases when the label length exceeds 63 characters.
- if the length of the backup/restore name is <= 63 characters, use it as the value of the label
- if it's > 63 characters, take the SHA256 hash of the name. the value of
the label will be the first 57 characters of the backup/restore name
plus the first six characters of the SHA256 hash.
Fixes heptio#1021
Signed-off-by: Anshul Chandra <anshulc@vmware.com>
Using only the `component: velero` selector caused the restic pods to be
matched, as well, which made things such as `kubectl logs` return too
much information.
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
Prior to 1.0, user-provided values such as cloud provider names didn't
need to be namespaced. This change allows those values to continue
working without the user editing the fields manually.
Fixes#1363
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Adds support for allowing a RestoreItemAction to skip item restore
This allows a RestoreItemAction plugin to signal to velero that
the returned item should be skipped rather than restored to the
cluster.
To support this, a boolean SkipRestore attribute is added to
RestoreItemActionExecuteOutput. If restore.restoreResource finds
this set to true, any remaining actions on this item are skipped,
and restore on this item is skipped. Execution continues with
the next item of this resource type.
To signal this for a particular item, the RestoreItemAction's
Execute method should call WithoutRestore() on the
RestoreItemActionExecuteOutput before returning it.
Signed-off-by: Scott Seago <sseago@redhat.com>
* Autogenerated code to support SkipRestore
Signed-off-by: Scott Seago <sseago@redhat.com>
* Added changelog for #1336
Signed-off-by: Scott Seago <sseago@redhat.com>
Original error was:
```
ark -n <redacted> restore logs <redacted>
time="2019-03-06T18:31:06Z" level=info msg="Not including resource" groupResource=nodes logSource="pkg/restore/restore.go:124"
time="2019-03-06T18:31:06Z" level=info msg="Not including resource" groupResource=events logSource="pkg/restore/restore.go:124"
time="2019-03-06T18:31:06Z" level=info msg="Not including resource" groupResource=events.events.k8s.io logSource="pkg/restore/restore.go:124"
time="2019-03-06T18:31:06Z" level=info msg="Not including resource" groupResource=backups.ark.heptio.com logSource="pkg/restore/restore.go:124"
time="2019-03-06T18:31:06Z" level=info msg="Not including resource" groupResource=restores.ark.heptio.com logSource="pkg/restore/restore.go:124"
time="2019-03-06T18:31:06Z" level=info msg="Starting restore of backup backup/<redacted>" logSource="pkg/restore/restore.go:342"
time="2019-03-06T18:31:06Z" level=info msg="error unzipping and extracting: open /tmp/604421455/resources/rolebindings.rbac.authorization.k8s.io/namespaces/<redacted>/<redacted>: too many open files" logSource="pkg/restore/restore.go:346"
```
Downloading the directory from s3 and untarring it I found 1036 files. The ulimit -n output says 1024. This is our team's best guess at a root cause. But the code fixed in the PR definitely is holding all the files open until the method closes: https://blog.learngoprogramming.com/gotchas-of-defer-in-go-1-8d070894cb01
Please note my go code abilities are not great and I did not test this. I just edited the file in github. All I did was remove the defer and put fileClose after the copy is done. Theoretically this should only hold one file open at a time now. Let me know if you want me to do any further steps.
Thank you,
-Asaf
Signed-off-by: Asaf Erlich <aerlich@groupon.com>
* Move Phase to right under Metadata(name/namespace/label/annotations)
* Move Validation errors: section right after Phase: section and only
show it if the item has a phase of FailedValidation
* For restores move Warnings and Errors under Validation errors. Do not
show Warnings or Errors if there are none.
Signed-off-by: DheerajSShetty <dheerajs@vmware.com>
Fixes#987
To create a regional disk, the URLs for the zones in which the disk is
replicated must be provided to the GCP API.
Fixes#1183
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
Due to the assumption of building from a git repository inherent in the
Makefile targets, update the documentation to limit source code archive
builds to the `go build` commands.
Note that it may be possible to update hack/build.sh to cope with
building outside a git repository, but there are a number of questions
to answer regarding how to populate the buildinfo info, and that is a
larger discussion than ensuring we can build the binary from the sources
in the source code archive.
Signed-off-by: Darren Hart <dvhart@vmware.com>
Update the documentation to include minimal instructions for building
the velero binary from the GitHub Release "Source code" archive.
Correct the Download link in the Table of Contents for
build-from-scratch.md.
Signed-off-by: Darren Hart <dvhart@vmware.com>
If a PV already exists, wait for it, it's associated PVC, and associated
namespace to be deleted before attempting to restore it.
If a namespace already exists, wait for it to be deleted before
attempting to restore it.
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
The binary, deployment, and namespace have yet to change for most users,
so make sure the bug template has the correct information when filing.
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
@@ -14,11 +14,11 @@ about: Tell us about a problem you are experiencing
**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.)
*`kubectl logs deployment/ark -n heptio-ark`
*`ark backup describe <backupname>` or `kubectl get backup/<backupname> -n heptio-ark -o yaml`
*`ark backup logs <backupname>`
*`ark restore describe <restorename>` or `kubectl get restore/<restorename> -n heptio-ark -o yaml`
*`ark restore logs <restorename>`
-`kubectl logs deployment/velero -n velero`
-`velero backup describe <backupname>` or `kubectl get backup/<backupname> -n velero -o yaml`
-`velero backup logs <backupname>`
-`velero restore describe <restorename>` or `kubectl get restore/<restorename> -n velero -o yaml`
-`velero restore logs <restorename>`
**Anything else you would like to add:**
@@ -27,8 +27,18 @@ about: Tell us about a problem you are experiencing
**Environment:**
-Ark version (use `ark version`):
-Velero version (use `velero version`):
- Velero features (use `velero client config get features`):
- Kubernetes version (use `kubectl version`):
- Kubernetes installer & version:
- Cloud provider or hardware configuration:
- OS (e.g. from `/etc/os-release`):
**Vote on this issue!**
This is an invitation to the Velero community to vote on issues, you can see the project's [top voted issues listed here](https://github.com/vmware-tanzu/velero/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc).
Use the "reaction smiley face" up to the right of this comment to vote.
- :+1: for "I would like to see this bug fixed as soon as possible"
- :-1: for "There are more important bugs to focus on right now"
@@ -4,6 +4,10 @@ about: Suggest an idea for this project
---
**Describe the problem/challenge you have**
[A description of the current limitation/problem/challenge that you are experiencing.]
**Describe the solution you'd like**
[A clear and concise description of what you want to happen.]
@@ -14,8 +18,16 @@ about: Suggest an idea for this project
**Environment:**
-Ark version (use `ark version`):
-Velero version (use `velero version`):
- Kubernetes version (use `kubectl version`):
- Kubernetes installer & version:
- Cloud provider or hardware configuration:
- OS (e.g. from `/etc/os-release`):
**Vote on this issue!**
This is an invitation to the Velero community to vote on issues, you can see the project's [top voted issues listed here](https://github.com/vmware-tanzu/velero/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc).
Use the "reaction smiley face" up to the right of this comment to vote.
- :+1: for "The project would be better with this feature added"
- :-1: for "This feature will not enhance the project in a meaningful way"
Below is a list of adopters of Velero in **production environments** that have
publicly shared the details of how they use it.
**[BitGo][20]**
BitGo uses Velero backup and restore capabilities to seamlessly provision and scale fullnode statefulsets on the fly as well as having it serve an integral piece for our kubernetes disaster-recovery story.
**[Bugsnag][30]**
We use Velero for managing backups of an internal instance of our on-premise clustered solution. We also recommend our users of [on-premise Bugsnag installations][31] use Velero for [managing their own backups][32].
**[Banzai Cloud][60]**
[Banzai Cloud Pipeline][61] is a Kubernetes-based microservices platform that integrates services needed for Day-1 and Day-2 operations along with first-class support both for on-prem and hybrid multi-cloud deployments. We use Velero to periodically [backup and restore these clusters in case of disasters][62].
## Solutions built with Velero
Below is a list of solutions where Velero is being used as a component.
**[Nirmata][10]**
We have integrated our [solution with Velero][11] to provide our customers with out of box backup/DR.
**[Kyma][40]**
Kyma [integrates with Velero][41] to effortlessly back up and restore Kyma clusters with all its resources. Velero capabilities allow Kyma users to define and run manual and scheduled backups in order to successfully handle a disaster-recovery scenario.
**[Red Hat][50]**
Red Hat has developed the [Cluster Application Migration Tool][51] which uses [Velero and Restic][52] to drive the migration of applications between OpenShift clusters.
**[Dell EMC][70]**
For Kubernetes environments, [PowerProtect Data Manager][71] leverages the Container Storage Interface (CSI) framework to take snapshots to back up the persistent data or the data that the application creates e.g. databases. [Dell EMC leverages Velero][72] to backup the namespace configuration files (also known as Namespace meta data) for enterprise grade data protection.
**[SIGHUP][80]**
SIGHUP integrates Velero in its [Fury Kubernetes Distribution][81] providing predefined schedules and configurations to ensure an optimized disaster recovery experience.
[Fury Kubernetes Disaster Recovery Module][82] is ready to be deployed into any Kubernetes cluster running anywhere.
**[MayaData][90]**
MayaData is a large user of Velero as well as a contributor. MayaData offers a Data Agility platform called [OpenEBS Director][91], that helps customers confidently and easily manage stateful workloads in Kubernetes. Velero is one of the core software building block of the OpenEBS Director's [DMaaS or data migration as a service offering][92] used to enable data protection strategies.
**[Okteto][93]**
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.
## 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/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].
### Adding a logo to velero.io
If you would like to add your logo to a future `Adopters of Velero` section on [velero.io][2], follow the steps above to add your organization to the list of Velero Adopters. Our community will follow up and publish it to the [velero.io][2] website.
As contributors and maintainers of this project, and in the interest of fostering
an open and welcoming community, we pledge to respect all people who contribute
through reporting issues, posting feature requests, updating documentation,
submitting pull requests or patches, and other activities.
We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.
We are committed to making participation in this project a harassment-free experience for
everyone, regardless of level of experience, gender, gender identity and expression,
sexual orientation, disability, personal appearance, body size, race, ethnicity, age,
religion, or nationality.
We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.
Examples of unacceptable behavior by participants include:
## Our Standards
* The use of sexualized language or imagery
* Personal attacks
*Trolling or insulting/derogatory comments
Examples of behavior that contributes to a positive environment for our community include:
*Demonstrating empathy and kindness toward other people
* Being respectful of differing opinions, viewpoints, and experiences
* Giving and gracefully accepting constructive feedback
* Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
* Focusing on what is best not just for us as individuals, but for the overall community
Examples of unacceptable behavior include:
* The use of sexualized language or imagery, and sexual attention or
advances of any kind
* Trolling, insulting or derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing other's private information, such as physical or electronic addresses,
without explicit permission
* Other unethical or unprofessional conduct.
* Publishing others' private information, such as a physical or email
address, without their explicit permission
* Other conduct which could reasonably be considered inappropriate in a
professional setting
Project maintainers have the right and responsibility to remove, edit, or reject
comments, commits, code, wiki edits, issues, and other contributions that are not
aligned to this Code of Conduct. By adopting this Code of Conduct, project maintainers
commit themselves to fairly and consistently applying these principles to every aspect
of managing this project. Project maintainers who do not follow or enforce the Code of
Conduct may be permanently removed from the project team.
## Enforcement Responsibilities
This code of conduct applies both within project spaces and in public spaces
when an individual is representing the project or its community.
Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project maintainer(s).
Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.
This Code of Conduct is adapted from the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md) and [Contributor Covenant](http://contributor-covenant.org/version/1/2/0/), version 1.2.0.
## Scope
This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at [oss-coc@vmware.com](mailto:oss-coc@vmware.com). All complaints will be reviewed and investigated promptly and fairly.
All community leaders are obligated to respect the privacy and security of the reporter of any incident.
## Enforcement Guidelines
Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:
### 1. Correction
**Community Impact**: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.
**Consequence**: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.
### 2. Warning
**Community Impact**: A violation through a single incident or series of actions.
**Consequence**: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.
### 3. Temporary Ban
**Community Impact**: A serious violation of community standards, including sustained inappropriate behavior.
**Consequence**: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.
### 4. Permanent Ban
**Community Impact**: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.
**Consequence**: A permanent ban from any sort of public interaction within the community.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 2.0,
available at https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.
Community Impact Guidelines were inspired by [Mozilla's code of conduct enforcement ladder](https://github.com/mozilla/diversity).
[homepage]: https://www.contributor-covenant.org
For answers to common questions about this code of conduct, see the FAQ at
https://www.contributor-covenant.org/faq. Translations are available at https://www.contributor-covenant.org/translations.
Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129
Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
```
Authors are expected to follow some guidelines when submitting PRs. Please see [our documentation](https://velero.io/docs/master/code-standards/) for details.
This document defines the project governance for Velero.
## Overview
**Velero**, an open source project, is committed to building an open, inclusive, productive and self-governing open source community focused on building a high quality tool that enables users to safely backup and restore, perform disaster recovery, and migrate Kubernetes cluster resources and persistent volumes. The community is governed by this document with the goal of defining how community should work together to achieve this goal.
## Code Repositories
The following code repositories are governed by Velero community and maintained under the `vmware-tanzu\Velero` organization.
* **[Velero](https://github.com/vmware-tanzu/velero):** Main Velero codebase
* **[Helm Chart](https://github.com/vmware-tanzu/helm-charts/tree/master/charts/velero):** The Helm chart for the Velero server component
* **[Velero CSI Plugin](https://github.com/vmware-tanzu/velero-plugin-for-csi):** This repository contains Velero plugins for snapshotting CSI backed PVCs using the CSI beta snapshot APIs
* **[Velero Plugin for vSphere](https://github.com/vmware-tanzu/velero-plugin-for-vsphere):** This repository contains the Velero Plugin for vSphere. This plugin is a volume snapshotter plugin that provides crash-consistent snapshots of vSphere block volumes and backup of volume data into S3 compatible storage.
* **[Velero Plugin for AWS](https://github.com/vmware-tanzu/velero-plugin-for-aws):** This repository contains the plugins to support running Velero on AWS, including the object store plugin and the volume snapshotter plugin
* **[Velero Plugin for GCP](https://github.com/vmware-tanzu/velero-plugin-for-gcp):** This repository contains the plugins to support running Velero on GCP, including the object store plugin and the volume snapshotter plugin
* **[Velero Plugin for Azure](https://github.com/vmware-tanzu/velero-plugin-for-microsoft-azure):** This repository contains the plugins to support running Velero on Azure, including the object store plugin and the volume snapshotter plugin
* **[Velero Plugin Example](https://github.com/vmware-tanzu/velero-plugin-example):** This repository contains example plugins for Velero
## Community Roles
* **Users:** Members that engage with the Velero community via any medium (Slack, GitHub, mailing lists, etc.).
* **Contributors:** Regular contributions to projects (documentation, code reviews, responding to issues, participation in proposal discussions, contributing code, etc.).
* **Maintainers**: The Velero project leaders. They are responsible for the overall health and direction of the project; final reviewers of PRs and responsible for releases. Some Maintainers are responsible for one or more components within a project, acting as technical leads for that component. Maintainers are expected to contribute code and documentation, review PRs including ensuring quality of code, triage issues, proactively fix bugs, and perform maintenance tasks for these components.
### Maintainers
New maintainers must be nominated by an existing maintainer and must be elected by a supermajority of existing maintainers. Likewise, maintainers can be removed by a supermajority of the existing maintainers or can resign by notifying one of the maintainers.
### Supermajority
A supermajority is defined as two-thirds of members in the group.
A supermajority of [Maintainers](#maintainers) is required for certain
decisions as outlined above. A supermajority vote is equivalent to the number of votes in favor being at least twice the number of votes against. For example, if you have 5 maintainers, a supermajority vote is 4 votes. Voting on decisions can happen on the mailing list, GitHub, Slack, email, or via a voting service, when appropriate. Maintainers can either vote "agree, yes, +1", "disagree, no, -1", or "abstain". A vote passes when supermajority is met. An abstain vote equals not voting at all.
### Decision Making
Ideally, all project decisions are resolved by consensus. If impossible, any
maintainer may call a vote. Unless otherwise specified in this document, any
vote will be decided by a supermajority of maintainers.
Votes by maintainers belonging to the same company
will count as one vote; e.g., 4 maintainers employed by fictional company **Valerium** will
only have **one** combined vote. If voting members from a given company do not
agree, the company's vote is determined by a supermajority of voters from that
company. If no supermajority is achieved, the company is considered to have
abstained.
## Proposal Process
One of the most important aspects in any open source community is the concept
of proposals. Large changes to the codebase and / or new features should be
preceded by a proposal in our community repo. This process allows for all
members of the community to weigh in on the concept (including the technical
details), share their comments and ideas, and offer to help. It also ensures
that members are not duplicating work or inadvertently stepping on toes by
making large conflicting changes.
The project roadmap is defined by accepted proposals.
Proposals should cover the high-level objectives, use cases, and technical
recommendations on how to implement. In general, the community member(s)
interested in implementing the proposal should be either deeply engaged in the
proposal process or be an author of the proposal.
The proposal should be documented as a separated markdown file pushed to the root of the
`design` folder in the [Velero](https://github.com/vmware-tanzu/velero/tree/master/design)
repository via PR. The name of the file should follow the name pattern `<short
meaningful words joined by '-'>_design.md`, e.g:
`restore-hooks-design.md`.
Use the [Proposal Template](https://github.com/vmware-tanzu/velero/blob/master/design/_template.md) as a starting point.
### Proposal Lifecycle
The proposal PR can follow the GitHub lifecycle of the PR to indicate its status:
* **Open**: Proposal is created and under review and discussion.
* **Merged**: Proposal has been reviewed and is accepted (either by consensus or through a vote).
* **Closed**: Proposal has been reviewed and was rejected (either by consensus or through a vote).
## Lazy Consensus
To maintain velocity in a project as busy as Velero, the concept of [Lazy
Consensus](http://en.osswiki.info/concepts/lazy_consensus) is practiced. Ideas
and / or proposals should be shared by maintainers via
GitHub with the appropriate maintainer groups (e.g.,
`@vmware-tanzu/velero-maintainers`) tagged. Out of respect for other contributors,
major changes should also be accompanied by a ping on Slack or a note on the
Velero mailing list as appropriate. Author(s) of proposal, Pull Requests,
issues, etc. will give a time period of no less than five (5) working days for
comment and remain cognizant of popular observed world holidays.
Other maintainers may chime in and request additional time for review, but
should remain cognizant of blocking progress and abstain from delaying
progress unless absolutely needed. The expectation is that blocking progress
is accompanied by a guarantee to review and respond to the relevant action(s)
(proposals, PRs, issues, etc.) in short order.
Lazy Consensus is practiced for all projects in the `Velero` org, including
the main project repository and the additional repositories.
Lazy consensus does _not_ apply to the process of:
* Removal of maintainers from Velero
## Updating Governance
All substantive changes in Governance require a supermajority agreement by all maintainers.
Ark gives you tools to back up and restore your Kubernetes cluster resources and persistent volumes. Ark lets you:
Velero (formerly Heptio Ark) gives you tools to back up and restore your Kubernetes cluster resources and persistent volumes. You can run Velero with a public cloud platform or on-premises. Velero lets you:
* Take backups of your cluster and restore in case of loss.
*Copy cluster resources to other clusters.
* Replicate your production environment for development and testing environments.
*Migrate cluster resources to other clusters.
* Replicate your production cluster to development and testing clusters.
Ark consists of:
Velero consists of:
* A server that runs on your cluster
* A command-line client that runs locally
You can run Ark in clusters on a cloud provider or on-premises. For detailed information, see [Compatible Storage Providers][99].
## Documentation
## Breaking changes
[The documentation][29] provides a getting started guide and information about building from source, architecture, extending Velero, and more.
Ark version 0.10.0 introduces a number of breaking changes. Before you upgrade to version 0.10.0, make sure to read [the documentation on upgrading][98].
## More information
[The documentation][29] provides a getting started guide, plus information about building from source, architecture, extending Ark, and more.
Please use the version selector at the top of the site to ensure you are using the appropriate documentation for your version of Velero.
## Troubleshooting
If you encounter issues, review the [troubleshooting docs][30], [file an issue][4], or talk to us on the [#ark-dr channel][25] on the Kubernetes Slack server.
If you encounter issues, review the [troubleshooting docs][30], [file an issue][4], or talk to us on the [#velero channel][25] on the Kubernetes Slack server.
## Contributing
Thanks for taking the time to join our community and start contributing!
Feedback and discussion are available on [the mailing list][24].
### Before you start
* Please familiarize yourself with the [Code of Conduct][8] before contributing.
* See [CONTRIBUTING.md][5] for instructions on the developer certificate of origin that we require.
* Read how [we're using ZenHub][26] for project and roadmap planning
### Pull requests
* We welcome pull requests. Feel free to dig through the [issues][4] and jump in.
If you are ready to jump in and test, add code, or help with documentation, follow the instructions on our [Start contributing][31] documentation for guidance on how to setup Velero for development.
## Changelog
See [the list of releases][6] to find out about feature changes.
This document provides a link to the [Velero Project board](https://app.zenhub.com/workspaces/velero-5c59c15e39d47b774b5864e3/board?repos=99143276,112385197,190224441,214524700,214524630,213946861) that serves as the up to date description of items that are in the release pipeline. The board has separate swim lanes based on prioritization. Most items are gathered from the community or include a feedback loop with the community. This should serve as a reference point for Velero users and contributors to understand where the project is heading, and help determine if a contribution could be conflicting with a longer term plan. You will need the ZenHub plugin to view the board.
### How to help?
Discussion on the roadmap can take place in threads under [Issues](https://github.com/vmware-tanzu/velero/issues) or in [community meetings](https://velero.io/community/). Please open and comment on an issue if you want to provide suggestions, use cases, and feedback to an item in the roadmap. Please review the roadmap to avoid potential duplicated effort.
### How to add an item to the roadmap?
One of the most important aspects in any open source community is the concept of proposals. Large changes to the codebase and / or new features should be preceded by a [proposal](https://github.com/vmware-tanzu/velero/blob/master/GOVERNANCE.md#proposal-process) in our repo.
For smaller enhancements, you can open an issue to track that initiative or feature request.
We work with and rely on community feedback to focus our efforts to improve Velero and maintain a healthy roadmap.
### Current Roadmap
The following table includes the current roadmap for Velero. If you have any questions or would like to contribute to Velero, please attend a [community meeting](https://velero.io/community/) to discuss with our team. If you don't know where to start, we are always looking for contributors that will help us reduce technical, automation, and documentation debt.
Please take the timelines & dates as proposals and goals. Priorities and requirements change based on community feedback, roadblocks encountered, community contributions, etc. If you depend on a specific item, we encourage you to attend community meetings to get updated status information, or help us deliver that feature by contributing to Velero.
`Last Updated: May 2020`
|Theme|Description|Timeline|
|--|--|--|
|Restic Improvements|Introduce improvements in annotating resources for Restic backup|August 2020|
|Extensibility|Add restore hooks for enhanced recovery scenarios|August 2020|
|CSI|Continue improving the CSI snapshot capabilities and participate in the upstream K8s CSI community|Long running (dependent on CSI working group)|
|Backup/Restore|Improvements to long-running copy operations from a performance and reliability standpoint|August 2020|
|UX|Improvements to install and configuration user experience|August 2020|
|Restic Improvements|Improve the use of Restic in Velero and offer stable support|Dec 2020|
|Perf & Scale|Introduce a scalable model by using a worker pod for each backup/restore operation and improve operations|Dec 2020|
|Backup/Restore|Better backup and restore semantics for certain Kubernetes resources like stateful sets, operators|Dec 2020|
|Security|Enable the use of custom credential providers|Dec 2020|
|Self-Service & Multitenancy|Reduce friction by enabling developers to backup their namespaces via self-service. Introduce a Velero multi-tenancy model, enabling owners of namespaces to backup and restore within their access scope|Mar 2021|
|Backup/Restore|Cross availability zone or region backup and restore|Mar 2021|
|Application Consistency|Offer blueprints for backing up and restoring popular applications|May 2021|
|Backup/Restore|Data only backup and restore|May 2021|
|Backup/Restore|Introduce the ability to overwrite existing objects during a restore|May 2021|
|Backup/Restore|What-if dry run for backup and restore|May 2021|
* Added the `velero migrate-backups` command to migrate legacy Ark backup metadata to the current Velero format in object storage. This command needs to be run in preparation for upgrading to v1.0, **if** you have backups that were originally created prior to v0.11 (i.e. when the project was named Ark).
* Heptio Ark is now Velero! This release is the first one to use the new name. For details on the changes and how to migrate to v0.11, see the [migration instructions][1]. **Please follow the instructions to ensure a successful upgrade to v0.11.**
* Restic has been upgraded to v0.9.4, which brings significantly faster restores thanks to a new multi-threaded restorer.
* Velero now waits for terminating namespaces and persistent volumes to delete before attempting to restore them, rather than trying and failing to restore them while they're being deleted.
* Wait for PVs and namespaces to delete before attempting to restore them. (#826, @nrb)
* Set the zones for GCP regional disks on restore. This requires the `compute.zones.get` permission on the GCP serviceaccount in order to work correctly. (#1200, @nrb)
* Renamed Heptio Ark to Velero. Changed internal imports, environment variables, and binary name. (#1184, @nrb)
* use 'restic stats' instead of 'restic check' to determine if repo exists (#1171, @skriss)
* upgrade restic to v0.9.4 & replace --hostname flag with --host (#1156, @skriss)
* Clarify restore log when object unchanged (#1153, @daved)
* Add backup-version file in backup tarball. (#1117, @wwitzel3)
* add ServerStatusRequest CRD and show server version in `ark version` output (#1116, @skriss)
- We've added a new command, `velero install`, to make it easier to get up and running with Velero. This CLI command replaces the static YAML installation files that were previously part of release tarballs. See the updated [install instructions][3] for more information.
- We've made a number of improvements to the plugin framework:
- we've reorganized the relevant packages to minimize the import surface for plugin authors
- all plugins are now wrapped in panic handlers that will report information on panics back to Velero
- Velero's `--log-level` flag is now passed to plugin implementations
- Errors logged within plugins are now annotated with the file/line of where the error occurred
- Restore item actions can now optionally return a list of additional related items that should be restored
- Restore item actions can now indicate that an item *should not* be restored
- For Azure installation, the `cloud-credentials` secret can now be created from a file containing a list of environment variables. Note that `velero install` always uses this method of providing credentials for Azure. For more details, see [Run on Azure][0].
- We've added a new phase, `PartiallyFailed`, for both backups and restores. This new phase is used for backups/restores that successfully process some but not all of their items.
- We removed all legacy Ark references, including API types, prometheus metrics, restic & hook annotations, etc.
- The restic integration remains a **beta feature**. Please continue to try it out and provide feedback, and we'll be working over the next couple of releases to bring it to GA.
### Breaking Changes
#### API
* All legacy Ark data types and pre-1.0 compatibility code has been removed. Users should migrate any backups created pre-v0.11.0 with the `velero migrate-backups` command, available in [v0.11.1][2].
#### Image
* The base container image has been switched to `ubuntu:bionic`
#### Labels/Annotations/Metrics
* The "ark" annotations for specifying hooks are no longer supported, and have been replaced with "velero"-based equivalents.
* The "ark" annotation for specifying restic backups is no longer supported, and has been replaced with a "velero"-based equivalent.
* The "ark" prometheus metrics no longer exist, and have been replaced with "velero"-based equivalents.
#### Plugin Development
*`BlockStore` plugins are now named `VolumeSnapshotter` plugins
* Plugin APIs have moved to reduce the import surface:
* Plugin gRPC servers live in `github.com/heptio/velero/pkg/plugin/framework`
* Plugin interface types live in `github.com/heptio/velero/pkg/plugin/velero`
* RestoreItemAction interface now takes the original item from the backup as a parameter
* RestoreItemAction plugins can now return additional items to restore
* RestoreItemAction plugins can now skip restoring an item
* Plugins may now send stack traces with errors to the Velero server, so that the errors may be put into the server log
* Plugins must now be "namespaced," using `example.domain.com/plugin-name` format
* For external ObjectStore and VolumeSnapshotter plugins. this name will also be the provider name in BackupStorageLoction and VolumeSnapshotLocation objects
*`--log-level` flag is now passed to all plugins
#### Validation
* Configs for Azure, AWS, and GCP are now checked for invalid or extra keys, and the server is halted if any are found
To upgrade from a previous version of Velero, see our [upgrade instructions][1].
### All Changes
* Change base images to ubuntu:bionic (#1488, @skriss)
* Expose the timestamp of the last successful backup in a gauge (#1448, @fabito)
* check backup existence before download (#1447, @fabito)
* Use `latest` image tag if no version information is provided at build time (#1439, @nrb)
* switch from `restic stats` to `restic snapshots` for checking restic repository existence (#1416, @skriss)
* GCP: add optional 'project' config to volume snapshot location for if snapshots are in a different project than the IAM account (#1405, @skriss)
* Disallow bucket names starting with '-' (#1407, @nrb)
* Shorten label values when they're longer than 63 characters (#1392, @anshulc)
* Fail backup if it already exists in object storage. (#1390, @ncdc,carlisia)
* Add PartiallyFailed phase for backups, log + continue on errors during backup process (#1386, @skriss)
* Remove deprecated "hooks" for backups (they've been replaced by "pre hooks") (#1384, @skriss)
* Restic repo ensurer: return error if new repository does not become ready within a minute, and fix channel closing/deletion (#1367, @skriss)
* Support non-namespaced names for built-in plugins (#1366, @nrb)
* Change container base images to debian:stretch-slim and upgrade to go 1.12 (#1365, @skriss)
* Azure: allow credentials to be provided in a .env file (path specified by $AZURE_CREDENTIALS_FILE), formatted like (#1364, @skriss):
```
AZURE_TENANT_ID=${AZURE_TENANT_ID}
AZURE_SUBSCRIPTION_ID=${AZURE_SUBSCRIPTION_ID}
AZURE_CLIENT_ID=${AZURE_CLIENT_ID}
AZURE_CLIENT_SECRET=${AZURE_CLIENT_SECRET}
AZURE_RESOURCE_GROUP=${AZURE_RESOURCE_GROUP}
```
* Instantiate the plugin manager with the per-restore logger so plugin logs are captured in the per-restore log (#1358, @skriss)
* Add gauge metrics for number of existing backups and restores (#1353, @fabito)
* Set default TTL for backups (#1352, @vorar)
* Validate that there can't be any duplicate plugin name, and that the name format is `example.io/name`. (#1339, @carlisia)
* AWS/Azure/GCP: fail fast if unsupported keys are provided in BackupStorageLocation/VolumeSnapshotLocation config (#1338, @skriss)
* `velero backup logs` & `velero restore logs`: show helpful error message if backup/restore does not exist or is not finished processing (#1337, @skriss)
* Add support for allowing a RestoreItemAction to skip item restore. (#1336, @sseago)
* Improve error message around invalid S3 URLs, and gracefully handle trailing backslashes. (#1331, @skriss)
* Set backup's start timestamp before patching it to InProgress so start times display in `velero backup get` while in progress (#1330, @skriss)
* Added ability to dynamically disable controllers (#1326, @amanw)
* Remove deprecated code in preparation for v1.0 release (#1323, @skriss):
- remove ark.heptio.com API group
- remove support for reading ark-backup.json files from object storage
- remove Ark field from RestoreResult type
- remove support for "hook.backup.ark.heptio.com/..." annotations for specifying hooks
- remove support for $HOME/.config/ark/ client config directory
- remove support for restoring Azure snapshots using short snapshot ID formats in backup metadata
- stop applying "velero-restore" label to restored resources and remove it from the API pkg
- remove code that strips the "gc.ark.heptio.com" finalizer from backups
- remove support for "backup.ark.heptio.com/..." annotations for requesting restic backups
- remove "ark"-prefixed prometheus metrics
- remove VolumeBackups field and related code from Backup's status
* Rename BlockStore plugin to VolumeSnapshotter (#1321, @skriss)
* Bump plugin ProtocolVersion to version 2 (#1319, @carlisia)
* Remove Warning field from restore item action output (#1318, @skriss)
* Fix for #1312, use describe to determine if AWS EBS snapshot is encrypted and explicitly pass that value in EC2 CreateVolume call. (#1316, @mstump)
* Allow restic restore helper image name to be optionally specified via ConfigMap (#1311, @skriss)
* Compile only once to lower the initialization cost for regexp.MustCompile. (#1306, @pei0804)
* Enable restore item actions to return additional related items to be restored; have pods return PVCs and PVCs return PVs (#1304, @skriss)
* Log error locations from plugin logger, and don't overwrite them in the client logger if they exist already (#1301, @skriss)
* Send stack traces from plugin errors to Velero via gRPC so error location info can be logged (#1300, @skriss)
* Azure: restore volumes in the original region's zone (#1298, @sylr)
* Check for and exclude hostPath-based persistent volumes from restic backup (#1297, @skriss)
* Make resticrepositories non-restorable resources (#1296, @skriss)
* Gracefully handle failed API groups from the discovery API (#1293, @fabito)
* Add `velero install` command for basic use cases. (#1287, @nrb)
* Collect 3 new metrics: backup_deletion_{attempt|failure|success}_total (#1280, @fabito)
* Pass --log-level flag to internal/external plugins, matching Velero server's log level (#1278, @skriss)
* AWS EBS Volume IDs now contain AZ (#1274, @tsturzl)
* Add panic handlers to all server-side plugin methods (#1270, @skriss)
* Move all the interfaces and associated types necessary to implement all of the Velero plugins to under the new package `velero`. (#1264, @carlisia)
* Update `velero restore` to not open every single file open during extraction of the data (#1261, @asaf)
* Remove restore code that waits for a PV to become Available (#1254, @skriss)
* Improve `describe` output
* Move Phase to right under Metadata(name/namespace/label/annotations)
* Move Validation errors: section right after Phase: section and only show it if the item has a phase of FailedValidation
* For restores move Warnings and Errors under Validation errors. Leave their display as is. (#1248, @DheerajSShetty)
* Don't remove storage class from a persistent volume when restoring it (#1246, @skriss)
* Need to defer closing the the ReadCloser in ObjectStoreGRPCServer.GetObject (#1236, @DheerajSShetty)
* Update Kubernetes dependencies to match v1.12, and update Azure SDK to v19.0.0 (GA) (#1231, @skriss)
* Remove pkg/util/collections/map_utils.go, replace with structured API types and apimachinery's unstructured helpers (#1146, @skriss)
* Add original resource (from backup) to restore item action interface (#1123, @mwieczorek)
**If you are running Velero in a non-default namespace**, i.e. any namespace other than `velero`, manual intervention is required when upgrading to v1.1. See [upgrading to v1.1](https://velero.io/docs/v1.1.0/upgrade-to-1.1/) for details.
### Highlights
#### Improved Restic Support
A big focus of our work this cycle was continuing to improve support for restic. To that end, we’ve fixed the following bugs:
- Prior to version 1.1, restic backups could be delayed or failed due to long-lived locks on the repository. Now, Velero removes stale locks from restic repositories every 5 minutes, ensuring they do not interrupt normal operations.
- Previously, the PodVolumeBackup custom resources that represented a restic backup within a cluster were not synchronized between clusters, making it unclear what restic volumes were available to restore into a new cluster. In version 1.1, these resources are synced into clusters, so they are more visible to you when you are trying to restore volumes.
- Originally, Velero would not validate the host path in which volumes were mounted on a given node. If a node did not expose the filesystem correctly, you wouldn’t know about it until a backup failed. Now, Velero’s restic server will validate that the directory structure is correct on startup, providing earlier feedback when it’s not.
- Velero’s restic support is intended to work on a broad range of volume types. With the general release of the [Container Storage Interface API](https://kubernetes.io/blog/2019/01/15/container-storage-interface-ga/), Velero can now use restic to back up CSI volumes.
Along with our bug fixes, we’ve provided an easier way to move restic backups between storage providers. Different providers often have different StorageClasses, requiring user intervention to make restores successfully complete.
To make cross-provider moves simpler, we’ve introduced a StorageClass remapping plug-in. It allows you to automatically translate one StorageClass on PersistentVolumeClaims and PersistentVolumes to another. You can read more about it in our [documentation](https://velero.io/docs/v1.1.0/restore-reference/#changing-pv-pvc-storage-classes).
#### Quality-of-Life Improvements
We’ve also made several other enhancements to Velero that should benefit all users.
Users sometimes ask about recommendations for Velero’s resource allocation within their cluster. To help with this concern, we’ve added default resource requirements to the Velero Deployment and restic init containers, along with configurable requests and limits for the restic DaemonSet. All these values can be adjusted if your environment requires it.
We’ve also taken some time to improve Velero for the future by updating the Deployment and DaemonSet to use the apps/v1 API group, which will be the [default in Kubernetes 1.16](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.16.md#action-required-3). This change means that `velero install` and the `velero plugin` commands will require Kubernetes 1.9 or later to work. Existing Velero installs will continue to work without needing changes, however.
In order to help you better understand what resources have been backed up, we’ve added a list of resources in the `velero backup describe --details` command. This change makes it easier to inspect a backup without having to download and extract it.
In the same vein, we’ve added the ability to put custom tags on cloud-provider snapshots. This approach should provide a better way to keep track of the resources being created in your cloud account. To add a label to a snapshot at backup time, use the `--labels` argument in the `velero backup create` command.
Our final change for increasing visibility into your Velero installation is the `velero plugin get` command. This command will report all the plug-ins within the Velero deployment..
Velero has previously used a restore-only flag on the server to control whether a cluster could write backups to object storage. With Velero 1.1, we’ve now moved the restore-only behavior into read-only BackupStorageLocations. This move means that the Velero server can use a BackupStorageLocation as a source to restore from, but not for backups, while still retaining the ability to back up to other configured locations. In the future, the `--restore-only` flag will be removed in favor of configuring read-only BackupStorageLocations.
#### Community Contributions
We appreciate all community contributions, whether they be pull requests, bug reports, feature requests, or just questions. With this release, we wanted to draw attention to a few contributions in particular:
For users of node-based IAM authentication systems such as kube2iam, `velero install` now supports the `--pod-annotations` argument for applying necessary annotations at install time. This support should make `velero install` more flexible for scenarios that do not use Secrets for access to their cloud buckets and volumes. You can read more about how to use this new argument in our [AWS documentation](https://velero.io/docs/v1.1.0/aws-config/#alternative-setup-permissions-using-kube2iam). Huge thanks to [Traci Kamp](https://github.com/tlkamp) for this contribution.
Structured logging is important for any application, and Velero is no different. Starting with version 1.1, the Velero server can now output its logs in a JSON format, allowing easier parsing and ingestion. Thank you to [Donovan Carthew](https://github.com/carthewd) for this feature.
AWS supports multiple profiles for accessing object storage, but in the past Velero only used the default. With v.1.1, you can set the `profile` key on yourBackupStorageLocation to specify an alternate profile. If no profile is set, the default one is used, making this change backward compatible. Thanks [Pranav Gaikwad](https://github.com/pranavgaikwad) for this change.
Finally, thanks to testing by [Dylan Murray](https://github.com/dymurray) and [Scott Seago](https://github.com/sseago), an issue with running Velero in non-default namespaces was found in our beta version for this release. If you’re running Velero in a namespace other than `velero`, please follow the [upgrade instructions](https://velero.io/docs/v1.1.0/upgrade-to-1.1/).
### All Changes
* Add the prefix to BSL config map so that object stores can use it when initializing (#1767, @betta1)
* Use `VELERO_NAMESPACE` to determine what namespace Velero server is running in. For any v1.0 installations using a different namespace, the `VELERO_NAMESPACE` environment variable will need to be set to the correct namespace. (#1748, @nrb)
* support setting CPU/memory requests with unbounded limits using velero install (#1745, @prydonius)
* sort output of resource list in `velero backup describe --details` (#1741, @prydonius)
* adds the ability to define custom tags to be added to snapshots by specifying custom labels on the Backup CR with the velero backup create --labels flag (#1729, @prydonius)
* Restore restic volumes from PodVolumeBackups CRs (#1723, @carlisia)
* properly restore PVs backed up with restic and a reclaim policy of "Retain" (#1713, @skriss)
* Make `--secret-file` flag on `velero install` optional, add `--no-secret` flag for explicit confirmation (#1699, @nrb)
* Add low cpu/memory limits to the restic init container. This allows for restoration into namespaces with quotas defined. (#1677, @nrb)
* Adds configurable CPU/memory requests and limits to the restic DaemonSet generated by velero install. (#1710, @prydonius)
* remove any stale locks from restic repositories every 5m (#1708, @skriss)
* error if backup storage location's Bucket field also contains a prefix, and gracefully handle leading/trailing slashes on Bucket and Prefix fields. (#1694, @skriss)
* Adds configurable CPU/memory requests and limits to the Velero Deployment generated by velero install. (#1678, @prydonius)
* Store restic PodVolumeBackups in obj storage & use that as source of truth like regular backups. (#1577, @carlisia)
* Update Velero Deployment to use apps/v1 API group. `velero install` and `velero plugin add/remove` commands will now require Kubernetes 1.9+ (#1673, @nrb)
* Respect the --kubecontext and --kubeconfig arugments for `velero install`. (#1656, @nrb)
* add plugin for updating PV & PVC storage classes on restore based on a config map (#1621, @skriss)
* Add restic support for CSI volumes (#1615, @nrb)
* enhancement: allow users to specify additional Velero/Restic pod annotations on the command line with the pod-annotations flag. (#1626, @tlkamp)
* adds validation for pod volumes hostPath mount on restic server startup (#1616, @prydonius)
* enable support for ppc64le architecture (#1605, @prajyot)
* bug fix: only restore additional items returned from restore item actions if they match the restore's namespace/resource selectors (#1612, @skriss)
* add startTimestamp and completionTimestamp to PodVolumeBackup and PodVolumeRestore status fields (#1609, @prydonius)
* bug fix: respect namespace selector when determining which restore item actions to run (#1607, @skriss)
* ensure correct backup item actions run with namespace selector (#1601, @prydonius)
* allows excluding resources from backups with the `velero.io/exclude-from-backup=true` label (#1588, @prydonius)
* ensures backup item action modifications to an item's namespace/name are saved in the file path in the tarball (#1587, @prydonius)
* Hides `velero server` and `velero restic server` commands from the list of available commands as these are not intended for use by the velero CLI user. (#1561, @prydonius)
* remove dependency on glog, update to klog (#1559, @skriss)
* move issue-template-gen from docs/ to hack/ (#1558, @skriss)
* fix panic when processing DeleteBackupRequest objects without labels (#1556, @prydonius)
* support for multiple AWS profiles (#1548, @pranavgaikwad)
* Add CLI command to list (get) all Velero plugins (#1535, @carlisia)
* Added author as a tag on blog post. Should fix 404 error when trying to follow link as specified in issue #1522. (#1522, @coonsd)
* Allow individual backup storage locations to be read-only (#1517, @skriss)
* Stop returning an error when a restic volume is empty since it is a valid scenario. (#1480, @carlisia)
* add ability to use wildcard in includes/excludes (#1428, @guilhem)
Please note that as of this release we are no longer publishing new container images to `gcr.io/heptio-images`. The existing ones will remain there for the foreseeable future.
### Documentation
https://velero.io/docs/v1.2.0/
### Upgrading
https://velero.io/docs/v1.2.0/upgrade-to-1.2/
### Highlights
## Moving Cloud Provider Plugins Out of Tree
Velero has had built-in support for AWS, Microsoft Azure, and Google Cloud Platform (GCP) since day 1. When Velero moved to a plugin architecture for object store providers and volume snapshotters in version 0.6, the code for these three providers was converted to use the plugin interface provided by this new architecture, but the cloud provider code still remained inside the Velero codebase. This put the AWS, Azure, and GCP plugins in a different position compared with other providers’ plugins, since they automatically shipped with the Velero binary and could include documentation in-tree.
With version 1.2, we’ve extracted the AWS, Azure, and GCP plugins into their own repositories, one per provider. We now also publish one plugin image per provider. This change brings these providers to parity with other providers’ plugin implementations, reduces the size of the core Velero binary by not requiring each provider’s SDK to be included, and opens the door for the plugins to be maintained and released independently of core Velero.
## Restic Integration Improvements
We’ve continued to work on improving Velero’s restic integration. With this release, we’ve made the following enhancements:
- Restic backup and restore progress is now captured during execution and visible to the user through the `velero backup/restore describe --details` command. The details are updated every 10 seconds. This provides a new level of visibility into restic operations for users.
- Restic backups of persistent volume claims (PVCs) now remain incremental across the rescheduling of a pod. Previously, if the pod using a PVC was rescheduled, the next restic backup would require a full rescan of the volume’s contents. This improvement potentially makes such backups significantly faster.
- Read-write-many volumes are no longer backed up once for every pod using the volume, but instead just once per Velero backup. This improvement speeds up backups and prevents potential restore issues due to multiple copies of the backup being processed simultaneously.
## Clone PVs When Cloning a Namespace
Before version 1.2, you could clone a Kubernetes namespace by backing it up and then restoring it to a different namespace in the same cluster by using the `--namespace-mappings` flag with the `velero restore create` command. However, in this scenario, Velero was unable to clone persistent volumes used by the namespace, leading to errors for users.
In version 1.2, Velero automatically detects when you are trying to clone an existing namespace, and clones the persistent volumes used by the namespace as well. This doesn’t require the user to specify any additional flags for the `velero restore create` command. This change lets you fully achieve your goal of cloning namespaces using persistent storage within a cluster.
## Improved Server-Side Encryption Support
To help you secure your important backup data, we’ve added support for more forms of server-side encryption of backup data on both AWS and GCP. Specifically:
- On AWS, Velero now supports Amazon S3-managed encryption keys (SSE-S3), which uses AES256 encryption, by specifying `serverSideEncryption: AES256` in a backup storage location’s config.
- On GCP, Velero now supports using a specific Cloud KMS key for server-side encryption by specifying `kmsKeyName: <key name>` in a backup storage location’s config.
## CRD Structural Schema
In Kubernetes 1.16, custom resource definitions (CRDs) reached general availability. Structural schemas are required for CRDs created in the `apiextensions.k8s.io/v1` API group. Velero now defines a structural schema for each of its CRDs and automatically applies it the user runs the `velero install` command. The structural schemas enable the user to get quicker feedback when their backup, restore, or schedule request is invalid, so they can immediately remediate their request.
### All Changes
* Ensure object store plugin processes are cleaned up after restore and after BSL validation during server start up (#2041, @betta1)
* bug fix: don't try to restore pod volume backups that don't have a snapshot ID (#2031, @skriss)
* Restore Documentation: Updated Restore Documentation with Clarification implications of removing restore object. (#1957, @nainav)
* add `--allow-partially-failed` flag to `velero restore create` for use with `--from-schedule` to allow partially-failed backups to be restored (#1994, @skriss)
* Allow backup storage locations to specify backup sync period or toggle off sync (#1936, @betta1)
* Remove cloud provider code (#1985, @carlisia)
* Restore action for cluster/namespace role bindings (#1974, @alexander-demichev)
* Add `--no-default-backup-location` flag to `velero install` (#1931, @Frank51)
* If includeClusterResources is nil/auto, pull in necessary CRDs in backupResource (#1831, @sseago)
* Azure: add support for Azure China/German clouds (#1938, @andyzhangx)
* Add a new required `--plugins` flag for `velero install` command. `--plugins` takes a list of container images to add as initcontainers. (#1930, @nrb)
* restic: only backup read-write-many PVCs at most once, even if they're annotated for backup from multiple pods. (#1896, @skriss)
* Azure: add support for cross-subscription backups (#1895, @boxcee)
* adds `insecureSkipTLSVerify` server config for AWS storage and `--insecure-skip-tls-verify` flag on client for self-signed certs (#1793, @s12chung)
* Add check to update resource field during backupItem (#1904, @spiffcs)
* Add `LD_LIBRARY_PATH` (=/plugins) to the env variables of velero deployment. (#1893, @lintongj)
* backup sync controller: stop using `metadata/revision` file, do a full diff of bucket contents vs. cluster contents each sync interval (#1892, @skriss)
* bug fix: during restore, check item's original namespace, not the remapped one, for inclusion/exclusion (#1909, @skriss)
* adds structural schema to Velero CRDs created on Velero install, enabling validation of Velero API fields (#1898, @prydonius)
* GCP: add support for specifying a Cloud KMS key name to use for encrypting backups in a storage location. (#1879, @skriss)
* AWS: add support for SSE-S3 AES256 encryption via `serverSideEncryption` config field in BackupStorageLocation (#1869, @skriss)
* change default `restic prune` interval to 7 days, add `velero server/install` flags for specifying an alternate default value. (#1864, @skriss)
* velero install: if `--use-restic` and `--wait` are specified, wait up to a minute for restic daemonset to be ready (#1859, @skriss)
* report restore progress in PodVolumeRestores and expose progress in the velero restore describe --details command (#1854, @prydonius)
* Jekyll Site updates - modifies documentation to use a wider layout; adds better markdown table formatting (#1848, @ccbayer)
* fix excluding additional items with the velero.io/exclude-from-backup=true label (#1843, @prydonius)
* report backup progress in PodVolumeBackups and expose progress in the velero backup describe --details command. Also upgrades restic to v0.9.5 (#1821, @prydonius)
* Add `--features` argument to all velero commands to provide feature flags that can control enablement of pre-release features. (#1798, @nrb)
* when backing up PVCs with restic, specify `--parent` flag to prevent full volume rescans after pod reschedules (#1807, @skriss)
* remove 'restic check' calls from before/after 'restic prune' since they're redundant (#1794, @skriss)
* fix error formatting due interpreting % as printf formatted strings (#1781, @s12chung)
* when using `velero restore create --namespace-mappings ...` to create a second copy of a namespace in a cluster, create copies of the PVs used (#1779, @skriss)
* adds --from-schedule flag to the `velero create backup` command to create a Backup from an existing Schedule (#1734, @prydonius)
* Allow `plugins/` as a valid top-level directory within backup storage locations. This directory is a place for plugin authors to store arbitrary data as needed. It is recommended to create an additional subdirectory under `plugins/` specifically for your plugin, e.g. `plugins/my-plugin-data/`. (#2350, @skriss)
* bug fix: don't panic in `velero restic repo get` when last maintenance time is `nil` (#2315, @skriss)
#### Custom Resource Definition Backup and Restore Improvements
This release includes a number of related bug fixes and improvements to how Velero backs up and restores custom resource definitions (CRDs) and instances of those CRDs.
We found and fixed three issues around restoring CRDs that were originally created via the `v1beta1` CRD API. The first issue affected CRDs that had the `PreserveUnknownFields` field set to `true`. These CRDs could not be restored into 1.16+ Kubernetes clusters, because the `v1` CRD API does not allow this field to be set to `true`. We added code to the restore process to check for this scenario, to set the `PreserveUnknownFields` field to `false`, and to instead set `x-kubernetes-preserve-unknown-fields` to `true` in the OpenAPIv3 structural schema, per Kubernetes guidance. For more information on this, see the [Kubernetes documentation](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/#pruning-versus-preserving-unknown-fields). The second issue affected CRDs without structural schemas. These CRDs need to be backed up/restored through the `v1beta1` API, since all CRDs created through the `v1` API must have structural schemas. We added code to detect these CRDs and always back them up/restore them through the `v1beta1` API. Finally, related to the previous issue, we found that our restore code was unable to handle backups with multiple API versions for a given resource type, and we’ve remediated this as well.
We also improved the CRD restore process to enable users to properly restore CRDs and instances of those CRDs in a single restore operation. Previously, users found that they needed to run two separate restores: one to restore the CRD(s), and another to restore instances of the CRD(s). This was due to two deficiencies in the Velero code. First, Velero did not wait for a CRD to be fully accepted by the Kubernetes API server and ready for serving before moving on; and second, Velero did not refresh its cached list of available APIs in the target cluster after restoring CRDs, so it was not aware that it could restore instances of those CRDs.
We fixed both of these issues by (1) adding code to wait for CRDs to be “ready” after restore before moving on, and (2) refreshing the cached list of APIs after restoring CRDs, so any instances of newly-restored CRDs could subsequently be restored.
With all of these fixes and improvements in place, we hope that the CRD backup and restore experience is now seamless across all supported versions of Kubernetes.
#### Multi-Arch Docker Images
Thanks to community members [@Prajyot-Parab](https://github.com/Prajyot-Parab) and [@shaneutt](https://github.com/shaneutt), Velero now provides multi-arch container images by using Docker manifest lists. We are currently publishing images for `linux/amd64`, `linux/arm64`, `linux/arm`, and `linux/ppc64le` in [our Docker repository](https://hub.docker.com/r/velero/velero/tags?page=1&name=v1.3&ordering=last_updated).
Users don’t need to change anything other than updating their version tag - the v1.3 image is `velero/velero:v1.3.0`, and Docker will automatically pull the proper architecture for the host.
For more information on manifest lists, see [Docker’s documentation](https://docs.docker.com/registry/spec/manifest-v2-2/).
#### Bug Fixes, Usability Enhancements, and More
We fixed a large number of bugs and made some smaller usability improvements in this release. Here are a few highlights:
- Support private registries with custom ports for the restic restore helper image ([PR #1999](https://github.com/vmware-tanzu/velero/pull/1999), [@cognoz](https://github.com/cognoz))
- Use AWS profile from BackupStorageLocation when invoking restic ([PR #2096](https://github.com/vmware-tanzu/velero/pull/2096), [@dinesh](https://github.com/dinesh))
- Allow restores from schedules in other clusters ([PR #2218](https://github.com/vmware-tanzu/velero/pull/2218), [@cpanato](https://github.com/cpanato))
* Corrected the selfLink for Backup CR in site/docs/master/output-file-format.md (#2292, @RushinthJohn)
* Back up schema-less CustomResourceDefinitions as v1beta1, even if they are retrieved via the v1 endpoint. (#2264, @nrb)
* Bug fix: restic backup volume snapshot to the second location failed (#2244, @jenting)
* Added support of using PV name from volumesnapshotter('SetVolumeID') in case of PV renaming during the restore (#2216, @mynktl)
* Replaced deprecated helm repo url at all it appearance at docs. (#2209, @markrity)
* added support for arm and arm64 images (#2227, @shaneutt)
* when restoring from a schedule, validate by checking for backup(s) labeled with the schedule name rather than existence of the schedule itself, to allow for restoring from deleted schedules and schedules in other clusters (#2218, @cpanato)
* bug fix: back up server-preferred version of CRDs rather than always the `v1beta1` version (#2230, @skriss)
* Wait for CustomResourceDefinitions to be ready before restoring CustomResources. Also refresh the resource list from the Kubernetes API server after restoring CRDs in order to properly restore CRs. (#1937, @nrb)
* When restoring a v1 CRD with PreserveUnknownFields = True, make sure that the preservation behavior is maintained by copying the flag into the Open API V3 schema, but update the flag so as to allow the Kubernetes API server to accept the CRD without error. (#2197, @nrb)
* Add details of CSI volumesnapshotcontents associated with a backup to `velero backup describe` when the `EnableCSI` feature flag is given on the velero client. (#2448, @nrb)
* Allow users the option to retrieve all versions of a given resource (instead of just the preferred version) from the API server with the `EnableAPIGroupVersions` feature flag. (#2373, @brito-rafa)
* Changed backup tarball format to store all versions of a given resource, updated backup tarball format to 1.1.0. (#2373, @brito-rafa)
* allow feature flags to be passed from install CLI (#2503, @ashish-amarnath)
* sync backups' CSI API objects into the cluster as part of the backup sync controller (#2496, @ashish-amarnath)
* bug fix: in error location logging hook, if the item logged under the `error` key doesn't implement the `error` interface, don't return an error since this is a valid scenario (#2487, @skriss)
* bug fix: in CRD restore plugin, don't use runtime.DefaultUnstructuredConverter.FromUnstructured(...) to avoid conversion issues when float64 fields contain int values (#2484, @skriss)
* during backup deletion also delete CSI volumesnapshotcontents that were created as a part of the backup but the associated volumesnapshot object does not exist (#2480, @ashish-amarnath)
* If plugins don't support the `--features` flag, don't pass it to them. Also, update the standard plugin server to ignore unknown flags. (#2479, @skriss)
* At backup time, if a CustomResourceDefinition appears to have been created via the v1beta1 endpoint, retrieve it from the v1beta1 endpoint instead of simply changing the APIVersion. (#2478, @nrb)
* update container base images from ubuntu:bionic to ubuntu:focal (#2471, @skriss)
* bug fix: when a resource includes/excludes list contains unresolvable items, don't remove them from the list, so that the list doesn't inadvertently end up matching *all* resources. (#2462, @skriss)
* Azure: add support for getting storage account key for restic directly from an environment variable (#2455, @jaygridley)
* Support to skip VSL validation for the backup having SnapshotVolumes set to false or created with `--snapshot-volumes=false` (#2450, @mynktl)
* report backup progress (number of items backed up so far out of an estimated total number of items) during backup in the logs and as status fields on the Backup custom resource (#2440, @skriss)
* bug fix: populate namespace in logs for backup errors (#2438, @skriss)
* during backup deletion also delete CSI volumesnapshots that were created as a part of the backup (#2411, @ashish-amarnath)
* bump Kubernetes module dependencies to v0.17.4 to get fix for https://github.com/kubernetes/kubernetes/issues/86149 (#2407, @skriss)
* bug fix: save PodVolumeBackup manifests to object storage even if the volume was empty, so that on restore, the PV is dynamically reprovisioned if applicable (#2390, @skriss)
* Adding new restoreItemAction for PVC to update the selected-node annotation (#2377, @mynktl)
* Added a --cacert flag to the install command to provide the CA bundle to use when verifying TLS connections to object storage (#2368, @mansam)
* Added a `--cacert` flag to the velero client describe, download, and logs commands to allow passing a path to a certificate to use when verifying TLS connections to object storage. Also added a corresponding client config option called `cacert` which takes a path to a certificate bundle to use as a default when `--cacert` is not specified. (#2364, @mansam)
* support setting a custom CA certificate on a BSL to use when verifying TLS connections (#2353, @mansam)
* adding annotations on backup CRD for k8s major, minor and git versions (#2346, @brito-rafa)
* When the EnableCSI feature flag is provided, upload CSI VolumeSnapshots and VolumeSnapshotContents to object storage as gzipped JSON. (#2323, @nrb)
* add CSI snapshot API types into default restore priorities (#2318, @ashish-amarnath)
* refactoring: wait for all informer caches to sync before running controllers (#2299, @skriss)
* refactor restore code to lazily resolve resources via discovery and eliminate second restore loop for instances of restored CRDs (#2248, @skriss)
* upgrade to go 1.14 and migrate from `dep` to go modules (#2214, @skriss)
* clarify the wording for restore describe for namespaces included
bump Kubernetes module dependencies to v0.18.4 to fix https://github.com/vmware-tanzu/velero/issues/2540 by adding code compatibility with kubernetes v1.18
Add a BSL controller to handle validation + update BSL status phase (validation removed from the server and no longer blocks when there's any invalid BSL)
description:Backup is a Velero resource that respresents 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
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
group:velero.io
names:
kind:BackupStorageLocation
listKind:BackupStorageLocationList
plural:backupstoragelocations
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
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.
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.
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.
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
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.
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.
description:Restore is a Velero resource that represents the application of
resources from a Velero backup to a target Kubernetes cluster.
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:RestoreSpec defines the specification for a Velero restore.
properties:
backupName:
description:BackupName is the unique name of the Velero backup to restore
from.
type:string
excludedNamespaces:
description:ExcludedNamespaces contains a list of namespaces that are
not included in the restore.
items:
type:string
nullable:true
type:array
excludedResources:
description:ExcludedResources is a slice of resource names that are
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
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.
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 lifecyle phase of a
# Design proposal template `<replace with your proposal's title>`
_Note_: The preferred style for design documents is one sentence per line.
*Do not wrap lines*.
This aids in review of the document as changes to a line are not obscured by the reflowing those changes caused and has a side effect of avoiding debate about one or two space after a period.
_Note_: The name of the file should follow the name pattern `<short meaningful words joined by '-'>_design.md`, e.g:
`listener-design.md`.
## 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.
## Background
One to two paragraphs of exposition to set the context for this proposal.
## Goals
- A short list of things which will be accomplished by implementing this proposal.
- Two things is ok.
- Three is pushing it.
- More than three goals suggests that the proposal's scope is too large.
## Non Goals
- A short list of items which are:
- a. out of scope
- b. follow on items which are deliberately excluded from this proposal.
## High-Level Design
One to two paragraphs that describe the high level changes that will be made to implement this proposal.
## Detailed Design
A detailed design describing how the changes to the product should be made.
The names of types, fields, interfaces, and methods should be agreed on here, not debated in code review.
The same applies to changes in CRDs, YAML examples, and so on.
Ideally the changes should be made in sequence so that the work required to implement this design can be done incrementally, possibly in parallel.
## Alternatives Considered
If there are alternative high level or detailed designs that were not pursued they should be called out here with a brief explanation of why they were not pursued.
## Security Considerations
If this proposal has an impact to the security of the product, its users, or data stored or transmitted via the product, they must be addressed here.
## Compatibility
A discussion of any compatibility issues that need to be considered
## Implementation
A description of the implementation, timelines, and any resources that have agreed to contribute.
## Open Issues
A discussion of issues relating to this proposal for which the author does not know the solution. This section may be omitted if there are none.
# Expose list of backed up resources in backup details
Status: Accepted
To increase the visibility of what a backup might contain, this document proposes storing metadata about backed up resources in object storage and adding a new section to the detailed backup description output to list them.
## Goals
- Include a list of backed up resources as metadata in the bucket
- Enable users to get a view of what resources are included in a backup using the Velero CLI
## Non Goals
- Expose the full manifests of the backed up resources
## Background
As reported in [#396](https://github.com/heptio/velero/issues/396), the information reported in a `velero backup describe <name> --details` command is fairly limited, and does not easily describe what resources a backup contains.
In order to see what a backup might contain, a user would have to download the backup tarball and extract it.
This makes it difficult to keep track of different backups in a cluster.
## High-Level Design
After performing a backup, a new file will be created that contains the list of the resources that have been included in the backup.
This file will be persisted in object storage alongside the backup contents and existing metadata.
A section will be added to the output of `velero backup describe <name> --details` command to view this metadata.
## Detailed Design
### Metadata file
This metadata will be in JSON (or YAML) format so that it can be easily inspected from the bucket outside of Velero tooling, and will contain the API resource and group, namespaces and names of the resources:
```
apps/v1/Deployment:
- default/database
- default/wordpress
v1/Service:
- default/database
- default/wordpress
v1/Secret:
- default/database-root-password
- default/database-user-password
v1/ConfigMap:
- default/database
v1/PersistentVolume:
- my-pv
```
The filename for this metadata will be `<backup name>-resource-list.json.gz`.
The top-level key is the string form of the `schema.GroupResource` type that we currently keep track of in the backup controller code path.
### Changes in Backup controller
The Backupper currently initialises a map to track the `backedUpItems` (https://github.com/heptio/velero/blob/1594bdc8d0132f548e18ffcc1db8c4cd2b042726/pkg/backup/backup.go#L269), this is passed down through GroupBackupper, ResourceBackupper and ItemBackupper where ItemBackupper records each backed up item.
This property will be moved to the [Backup request struct](https://github.com/heptio/velero/blob/16910a6215cbd8f0bde385dba9879629ebcbcc28/pkg/backup/request.go#L11), allowing the BackupController to access it after a successful backup.
`backedUpItems` currently uses the `schema.GroupResource` as a key for the resource.
In order to record the API group, version and kind for the resource, this key will be constructed from the object's `schema.GroupVersionKind` in the format `{group}/{version}/{kind}` (e.g. `apps/v1/Deployment`).
The `backedUpItems` map is kept as a flat structure internally for quick lookup.
When the backup is ready to upload, `backedUpItems` will be converted to a nested structure representing the metadata file above, grouped by `schema.GroupVersionKind`.
After converting to the right format, it can be passed to the `persistBackup` function to persist the file in object storage.
### Changes to DownloadRequest CRD and processing
A new `DownloadTargetKind` "BackupResourceList" will be added to the DownloadRequest CR.
The `GetDownloadURL` function in the `persistence` package will be updated to handle this new DownloadTargetKind to enable the Velero client to fetch the metadata from the bucket.
### Changes to `velero backup describe <name> --details`
This command will need to be updated to fetch the metadata from the bucket using the `Stream` method used in other commands.
The file will be read in memory and displayed in the output of the command.
Depending on the format the metadata is stored in, it may need processing to print in a more human-readable format.
If we choose to store the metadata in YAML, it can likely be directly printed out.
If the metadata file does not exist, this is an older backup and we cannot display the list of resources that were backed up.
## Open Questions
## Alternatives Considered
### Fetch backup contents archive and walkthrough to list contents
Instead of recording new metadata about what resources have been backed up, we could simply download the backup contents archive and walkthrough it to list the contents everytime `velero backup describe <name> --details` is run.
The advantage of this approach is that we don't need to change any backup procedures as we already have this content, and we will also be able to list resources for older backups.
Additionally, if we wanted to expose more information about the backed up resources, we can do so without having to update what we store in the metadata.
The disadvantages are:
- downloading the whole backup archive will be larger than just downloading a smaller file with metadata
- reduces the metadata available in the bucket that users might want to inspect outside of Velero tooling (though this is not an explicit requirement)
This document proposes a solution that allows user to specify a backup order for resources of specific resource type.
## Background
During backup process, user may need to back up resources of specific type in some specific order to ensure the resources were backup properly because these resources are related and ordering might be required to preserve the consistency for the apps to recover itself <20>from the backup image
(Ex: primary-secondary database pods in a cluster).
## Goals
- Enable user to specify an order of back up resources belong to specific resource type
## Alternatives Considered
- Use a plugin to backup an resources and all the sub resources. For example use a plugin for StatefulSet and backup pods belong to the StatefulSet in specific order. This plugin solution is not generic and requires plugin for each resource type.
## High-Level Design
User will specify a map of resource type to list resource names (separate by semicolons). Each name will be in the format "namespaceName/resourceName" to enable ordering accross namespaces. Based on this map, the resources of each resource type will be sorted by the order specified in the list of resources. If a resource instance belong to that specific type but its name is not in the order list, then it will be put behind other resources that are in the list.
### Changes to BackupSpec
Add new field to BackupSpec
type BackupSpec struct {
...
// OrderedResources contains a list of key-value pairs that represent the order
// of backup of resources that belong to specific resource type
// +optional
// +nullable
OrderedResources map[string]string
}
### Changes to itemCollector
Function getResourceItems collects all items belong to a specific resource type. This function will be enhanced to check with the map to see whether the OrderedResources has specified the order for this resource type. If such order exists, then sort the items by such order being process before return.
### Changes to velero CLI
Add new flag "--ordered-resources" to Velero backup create command which takes a string of key-values pairs which represents the map between resource type and the order of the items of such resource type. Key-value pairs are separated by semicolon, items in the value are separated by commas.
- In the CLI, the design proposes to use commas to separate items of a resource type and semicolon to separate key-value pairs. This follows the convention of using commas to separate items in a list (For example: --include-namespaces ns1,ns2). However, the syntax for map in labels and annotations use commas to seperate key-value pairs. So it introduces some inconsistency.
- For pods that managed by Deployment or DaemonSet, this design may not work because the pods' name is randomly generated and if pods are restarted, they would have different names so the Backup operation may not consider the restarted pods in the sorting algorithm. This problem will be addressed when we enhance the design to use regular expression to specify the OrderResources instead of exact match.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.