e2e

package
v1.6.0-rc.1 Latest Latest
Warning

This package is not in the latest version of its module.

Go to latest
Published: Mar 29, 2021 License: Apache-2.0 Imports: 28 Imported by: 0

README

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:

  1. A running kubernetes cluster:
    1. With DNS and CNI installed.
    2. Compatible with Velero- running Kubernetes v1.10 or later.
    3. With necessary storage drivers/provisioners installed.
  2. kubectl installed locally.

Limitations

These are the current set of limitations with the E2E tests.

  1. 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.
  2. 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:
    1. Make each test suite setup wait for Velero to be uninstalled before attempting to install as part of its setup.
    2. 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:

  1. -credentials-file: File containing credentials for backup and volume provider. Required.
  2. -bucket: Name of the object storage bucket where backups from e2e tests should be stored. Required.
  3. -cloud-provider: The cloud the tests will be run in. Appropriate plug-ins will be installed except for kind which requires the object-store-provider to be specified.
  4. -object-store-provider: Object store provider to use. Required when kind is the cloud provider.
  5. -velerocli: Path to the velero application to use. Optional, by default uses velero in the $PATH
  6. -velero-image: Image for the velero server to be tested. Optional, by default uses velero/velero:main
  7. -bsl-config: Configuration to use for the backup storage location. Format is key1=value1,key2=value2. Optional.
  8. -prefix: Prefix in the bucket, under which all Velero data should be stored within the bucket. Optional.
  9. -vsl-config: Configuration to use for the volume snapshot location. Format is key1=value1,key2=value2. Optional.
  10. -velero-namespace: Namespace to install velero in. Optional, defaults to "velero".
  11. -install-velero: Specifies whether to install/uninstall velero for the tests. Optional, defaults to "true".
  12. -additional-bsl-object-store-provider: Provider of object store plugin for additional backup storage location. Required if testing multiple credentials support.
  13. -additional-bsl-bucket: Name of the object storage bucket for additional backup storage location. Required if testing multiple credentials support.
  14. -additional-bsl-prefix: Prefix in the additional-bsl-bucket, under which all Velero data should be stored. Optional.
  15. -additional-bsl-config: Configuration to use for the additional backup storage location. Format is key1=value1,key2=value2. Optional.
  16. -additional-bsl-credentials-file: File containing credentials for the additional backup storage location. Required if testing multiple credentials support.

These configurations or parameters are used to generate install options for Velero for each test suite.

Tests can be run with the Kubernetes cluster hosted in various cloud providers or in a kind cluster with storage in a specified object store type. Currently supported cloud provider types are aws, azure, vsphere and kind.

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.

  1. CREDS_FILE: -credentials-file. Required.
  2. BSL_BUCKET: -bucket. Required.
  3. CLOUD_PROVIDER: -cloud-provider. Required
  4. OBJECT_STORE_PROVIDER: -object-store-provider. Required when kind is the cloud provider.
  5. VELERO_CLI: the -velerocli. Optional.
  6. VELERO_IMAGE: the -velero-image. Optional.
  7. BSL_PREFIX: -prefix. Optional.
  8. BSL_CONFIG: -bsl-config. Optional.
  9. VSL_CONFIG: -vsl-config. Optional.
  10. ADDITIONAL_OBJECT_STORE_PROVIDER: -additional-bsl-object-store-provider. Optional.
  11. ADDITIONAL_CREDS_FILE: -additional-bsl-bucket. Optional.
  12. ADDITIONAL_BSL_BUCKET: -additional-bsl-prefix. Optional.
  13. ADDITIONAL_BSL_PREFIX: -additional-bsl-config. Optional.
  14. ADDITIONAL_BSL_CONFIG: -additional-bsl-credentials-file. Optional.

For example, E2E tests can be run from Velero repository roots using the commands below:

  1. Run Velero tests in a kind cluster with AWS (or Minio) as the storage provider:
    BSL_PREFIX=<PREFIX_UNDER_BUCKET> BSL_BUCKET=<BUCKET_FOR_E2E_TEST_BACKUP> CREDS_FILE=/path/to/aws-creds CLOUD_PROVIDER=kind OBJECT_STORE_PROVIDER=aws make test-e2e
    
  2. Run Velero tests in an AWS cluster:
    BSL_PREFIX=<PREFIX_UNDER_BUCKET> BSL_BUCKET=<BUCKET_FOR_E2E_TEST_BACKUP> CREDS_FILE=/path/to/aws-creds CLOUD_PROVIDER=aws make test-e2e
    
  3. Run Velero tests in a Microsoft Azure cluster:
    BSL_CONFIG="resourceGroup=$AZURE_BACKUP_RESOURCE_GROUP,storageAccount=$AZURE_STORAGE_ACCOUNT_ID,subscriptionId=$AZURE_BACKUP_SUBSCRIPTION_ID" BSL_BUCKET=<BUCKET_FOR_E2E_TEST_BACKUP> CREDS_FILE=/path/to/azure-creds CLOUD_PROVIDER=azure make test-e2e
    
    Please refer to velero-plugin-for-microsoft-azure documentation for instruction to set up permissions for Velero and to set up azure storage account and blob container
  4. 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
    
  5. Run Velero tests in a kind cluster with AWS (or Minio) as the storage provider and use Microsoft Azure as the storage provider for an additional Backup Storage Location:
    make test-e2e \
      CLOUD_PROVIDER=kind OBJECT_STORE_PROVIDER=aws BSL_BUCKET=<BUCKET_FOR_E2E_TEST_BACKUP> BSL_PREFIX=<PREFIX_UNDER_BUCKET> CREDS_FILE=/path/to/aws-creds \
      ADDITIONAL_OBJECT_STORE_PROVIDER=azure ADDITIONAL_BSL_BUCKET=<BUCKET_FOR_AZURE_BSL> ADDITIONAL_BSL_PREFIX=<PREFIX_UNDER_BUCKET> ADDITIONAL_BSL_CONFIG=<CONFIG_FOR_AZURE_BUCKET> ADDITIONAL_CREDS_FILE=/path/to/azure-creds
    
    Please refer to velero-plugin-for-microsoft-azure documentation for instruction to set up permissions for Velero and to set up azure storage account and blob container

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.

