Bug 1662739

Description Of the RFE : We would like to propose a feature to be implemented in the Heketi brick placer. The current brick scheduler strategy of Heketi tries to spread volume's bricks among the different zones of the loaded topology. In case of having a  topology with 3 zones, Heketi would create replica-3 volumes composed by bricks distributed among those zones. But in case one of those zones went offline, Heketi would create the volume's  bricks in the remaining two zones (e.g. 1 brick in zone 1 and another one in zone 2). 

The previous behavior would make volume become read only if the zone with two bricks went offline in a future. 

We would like to have a flag that would make Heketi force to create bricks in different zones, and if that was not possible, Heketi would return an error and would not provision the volume.


1. Why exactly do you need this feature? (List the business requirements here)
We have several production environments with a stretched cluster architecture for GlusterFS: 2 datacenters/zones (2 nodes in each) for data bricks and another zone for arbiter bricks (VMs on top of VMWare solution)
If one of the Datacenters goes down and a volume is created during that outage, data bricks would be created in the same DC and would not meet our data availability requirements.

2. How would you like to achieve this? (List the functional requirements here)
A lag or option passed to Heketi either in the OCP's storageclass or config file could be the best approach to force the topology for volumes.

3. Do you have any specific timeline dependencies?
We are now deploying the above Gluster stretched clusters, this is not a blocker feature for us, but we would like to see it implemented in the next OCS major version if possible. (March?)

4. Would you be able to assist in testing this functionality if implemented? Yes, we already have open several RFEs previously and we have given feedback/suggestions to the engineering/BU teams .