Files
kubernetes/test/e2e/storage/external/README.md
Patrick Ohly 6644db9914 e2e/storage: testing of external storage drivers
It is useful to apply the storage testsuite also to "external" (=
out-of-tree) storage drivers. One way of doing that is setting up a
custom E2E test suite, but that's still quite a bit of work.

An easier alternative is to parameterize the Kubernetes e2e.test
binary at runtime so that it instantiates the testsuite for one or
more drivers. Some parameters have to be provided before starting the
test because they define configuration and capabilities of the driver
and its storage backend that cannot be discovered at runtime. This is
done by populating the DriverDefinition with the content of the file
that the new -storage.testdriver parameters points to.

The universal .yaml and .json decoder from Kubernetes is used. It's
flexible, but has some downsides:
- currently ignores unknown fields (see https://github.com/kubernetes/kubernetes/pull/71589)
- poor error messages when fields have the wrong type

Storage drivers have to be installed in the test cluster before
starting e2e.test. Only tests involving dynamically provisioned
volumes are currently supported.
2019-03-06 22:06:31 +01:00

50 lines
1.8 KiB
Markdown

When a test suite like test/e2e/e2e.test from Kubernetes includes this
package, the -storage.testdriver parameter can be used one or more
times to enabling testing of a certain pre-installed storage driver.
The parameter takes as argument the name of a .yaml or .json file. The
filename can be absolute or relative to --repo-root. The content of
the file is used to populate a struct that defines how to test the
driver. For a full definition of the struct see the external.go file.
Here is an example for the CSI hostpath driver:
ShortName: mytest
StorageClass:
FromName: true
SnapshotClass:
FromName: true
DriverInfo:
Name: csi-hostpath
Capabilities:
persistence: true
dataSource: true
multipods: true
Currently there is no checking for unknown fields, i.e. only file
entries that match with struct entries are used and other entries are
silently ignored, so beware of typos.
For each driver, the storage tests from `test/e2e/storage/testsuites`
are added for that driver with `External Storage [Driver: <Name>]` as
prefix.
To run just those tests for the example above, put that content into
`/tmp/hostpath-testdriver.yaml` and invoke:
ginkgo -p -focus='External.Storage.*csi-hostpath' \
-skip='\[Feature:|\[Disruptive\]' \
./test/e2e \
-- \
-storage.testdriver=/tmp/hostpath-testdriver.yaml
This disables tests which depend on optional features. Those tests
must be run by selecting them explicitly in an environment that
supports them, for example snapshotting:
ginkgo -p -focus='External.Storage.*csi-hostpath.*\[Feature:VolumeSnapshotDataSource\]' \
-skip='\[Disruptive\]' \
./test/e2e \
-- \
-storage.testdriver=/tmp/hostpath-testdriver.yaml