Bug 1428694

Summary: Create arbiter brick with recommended sufficient disk space
Product: [oVirt] cockpit-ovirt Reporter: RamaKasturi <knarra>
Component: GdeployAssignee: Ramesh N <rnachimu>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 0.10.7-0.0.10CC: bugs
Target Milestone: ovirt-4.1.1Flags: rule-engine: ovirt-4.1+
rule-engine: blocker+
rule-engine: planning_ack+
rnachimu: devel_ack+
sasundar: testing_ack+
Target Release: 0.10.7-0.0.15   
Hardware: x86_64   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
While creating arbiter volumes, arbiter bricks(third brick in the arbiter volume) were created with same size as regular bricks. With this fix, arbiter bricks will be created with 10GB size. Third host will be used as arbiter host and arbiter bricks will be created on that host.
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-04-21 09:47:11 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Gluster RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1277939    
Description Flags
Gdeploy config file with proper arbiter brick configuration none

Description RamaKasturi 2017-03-03 07:41:10 UTC
Description of problem:
When a arbiter volume is created using gdeploy all the bricks for the volumes are created of equal sizes leaving the gain that arbiter brings.

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

How reproducible:

Steps to Reproduce:
1. Install the latest cockpit-ovirt-dashboard
2. Create a arbiter volume.

Actual results:
When replicated arbiter volume is created using cockpit-gdeploy all the bricks of the arbiter volume are created with equal sizes.

Expected results:
size of the arbiter brick should be calculated according to the recommendations present in link [1]

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1365850#c29

Additional info:

Comment 1 SATHEESARAN 2017-03-03 08:51:41 UTC
The expectation of this bug is that cockpit should help in HCI deployment, when user chooses to deploy with 2 powerful nodes ( both high on compute and storage ) and 1 least powerful node ( either low on spec wrt to storage or compute, maybe both ).

In this case, what is recommended storage stack on the third node ?

The ideal solution that I could think of is :
Leave it to user to create the storage space for arbiter brick and get it as input from cockpit. This is fairly simple. User need to allocate the size for the arbiter based on the calculation[1] and provide the brick path as the input to the cockpit, so that would be used as arbiter brick during volume creation.

Recommend user to create such a storage space for arbiter with thinlv that would help in safely extending the size of the thin lv. in case arbiter brick getting full in future.

What are the other solutions to this problem ?

[1] - https://bugzilla.redhat.com/show_bug.cgi?id=1365850#c29

Comment 2 Ramesh N 2017-03-08 03:34:06 UTC
Created attachment 1261059 [details]
Gdeploy config file with proper arbiter brick configuration

Comment 3 Ramesh N 2017-03-08 03:43:07 UTC
I will post a patch with the following assumptions.
    1. There are exactly three hosts in the deployment. This is already
       validated in the hosts step.
    2. Third host in the list will be used as arbiter host and all
       arbiter bricks will be created from this host.
    3. Disk names are same across all the three hosts.
    4. PVs and VGs will be created in the same way in all the hosts.
    5. Size of arbiter brick will be 10GB. So if we have to create
       2 arbiter bricks from same disk then size of the thinpool
       will be 20 GB
    6. LV and Thinpool section in the generated gdeploy config file
       will be common for first 2 hosts and different for third

Comment 4 SATHEESARAN 2017-03-20 06:41:48 UTC
Tested with cockpit-ovirt-dashboard-0.10.7-0.0.15

LVs for arbiter bricks are created of different size than the other 2 bricks ( in that replica set ) and has the size of 10GB