The assumption so far was that all drivers support read/write
volumes. That might not necessarily be true, so we have to let the
test driver specify it and then test accordingly.
Another aspect that is worth testing is whether the driver correctly
creates a new volume for each pod even if the volume attributes are
the same. However, drivers are not required to do that, so again we
have to let the test driver specify that.
After deleting a pod, we need to be sure that it really is gone,
otherwise there is a race condition: if we remove the CSI driver that
is responsible for the volume used by the pod before the pod is
actually deleted, deleting the pod will fail.
Once we have deleted the pod and the volume, we want to be sure that
NodeUnpublishVolume was called for it. The main motivation was to
check this for inline ephemeral volumes, but the same additional check
also makes sense for other volumes.
We need the 1.2.0 driver for that because that has support for
detecting the volume mode dynamically, and we need to deploy a
CSIDriver object which enables pod info (for the dynamic detection)
and both modes (to satisfy the new mode sanity check).
This ensures that the files are in sync with:
hostpath: v1.2.0-rc3
external-attacher: v2.0.1
external-provisioner: v1.3.0
external-resizer: v0.2.0
external-snapshotter: v1.2.0
driver-registrar/rbac.yaml is obsolete because only
node-driver-registrar is in use now and does not need RBAC rules.
mock/e2e-test-rbac.yaml was not used anywhere.
The README.md files were updated to indicate that these really are
files copied from elsewhere. To avoid the need to constantly edit
these files on each update, <version> is used as placeholder in the URL.
Moving pod related functions from e2e/framework/pv_util.go to
e2e/framework/pod in order to allow refactoring of pv_util.go into its
own package.
Signed-off-by: alejandrox1 <alarcj137@gmail.com>
PassiveClock has the subset of Clock functionality that only involves
reading the clock. Identifying this subset makes it possible to write
packages that are more clearly easy to test.
When a package is coded against Clock rather than PassiveClock this
adds two problems for the unit test functions. One is that Clock
provides no way for the test function to know when the next activity
is scheduled for. That could be added to FakeClock relatively easily.
The second problem is that when a package uses channels to schedule
future activity, once the Clock has advanced to such a future time the
Clock (and hence the test function) does not get informed when that
activity has completed.