Documentation

Index

Constants

This section is empty.

Variables

This section is empty.

Functions

func CheckBackupPhase

func CheckBackupPhase(ctx context.Context, veleroCLI string, veleroNamespace string, backupName string,
	expectedPhase velerov1api.BackupPhase) error

CheckBackupPhase uses veleroCLI to inspect the phase of a Velero backup.

func CheckRestorePhase

func CheckRestorePhase(ctx context.Context, veleroCLI string, veleroNamespace string, restoreName string,
	expectedPhase velerov1api.RestorePhase) error

CheckRestorePhase uses veleroCLI to inspect the phase of a Velero restore.

func CreateNamespace

func CreateNamespace(ctx context.Context, client *kubernetes.Clientset, namespace string) error

CreateNamespace creates a kubernetes namespace

func CreateSecretFromFiles

func CreateSecretFromFiles(ctx context.Context, client *kubernetes.Clientset, namespace string, name string, files map[string]string) error

func EnsureClusterExists

func EnsureClusterExists(ctx context.Context) error

EnsureClusterExists returns whether or not a kubernetes cluster exists for tests to be run on.

func GetProviderVeleroInstallOptions

func GetProviderVeleroInstallOptions(
	pluginProvider,
	credentialsFile,
	objectStoreBucket,
	objectStorePrefix string,
	bslConfig,
	vslConfig string,
	plugins []string,
	features string,
) (*cliinstall.InstallOptions, error)

GetProviderVeleroInstallOptions returns Velero InstallOptions for the provider.

func InstallVeleroServer

func InstallVeleroServer(io *cliinstall.InstallOptions) error

InstallVeleroServer installs velero in the cluster.

func RunKibishiiTests

func RunKibishiiTests(client *kubernetes.Clientset, providerName, veleroCLI, veleroNamespace, backupName, restoreName, backupLocation string,
	useVolumeSnapshots bool) error

RunKibishiiTests runs kibishii tests on the provider.

func VeleroAddPluginsForProvider

func VeleroAddPluginsForProvider(ctx context.Context, veleroCLI string, veleroNamespace string, provider string) error

VeleroAddPluginsForProvider determines which plugins need to be installed for a provider and installs them in the current Velero installation, skipping over those that are already installed.

func VeleroBackupLogs

func VeleroBackupLogs(ctx context.Context, veleroCLI string, veleroNamespace string, backupName string) error

func VeleroBackupNamespace

func VeleroBackupNamespace(ctx context.Context, veleroCLI string, veleroNamespace string, backupName string, namespace string, backupLocation string,
	useVolumeSnapshots bool) error

VeleroBackupNamespace uses the veleroCLI to backup a namespace.

func VeleroCreateBackupLocation

func VeleroCreateBackupLocation(ctx context.Context,
	veleroCLI string,
	veleroNamespace string,
	name string,
	objectStoreProvider string,
	bucket string,
	prefix string,
	config string,
	secretName string,
	secretKey string,
) error

func VeleroInstall

func VeleroInstall(ctx context.Context, veleroImage string, veleroNamespace string, cloudProvider string, objectStoreProvider string, useVolumeSnapshots bool,
	cloudCredentialsFile string, bslBucket string, bslPrefix string, bslConfig string, vslConfig string,
	features string) error

func VeleroRestore

func VeleroRestore(ctx context.Context, veleroCLI string, veleroNamespace string, restoreName string, backupName string) error

VeleroRestore uses the veleroCLI to restore from a Velero backup.

func VeleroRestoreLogs

func VeleroRestoreLogs(ctx context.Context, veleroCLI string, veleroNamespace string, restoreName string) error

func VeleroUninstall

func VeleroUninstall(ctx context.Context, client *kubernetes.Clientset, extensionsClient *apiextensionsclient.Clientset, veleroNamespace string) error

func WaitForNamespaceDeletion

func WaitForNamespaceDeletion(interval, timeout time.Duration, client *kubernetes.Clientset, ns string) error

WaitForNamespaceDeletion Waits for namespace to be deleted.

func WaitForPods

func WaitForPods(ctx context.Context, client *kubernetes.Clientset, namespace string, pods []string) error

Waits until all of the pods have gone to PodRunning state

Types

This section is empty.

Jump to

Keyboard shortcuts

? : This menu
/ : Search site
f or F : Jump to
y or Y : Canonical URL