Bug 1895553

Description of problem:
-----------------------
The precondition for the disk block size is that the disks used for volumes should be of same block size, for example, all 'vmstore' brick should be 512B, or all 'vmstore' bricks should be with block size 4KM and there is no mix that is allowed.

The statement is true for LV cache as well.(ie.) SSD can be attached to thinpool composed of bricks of same disk block size. Which means SSD of 4KB block size, can't be attached to thinpool consists of 512B disk block sized disks.

These checks should be done well before deployment and proper assertion, with proper error message should be thrown


Version-Release number of selected component (if applicable):
--------------------------------------------------------------
cockpit-ovirt-dashboard

Actual results:
---------------
No error thrown when mix of 4K and 512B disk block sized disks are used for one volume

Expected results:
-----------------
Preflight check added to validate that the gluster volumes do not contain disks of varied disk block sizes and throw proper error messages,in such situations

--- Additional comment from SATHEESARAN on 2020-07-16 10:14:47 UTC ---

Here are few examples for valid and invalid scenarios

Valid situations are:

1. 512B block sized disks used for engine volume
2. 4K block sized disks used for vmstore volume
3. 4K block sized SSD used as LV cache for thinpool composed of 4KB block sized disks
4. 512B block sized SSD used as LV cache for thinpool composed of 512B block sized disks

Invalid scenarios:

1. 'vmstore' volume configuration has bricks created out of 4KB disk block sized disk on host1, host2 and host3 is using 512B brick for arbiter.etc

--- Additional comment from RHEL Program Management on 2020-09-29 02:32:22 UTC ---

This BZ is being approved for a RHHI-V 1.8.z update, upon receipt of the 3 ACKs (PM,Devel,QA) for the release flag 'rhhiv‑1.8.z'

--- Additional comment from Rejy M Cyriac on 2020-09-29 09:53:53 UTC ---

Based on current GA time-lines for RHV 4.4.3 (24 November), and RHGS 3.5.3 (01 December) at which the gluster-ansible fix (Bug 1857667) is included,
either this BZ may have to be re-targeted for a later RHV 4.4.z update,
or the gluster-ansible fix would have to shipped earlier

--- Additional comment from Gobinda Das on 2020-10-15 07:34:57 UTC ---

(In reply to Rejy M Cyriac from comment #3)
> Based on current GA time-lines for RHV 4.4.3 (24 November), and RHGS 3.5.3
> (01 December) at which the gluster-ansible fix (Bug 1857667) is included,
> either this BZ may have to be re-targeted for a later RHV 4.4.z update,
> or the gluster-ansible fix would have to shipped earlier

Hi Rejy,
 I think we need to ship all gluster-ansible bugs which are targeted for rhgs-3.5.3 and rhv-4.4.3 in  RHGS-3.5.2-Async

--- Additional comment from SATHEESARAN on 2020-10-29 06:45:06 UTC ---

(In reply to Rejy M Cyriac from comment #3)
> Based on current GA time-lines for RHV 4.4.3 (24 November), and RHGS 3.5.3
> (01 December) at which the gluster-ansible fix (Bug 1857667) is included,
> either this BZ may have to be re-targeted for a later RHV 4.4.z update,
> or the gluster-ansible fix would have to shipped earlier

The information is already addressed by Gobinda in comment4
We are targetting this for RHHI-V 1.8 update2

--- Additional comment from SATHEESARAN on 2020-11-07 03:45:48 UTC ---

Tested with gluster-ansible-roles-1.0.5-22.el8rhgs

When creating the volume with its brick on disks of varied block sizes, then error is thrown with proper information

<snip>
        "item": {
            "pvname": "/dev/sdf",
            "vgname": "gluster_vg_sdf"
        },
        "rc": 0,
        "start": "2020-11-07 01:58:33.888422",
        "stderr": "",
        "stderr_lines": [],
        "stdout": "4096",
        "stdout_lines": [
            "4096"
        ]
    },
    "msg": "The logical block size of disk is not 512 bytes"


</snip>

The check works only with CLI based automated deployment of RHHI-V

There will be yet another bug to fix this in cockpit based deployment