Currently, there are some unit tests that are failing on Windows due to
various reasons:
- volume mounting is a bit different on Windows: Mount will create the
parent dirs and mklink at the volume path later (otherwise mklink will
raise an error).
- os.Chmod is not working as intended on Windows.
- path.Dir() will always return "." on Windows, and filepath.Dir()
should be used instead (which works correctly).
- on Windows, you can't typically run binaries without extensions. If
the file C:\\foo.bat exists, we can still run C:\\foo because Windows
will append one of the supported file extensions ($env:PATHEXT) to it
and run it.
- Windows file permissions do not work the same way as the Linux ones.
- /tmp directory being used, which might not exist on Windows. Instead,
the OS-specific Temp directory should be used.
Fixes a few other issues:
- rbd.go: Return error in a case in which an error is encountered. This
will prevent "rbd: failed to setup" and "rbd: successfully setup" log
messages to be logged at the same time.
When run as non-root user, TestAttacherMountDevice fails, because of missing
nil check that induces a panic. Fixed by doing err nil check
before using the returned user value from user.Current()
The CSI attacher that runs inside of the AttachDetachController has
access to a VolumeAttachment lister. By polling this lister for the
status of VolumeAttachments, we can save threads on the API server by
not using watches.
This way of syncing informers ensures all informers generated from these
factories are synced. Informers are lazy loaded, and only created once a
user calls .Informer() (which was why the .PollImmediate() worked).
Asserting the number of synced types to ensure everything is set up
correctly.
The reason for adding an expectedVolumeHost field is to prevent a
channel read from hanging when a test fails prior to creating the
VolumeAttachment watch.
fakeVolumeHost previously implemented both the KubeletVolumeHost and
AttachDetachVolumeHost interfaces. This design makes it difficult to test the
CSIAttacher since it behaves differently depending on what type of
VolumeHost is supplied.
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.
