As far as I could tell, the global_filter config added in change
I5d5c48e188cbb9b4208096736807f082bce524e8 wasn't actually making it
into the lvm.conf. Given the volume (or rather LVM volume) related
issues we've been seeing in the gate recently, we can give this a try
to see if the global_filter setting has any positive effect.
This also adds the contents of /etc/lvm/* to the logs collected by the
jobs, so that we can see the LVM config.
Change-Id: I2b39acd352669231d16b5cb2e151f290648355c0
glance and rally binaries are also needed.
Also make sure the cinder-rtstool is only called when cinder is actually
enabled.
Change-Id: I18113eabf2fa83e36bace276883775303f6a1e9a
We haven't been testing the distro for a while in CI, e.g. in
Tempest, the jobs on opensuse15 haven't been executed for a year
now.
Therefore the patch removes opensuse support from devstack.
Closes-Bug: #2002900
Change-Id: I0f5e4c644e2d14d1b8bb5bc0096d1469febe5fcc
This patch adds NVMe LVM support to the existing iSCSI LVM configuration
support.
We deprecate the CINDER_ISCSI_HELPER configuration option since we are
no longer limited to iSCSI, and replace it with the CINDER_TARGET_HELPER
option.
The patch also adds another 3 target configuration options:
- CINDER_TARGET_PROTOCOL
- CINDER_TARGET_PREFIX
- CINDER_TARGET_PORT
These options will have different defaults based on the selected target
helper. For tgtadm and lioadm they'll be iSCSI,
iqn.2010-10.org.openstack:, and 3260 respectively, and for nvmet they'll
be nvmet_rdma, nvme-subsystem-1, and 4420.
Besides nvmet_rdma the CINDER_TARGET_PROTOCOL option can also be set to
nvmet_tcp, and nvmet_fc.
For the RDMA transport protocol devstack will be using Soft-RoCE and
creating a device on top of the network interface.
LVM NVMe-TCP support is added in the dependency mentioned in the footer
and LVM NVMe-FC will be added in later patches (need os-brick and cinder
patches) but the code here should still be valid.
Change-Id: I6578cdc27489b34916cdeb72ba3fdf06ea9d4ad8
Previously, loop devices for LVM volume groups backing files were not
created after reboots, causing e.g. Cinder to fail with messages such
as
ERROR cinder.service [-] Manager for service cinder-volume
devstack@lvmdriver-1 is reporting problems, not sending
heartbeat. Service will appear "down".
Now, we use systemd services to manage loop devices for backing files.
Change-Id: I27ec027834966e44aa9a99999358f5b4debc43e0
This enables direct-io on the loop devices that we create for LVM backing
stores. The goal here is to reduce the buffer cache overhead involved with
loop mounting a very large file on a filesystem, as well as potentially
providing a little more block-device-like behavior for things that expect
them. We are hoping this will address some of the very long LVM calls that
cinder does, which randomly take a very long time, causing timeouts.
The loop direct-io support was added in kernel 4.4.0, which was xenial,
but the losetup binary does not have the required flag. Thus, this patch
checks the "losetup -h" output for the flag before deciding to enable it.
Change-Id: Idc69cf3598d6ed6646c0145733c90ad0b1b60883
This patch adds removing of the volume group
before removing the loopback device and
the backing file when performing LVM cleanup
in unstack.sh
Without this commit:
unstack.sh removes logical volumes, removes the
loopback devices and deletes the backing file
but leaves a dangling volume group
$ ./stack.sh && ./unstack.sh
$ sudo vgs
VG #PV #LV #SN Attr VSize VFree
stack-volumes-default 1 0 0 wz--n- 10.01g 10.01g
$ sudo losetup -a
$ sudo vgremove stack-volumes-default
/dev/loop0: lseek 4096 failed: Invalid argument
vg_remove_mdas stack-volumes-default failed
With this commit:
unstack.sh removes volume groups after removing
all logical volumes but before removing
the loopback device and deleting the backing file
Partial-Bug: 1441236
Change-Id: Id9c06fa50f6cad28764f5a3396f559cac9999649
We should be using $VOLUME_GROUP_NAME instead since Icehouse.
$VOLUME_GROUP_NAME has been introduced in
I93b8ef32832269d730c76a6dc24ddb4f20c6d9df and $VOLUME_GROUP is nowadays
only use as a fallback to $VOLUME_GROUP_NAME.
As a code comment in lib/lvm says it we kept the $VOLUME_GROUP around as
"for compatibility with icehouse-generation Grenade". Icehouse is long
gone so now seems a good time to remove any usage of $VOLUME_GROUP.
Change-Id: Id3051b5a196c45266c39fde4f08401aaacf0f6bd
When the loop device is not present because something
has gone wrong, this will print an error:
"losetup: option requires an argument -- 'd'"
Just skip the losetup -d in this case.
Change-Id: Iedc439b1ae924e9a599f6522eb081b83d43190c7
This change provides better handling of tgtadm --op show
output as input of tgt-admin --delete command. In situation
where no output of the first command is present no tgt-admin
command is run.
Change-Id: Ief5e1d50dd679f4d47cffef29ff07e54cc37f80a
Closes-bug: 1554997
I noticed this when debugging some grenade issues failures.
An include of grenade/functions stores the current value of XTRACE
(on) and disables xtrace for the rest of the import.
We then include devstack's "functions" library, which now overwrites
the stored value of XTRACE the current state; i.e. disabled.
When it finishes it restores the prior state (disabled), and then
grenade restores the same value of XTRACE (disabled).
The result is that xtrace is incorrectly disabled until the next time
it just happens to be turned on.
The solution is to name-space the store of the current-value of xtrace
so when we finish sourcing a file, we always restore the tracing value
to what it was when we entered.
Some files had already discovered this. In general there is
inconsistency around the setting of the variable, and a lot of obvious
copy-paste. This brings consistency across all files by using
_XTRACE_* prefixes for the sotre/restore of tracing values.
Change-Id: Iba7739eada5711d9c269cb4127fa712e9f961695
Ia0957b47187c3dcadd46154b17022c4213781112 proposes to have bashate
find instances of setting a local value. The issue is that "local"
always returns 0, thus hiding any failure in the commands running to
set the variable.
This is an automated replacement of such instances
Depends-On: I676c805e8f0401f75cc5367eee83b3d880cdef81
Change-Id: I9c8912a8fd596535589b207d7fc553b9d951d3fe
This avoids us leaving the filter in the global lvm config. Without cleaning
this up, we can hit some failures to run stack.sh because devices are excluded
that we need to be able to see. This resets it to what it was before when
we do a cleanup.
Also, do this before we add the line, so we don't add multiple lines on
successive runs.
Closes-bug: #1437998
Change-Id: Idbf8a06b723f79ef16a7c175ee77a8c25f813244
The Linux-IO is a modern way of handling targets.
Per the IRC discussions lioadm as default
seams like a better default for everyone, for now it will be
optional, but the tgtadm admin support expected to be removed when
lioadm works well with all CI (including third party).
Change-Id: Ia54c59914c1d3ff2ef5f00ecf819426bc448d0a9
A while back I added an lvm.conf file with a device filter setting
to try and clean up the LVM hangs in the gate:
(commit 0b9e76f280)
It turns out this wasn't the real problem, the real problem
is that on an LVS/VGS command LVM will attempt to open and read
all potential block devices in /dev to see if they have LVM data
on them. I initially thought the local filter would keep that
from happening, as it turns out the local filter only limits what's
returned AFTER the actual scan process. In order to keep the scan
from happening at all, either a global_filter needs to be used or
lvmetad needs to be running and enabled.
There are situations in gate tests where /dev/sdX devices are created and
deleted and the result is that we hit situations where LVM tries
to open up devices to check them even if they've been removed. The
result is we have a blocking open call from LVM that takes approx
60 seconds to time out and fail.
Ubuntu won't have a version of lvmetad until Vivid, so for now
that just leaves the global_filter as an option.
This patch adds the filter routine to the end of stack.sh. We don't
want to put the routine in lib/cinder_backend/lvm like we had it because
now we have to set the global filter for all LVM commands on the system.
So we put this as one of the last steps in stack.sh and run it if Cinder
is enabled. This way we can query PV's on the system regardless of what
other services may be running and using LVM and make sure that all of
their devices are added to the filter as well.
Also, make sure we only set this for Ubuntu as Fedora/RHEL variants
utilize lvmetad.
This patch also removes the old change that set the local filter.
DocImpact
Should add this to recommended config for Cinder on systems
that don't have lvmetad, and recommend lvmetad for those that do.
Change-Id: I5d5c48e188cbb9b4208096736807f082bce524e8
Closes-Bug: #1373513
When the lvm package gets installed the meta service does
not gets started automatically, but it becomes enabled so it would be
running on the next reboot.
The lvm commands are configured to use this service.
In the past this issue just causes warnings in the cinder log,
but now it can lead to a real issue.
It is better to ensure it is really running,
because it speeds up the lvm related commands.
Change-Id: I17fe2c3bcf77a6505ed2b6c824c5b20807beb725
A recent patch [1] added support for lvm ephemeral storage for nova,
but at the cost of initializing a default lvm volume group even if it
was not required. This change ensures that init of the default volume
group is only performed when nova and/or cinder are configured to use
lvm.
1: https://review.openstack.org/#/c/132333
Change-Id: I7634ca0ed0ffe1b13464e4d66744918f85149f2e
Closes-Bug: #1414820
DevStack currently lacks support for LVM ephemeral storage in Nova.
This support is important for testing of Nova's LVM backend. The
proposed change adds a default volume group, to be shared by Cinder
and Nova. It also adds a configuration option NOVA_BACKEND, which
must be LVM if it is set, that determines whether Nova should be
configured to use LVM ephemeral storage.
Change-Id: I4eb9afff3536fbcd563939f2d325efbb845081bb
melanie witt