Description of problem: We run Origin containerized as in v3.7.0-rc.0 on 3 RHEL7 VMWare VMs ; all these nodes act as [ master, nodes, GlusterFS, etcd, HAProxy, Heketi, ... ] ; we intentionally want to overcommit the disk space dynamically provided by Heketi since we can connect a new virtual disk on each node and enlarge the 3 VGs used by GlusterFS whenever the VG disk space would really get few. We'll monitor the VG disk space by Nagios or similar. Could you please make configurable the creation of block volumes exceeding the capacity of block hosting volume? The default might be set to 'false'. The setting of this property has to be manageable from the Origin inventory file. Version-Release number of selected component (if applicable): docker.io/gluster/gluster-centos ID: a3fec3f067e6 docker.io/heketi/heketi ID: a5c5b80471fc Heketi v5.0.0-5-gb005e0f-release-5 How reproducible: It's the default Heketi behavior as in version v5.0.0-5-gb005e0f-release-5 Steps to Reproduce: 1. It's enough to create 1 Heketi volume exceeding the single VG size. Actual results: Heketi returns : Failed to provision volume with StorageClass "glusterfs-storage": glusterfs: create volume err: error creating volume No space Expected results: Heketi overcommiting the disk space because its administration will be left to the Sys Admin. Additional info:
Kindly an update about this bug, thanks.
(In reply to fabio.martinelli from comment #0) > Description of problem: > > We run Origin containerized as in v3.7.0-rc.0 on 3 RHEL7 VMWare VMs ; all > these nodes act as [ master, nodes, GlusterFS, etcd, HAProxy, Heketi, ... ] > ; we intentionally want to overcommit the disk space dynamically provided by > Heketi since we can connect a new virtual disk on each node and enlarge the > 3 VGs used by GlusterFS whenever the VG disk space would really get few. > We'll monitor the VG disk space by Nagios or similar. > > Could you please make configurable the creation of block volumes exceeding > the capacity of block hosting volume? The default might be set to 'false'. > The setting of this property has to be manageable from the Origin inventory > file. > > Version-Release number of selected component (if applicable): > docker.io/gluster/gluster-centos ID: a3fec3f067e6 > docker.io/heketi/heketi ID: a5c5b80471fc > Heketi v5.0.0-5-gb005e0f-release-5 > > > How reproducible: > It's the default Heketi behavior as in version v5.0.0-5-gb005e0f-release-5 > > Steps to Reproduce: > 1. It's enough to create 1 Heketi volume exceeding the single VG size. > > Actual results: > Heketi returns : Failed to provision volume with StorageClass > "glusterfs-storage": glusterfs: create volume err: error creating volume No > space > > Expected results: > Heketi overcommiting the disk space because its administration will be left > to the Sys Admin. I don't fully get yet what you're trying to achieve: Are you suggesting a sparse file for the block that is nominally larger than the block-hosting volume underneath? Currently the block volume is fully preallocated explicitly, i.e. we can not overprovision. We might think about implementing this overprovisioning, but we would be careful with that, since it really requires the user to monitor the free space. Since you seem to be using upstream versions, would this not be more appropriate as an issue in the upsteam github repository https://github.com/heketi/heketi?
Dear Adam no I wasn't thinking about sparse files I basically need to get restored the previous Heketi overprovisioning behavior reported in the bug 1468882 ; that behavior must to be configurable by a setting in the OpenShift Ansible input file, for instance heketi_overprovisioning=false that in my case I'd set as true. My rationale is that the community I'm serving constantly creates GlusterFS volumes bigger than what they really need, at the very least 10GB that in turn means 3 x 10GB GlusterFS bricks maybe just to preserve 1.5GB of real data. kindly do I need to file an issue on https://github.com/heketi/heketi in order to get this implemented or is this bug report enough for the Heketi team ?
We don't think there is a safe way to overcommit blockvolumes without letting the IO performance go down. Won't be working on this.