* Restore API group version by priority Signed-off-by: F. Gold <fgold@vmware.com> * Add changelog Signed-off-by: F. Gold <fgold@vmware.com> * Correct spelling Signed-off-by: F. Gold <fgold@vmware.com> * Refactor userResourceGroupVersionPriorities(...) to accept config map, adjust unit test Signed-off-by: F. Gold <fgold@vmware.com> * Move some unit tests into e2e Signed-off-by: F. Gold <fgold@vmware.com> * Add three e2e tests using Testify Suites Summary of changes Makefile - add testify e2e test target go.sum - changed with go mod tidy pkg/install/install.go - increased polling timeout test/e2e/restore_priority_group_test.go - deleted test/e2e/restore_test.go - deleted test/e2e/velero_utils.go - made restic optional in velero install test/e2e_testify/Makefile - makefile for testify e2e tests test/e2e_testify/README.md - example command for running tests test/e2e_testify/common_test.go - helper functions test/e2e_testify/e2e_suite_test.go - prepare for tests and run test/e2e_testify/restore_priority_apigv_test.go - test cases Signed-off-by: F. Gold <fgold@vmware.com> * Make changes per @nrb code review Signed-off-by: F. Gold <fgold@vmware.com> * Wait for pods in e2e tests Signed-off-by: F. Gold <fgold@vmware.com> * Remove testify suites e2e scaffolding moved to PR #3354 Signed-off-by: F. Gold <fgold@vmware.com> * Make changes per @brito-rafa and Velero maintainers code reviews - Made changes suggested by @brito-rafa in GitHub. - We had a code review meeting with @carlisia, @dsu-igeek, @zubron, and @nrb - and changes were made based on their suggetions: - pull in logic from 'meetsAPIGVResotreReqs()' to restore.go. - add TODO to remove APIGroupVersionFeatureFlag check - have feature flag and backup version format checks in separate `if` statements. - rename variables to be sourceGVs, targetGVs, and userGVs. Signed-off-by: F. Gold <fgold@vmware.com> * Convert Testify Suites e2e tests to existing Ginkgo framework Signed-off-by: F. Gold <fgold@vmware.com> * Made changes per @zubron PR review Signed-off-by: F. Gold <fgold@vmware.com> * Run go mod tidy after resolving go.sum merge conflict Signed-off-by: F. Gold <fgold@vmware.com> * Add feature documentation to velero.io site Signed-off-by: F. Gold <fgold@vmware.com> * Add config map e2e test; rename e2e test file and name Signed-off-by: F. Gold <fgold@vmware.com> * Update go.{mod,sum} files Signed-off-by: F. Gold <fgold@vmware.com> * Move CRDs and CRs to testdata folder Signed-off-by: F. Gold <fgold@vmware.com> * Fix typos in cert-manager to pass codespell CICD check Signed-off-by: F. Gold <fgold@vmware.com> * Make changes per @nrb code review round 2 - make checkAndReadDir function private - add info level messages when priorties 1-3 API group versions can not be used Signed-off-by: F. Gold <fgold@vmware.com> * Make user config map rules less strict Signed-off-by: F. Gold <fgold@vmware.com> * Update e2e test image version in example Signed-off-by: F. Gold <fgold@vmware.com> * Update case A music-system controller code Signed-off-by: F. Gold <fgold@vmware.com> * Documentation updates Signed-off-by: F. Gold <fgold@vmware.com> * Update migration case documentation Signed-off-by: F. Gold <fgold@vmware.com> |
||
---|---|---|
.. | ||
testdata/enable_api_group_versions | ||
Makefile | ||
README.md | ||
backup_test.go | ||
common.go | ||
e2e_suite_test.go | ||
enable_api_group_versions_test.go | ||
kibishii_tests.go | ||
kind_test.go | ||
velero_utils.go |
README.md
End-to-end tests
Document for running Velero end-to-end test suite.
The E2E tests are validating end-to-end behavior of Velero including install, backup and restore operations. These tests take longer to complete and is not expected to be part of day-to-day developer workflow. It is for this reason that they are disabled when running unit tests. This is accomplished by running unit tests in short
mode using the -short
flag to go test
.
If you previously ran unit tests using the go test ./...
command or any of its variations, then you will now run the same command with the -short
flag to go test
to accomplish the same behavior. Alternatively, you can use the make test
command to run unit tests.
Prerequisites
Running the E2E tests expects:
- A running kubernetes cluster:
- With DNS and CNI installed.
- Compatible with Velero- running Kubernetes v1.10 or later.
- With necessary storage drivers/provisioners installed.
kubectl
installed locally.
Limitations
These are the current set of limitations with the E2E tests.
- E2E tests only accepts credentials only for a single provider and for that reason, only tests for a single provider can be run at a time.
- Each E2E test suite installs an instance of Velero to run tests and uninstalls it after test completion. It is possible that a test suite may be installing Velero while another may be uninstalling Velero. This race condition can lead to tests being flaky and cause false negatives. The options for resolving this are:
- Make each test suite setup wait for Velero to be uninstalled before attempting to install as part of its setup.
- Make each test suite install Velero in a different namespace.
Configuration for E2E tests
Below is a list of the configuration used by E2E tests. These configuration parameters are expected as values to the following command line flags:
-credentials-file
: File containing credentials for backup and volume provider. Required.-bucket
: Name of the object storage bucket where backups from e2e tests should be stored. Required.-plugin-provider
: Provider of object store and volume snapshotter plugins. Required.-velerocli
: Path to the velero application to use. Optional, by default usesvelero
in the$PATH
-velero-image
: Image for the velero server to be tested. Optional, by default usesvelero/velero:main
-bsl-config
: Configuration to use for the backup storage location. Format is key1=value1,key2=value2. Optional.-prefix
: Prefix in thebucket
, under which all Velero data should be stored within the bucket. Optional.-vsl-config
: Configuration to use for the volume snapshot location. Format is key1=value1,key2=value2. Optional.
These configurations or parameters are used to generate install options for Velero for each test suite.
Running tests locally
Running using make
E2E tests can be run from the Velero repository root by running make test-e2e
. While running E2E tests using make
the E2E test configuration values are passed using make
variables.
Below is a mapping between make
variables to E2E configuration flags.
CREDS_FILE
:-credentials-file
. Required.BSL_BUCKET
:-bucket
. Required.PLUGIN_PROVIDER
:-plugin-provider
. Required.VELERO_CLI
: the-velerocli
. Optional.VELERO_IMAGE
: the-velero-image
. Optional.BSL_PREFIX
:-prefix
. Optional.BSL_CONFIG
:-bsl-config
. Optional.VSL_CONFIG
:-vsl-config
. Optional.
For example, E2E tests can be run from Velero repository roots using the below command:
- Run Velero tests using AWS as the storage provider:
BSL_PREFIX=<PREFIX_UNDER_BUCKET> BSL_BUCKET=<BUCKET_FOR_E2E_TEST_BACKUP> CREDS_FILE=/path/to/aws-creds PLUGIN_PROVIDER=aws make test-e2e
- Run Velero tests using Microsoft Azure as the storage provider:
Please refer toBSL_CONFIG="resourceGroup=$AZURE_BACKUP_RESOURCE_GROUP,storageAccount=$AZURE_STORAGE_ACCOUNT_ID,subscriptionId=$AZURE_BACKUP_SUBSCRIPTION_ID" BSL_BUCKET=velero CREDS_FILE=~/bin/velero-dev/aks-creds PLUGIN_PROVIDER=azure make test-e2e
velero-plugin-for-microsoft-azure
documentation for instruction to set up permissions for Velero and to set up azure storage account and blob container - Run Ginko-focused Restore Multi-API Groups tests using an image built for PR #3133 and Minio as the backup storage location:
BSL_CONFIG="region=minio,s3ForcePathStyle=\"true\",s3Url=http://192.168.1.124:9000" BSL_PREFIX=veldat BSL_BUCKET=velero CREDS_FILE=~/go/src/github.com/vmware-tanzu/velero/frankie-secrets/credentials-minio PLUGIN_PROVIDER=aws VELERO_IMAGE=projects.registry.vmware.com/tanzu_migrator/velero-pr3133:0.0.5 GINKGO_FOCUS="API group versions" make test-e2e
Filtering tests
Velero E2E tests uses Ginkgo testing framework which allows a subset of the tests to be run using the -focus
and -skip
flags to ginkgo.
The -focus
flag is passed to ginkgo using the GINKGO_FOCUS
make variable. This can be used to focus on specific tests.