[Ci-users] Disk space on ci nodes

Fri Jan 22 10:53:40 UTC 2016
Niels de Vos <ndevos at redhat.com>

On Fri, Jan 22, 2016 at 07:47:17AM +0100, Fabian Arrotin wrote:
> 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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.centos.org/pipermail/ci-users/attachments/20160122/a06fa9c3/attachment-0003.sig>