Description of problem: Should describe clear what to fill in Fstype if disk is block when create localvolume on web console Version-Release number of selected component (if applicable): 4.6.0-0.nightly-2020-09-03-191144 local-storage-operator.4.6.0-202009041839.p0 How reproducible: Always Steps to Reproduce: 1.Deploy LSO 2.Click localvolume 3.Check Storage Class Device 4.For FsType, default value is ext4 5.If choose VolumeMode as Block, FsType should fill with blank. But there is no description how to fill FsType value here Actual results: Fstype is not clear for customer how to create block storage class devices. Expected results: Add description about Fstype value when choose VolumeMode as Block. Additional info:
This is auto generated form based on the x-descriptors. This needs to handled via the backend. Also, the volume mode field dropdown should be moved above the FsType field dropdown, as its value gets change based on the volume mode selection. Moving this to LSO team.
The FSType field should be omitted when using volumeMode: Block
console RFE. Should probably move to OCP, as it is an LSO piece. But moving to OCS->management console first, for further triaging.
This needs to fixed from the backend as the form are generated by the descriptors.
We can't do cross-field validation, so I am updating the description to: > File system type to create on empty volumes, such as "ext4" or "xfs". Used only when volumeMode is "Filesystem". Leave blank when volumeMode is "Block".
File system type to create on empty volumes, such as "ext4" or "xfs". Used only when volumeMode is "Filesystem". Leave blank when volumeMode is "Block". Above sentence is added 4.6.0-0.nightly-2020-09-21-030155 Update bz status.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (OpenShift Container Platform 4.6 GA Images), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:4196