Distributed-FIO: PV not getting mounted to server POD when created with pvcvolumemode: Block

[shekharberry]

Describe the bug
A clear and concise description of what the bug is.

When in distributed-FIO CR we specify pvcvolumemode: Block (Default is Filesystem), the PV is not getting mounted on the server POD. The PVC gets bound successfully.

The reason for this is for block mode the POD should have -devicePath but it has -mountPath. (https://kubernetes.io/docs/concepts/storage/persistent-volumes/#pod-specification-adding-raw-block-device-path-in-container)

Here's the output of POD in yaml when pvcvolumemode is Block: http://pastebin.test.redhat.com/1067721

To Reproduce
Steps to reproduce the behavior:

1. Deploy Benchmark-operator
2. Set pvcvolumemode: Block in distributed-FIO CR

Expected behavior
A clear and concise description of what you expected to happen.

the pod yaml, should have something like this for block mode: (Note: its an example)

volumeDevices:
- devicePath: "/dev/xvda"
name: lvm-block-pvc

but it has

volumeDevices:
- mountPath: "/dev/xvda"
name: lvm-block-pvc

Note, for pvcvolumemode: Filesystem (Default Config), the server POD comes up and tests finish successfully.

[mykaul]

How would a distributed fio work against a single block? Who'll coordinate the writes and reads?

[shekharberry]

This issue came up when I was evaluating LVMO Block performance on SNO (by specifying VolumeMode = block in PVC). The FIO tests wouldn't run because of issue described above
It again came up when I had to measure LSO performance where block PVs are created.
My plan is to assign one PV (from 1 NVMe) to a single FIO server and measure performance. This way the storage wouldn't have the shared access.

[mulbc]

@mykaul - Ripsaw never shares the same PVC between Pods. Ripsaw creates as many Pods as we define in the servers variable (in the benchmark CR). Each Pod gets its own PVC. We can tune the amount of parallel IO per PVC with the numjobs and iodepth variables.
Because of this, block PVCs should work just fine

[mulbc]

@shekharberry I think you just need to fix this here:
https://github.com/cloud-bulldozer/benchmark-operator/blob/master/roles/fio_distributed/templates/servers.yaml#L51
Add another if clause for block mode. (could you send a PR please?)

As far as I can see, fio on VMs should work fine already and is not affected by this bug

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.