On Fri, Jan 22, 2016 at 07:47:17AM +0100, Fabian Arrotin wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 22/01/16 05:18, Dusty Mabe wrote:

...

Hi,

Is it possible to get raw block device storage on nodes in the CI? Right now from what I can tell the nodes come up with LVM set up and no space free in the volume group. There is a root/home/swap LV and we can't really reclaim any space because xfs doesn't support shrinking the FS.

Can we have some free space left in the VG? Is there some other way to get this to happen?

Thanks, Dusty

Initially, the kickstart[s] we use to deploy CentOS {5,6,7} were using the whole disk as one PV, one VG, but minimal space for the LVs. Then people complaint about that, because their tests weren't doing the resize2fs/xfs_grow operations, so we decided to just add the

• --grow option :

part /boot --fstype="ext4" --ondisk=mpatha --size=500 part pv.14 --fstype="lvmpv" --ondisk=mpatha --size=10000 --grow volgroup vg_{{ inventory_hostname_short }} --pesize=4096 pv.14 logvol /home --fstype="xfs" --size=2412 --name=home --vgname=vg_{{ inventory_hostname_short }} --grow --maxsize=100000 logvol / --fstype="xfs" --size=8200 --name=root --vgname=vg_{{ inventory_hostname_short }} --grow --maxsize=1000000 logvol swap --fstype="swap" --size=2136 --name=swap --vgname=vg_{{ inventory_hostname_short }}

Happy to revisit that if needed. One option would be to have Duffy do the resize operation[s] before giving a node by default, and not touch the layout/fs if called with something like "&resizefs=no" Problem is that in such case, the "connect to node, analyze, resizefs" operations would add time to the api request/answer, so not sure if that's the way to go

Now for your raw block device storage, unfortunately there is actually no option, but still something we can probably do through iscsi. What would be the requirements for your tests ?

We would like to have raw block devices for Gluster testing too. Gluster can do snapshots based on lvm-thinp, and we recommend to use a dedicated Volume Group for each brick. Our tests can use files over /dev/loop* devices, but that is not how things should be used for real world setups.

Not sure about the iscsi suggestion, a network filesystem over network block devices is not very common either ;-)

Thanks, Niels

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 22/01/16 12:14, Karanbir Singh wrote:

On 22/01/16 10:53, Niels de Vos wrote:

...

We would like to have raw block devices for Gluster testing too. Gluster can do snapshots based on lvm-thinp, and we recommend to use a dedicated Volume Group for each brick. Our tests can use files over /dev/loop* devices, but that is not how things should be used for real world setups.

The way to resolve that would be to request the instances from Duffy, and then reprovision as needed. that way you own the timelag and process to provision the box ( we can help, ofcourse ). Rather than needing a systemside / system-wide change in the base layer.

That's also a possibility, but not sure that all projects willing to have more disk space would like to reinstall each node given by Duffy either

...

Not sure about the iscsi suggestion, a network filesystem over network block devices is not very common either ;-)

ofcourse, that depends on what you are testing. If perf becomes a thing, then you certainly dont want to go down that route.

Yes, and it's also a CI/Test environment, so while it makes sense to try to be as close as possible as what would be done in ideal/real life scenario, it's not always possible.

As a summary :

- - we can try to bring iscsi targets into the mix, but : - gbit connected - storage node behind itself having not infinite storage space (there are more spaces with the local SSD disks from the provisioned nodes) - - we can change the kickstart files to *not* --grow, and let every project create LVs in the VG as they need/want. As there would be less projects willing that, we can implement in Duffy an extra step (as discussed for the VLAN segregation discussion) to expand/resize by default, and let it in the provisioned state when duffy api is called with an extra parameter ) - - projects can also raw files as block devices on the underlying/existing FS, and setup new VG/LV as needed too (with a performance impact, but still probably faster than using iscsi devices)

- -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab

On 01/22/2016 05:06 AM, Athmane Madjoudj wrote:

Hi Dusty,

On Fri, Jan 22, 2016 at 5:18 AM, Dusty Mabe <dusty@dustymabe.com mailto:dusty@dustymabe.com> wrote:

Is it possible to get raw block device storage on nodes in the CI?
Right now from what I can tell the nodes come up with LVM set up and
no space free in the volume group. There is a root/home/swap LV and we
can't really reclaim any space because xfs doesn't support shrinking
the FS.

Can we have some free space left in the VG? Is there some other way to
get this to happen?

If performance does not impact you tests, you can setup VGs on PVs created from loopback devices (on empty files).

Yeah, that is what we are doing now. Docker creates it's storage on loopback devices by default.

Dusty