One previously undocumented expectation is that
GetDynamicProvisionStorageClass can be called more than once per test
and then each time returns a new, unique storage class. The in-memory
implementation in driveroperations.go:GetStorageClass ensured that,
but loading from a .yaml file didn't. This caused the multivolume tests
to fail when applied to an already installed GCE driver with the
-storage.testdriver parameter.
When using an already installed driver, the snapshot name is the
original driver name. Renaming was incorrectly copied from the in-tree
CSI hostpath driver.
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.
Patrick Ohly