Also remove FS VolMode disruptive tests because they are already covered
through the subpath disruptive test cases.
Change-Id: Ice4b30b0d8fdcb1f7fd61e54d27f53557de9f13a
Every caller of ReadOrDie() specified ginkgo.Fail as fail argument,
and that was intentional to avoid depending on Ginkgo.
However that just spreaded the dependency on Ginkgo to caller sides.
Especially that was unnecessary e2e test framework "ingress" depended
on Ginkgo only for the above reason.
Now we are cleaning up the dependencies on e2e tests, so let's just
remove such dependencies.
Using a "normal" CSI driver for an inline ephemeral volume may have
unexpected and potentially harmful effects when the driver gets a
NodePublishVolume call that it isn't expecting. To prevent that mistake,
driver deployments for a driver that supports such volumes must:
- deploy a CSIDriver object for the driver
- set CSIDriver.Spec.VolumeLifecycleModes such that it contains "ephemeral"
The default for that field is "persistent", so existing deployments
continue to work and are automatically protected against incorrect
usage.
For the E2E tests we need a way to specify the driver mode. The
existing cluster-driver-registrar doesn't support that and also was
deprecated, so we stop using it altogether and instead deploy and
patch a CSIDriver object.
A number of tests rely on SSH behavior but are not marked with
SkipUnlessSSHKeysPresent(). This means that the tests will run and
hang. This can be confusing for users because they may not know why
the tests failed. Instead, we should be reporting on the known issue
and skipping the test (hence why the helper Skip... function exists).
The PodInfo tests can be extended to also cover the new
csi.storage.k8s.io/ephemeral flag. However, the presence of that flag
depends on whether inline volume support is enabled, so tests that run
with and without the feature have to detect that at runtime.
Other tests have a feature tag and thus can assume that they only run
when that feature is enabled. However, we need a newer csi-mock driver
before we can actually ask it to publish an ephemeral inline volume.
The conceptual change is that the mode in which a volume gets handled
is derived from it's spec, not from the ability of the driver. In
practice, that is already how the code worked because it didn't
actually look at CSIDriver.Spec.Mode at all.
Therefore the code change itself is mostly just renaming "driver mode"
to "volume mode". In some places (CanDeviceMount, CanAttach) the
feature check that was used elsewhere seemed to be missing. Now their
code path for ephemeral volumes are also only entered if that feature
is enabled.
The sanity check whether a CSI driver is being used correctly still
needs to be implemented.
Related-to: https://github.com/kubernetes/kubernetes/issues/79624
