currently id you run devstack with the dbcounter service enabled
the created subdirs show up in git status
this change justs add them to .gitgnore
Change-Id: Iee48eb4e12ac22734c8a2c1dcbe0b92a0a387eaa
Neutron bobcat release has enabled the RBAC new defaults
by default. With the latest release of Neutron have new
defaults enable, we should configure the same by default in
devstack. This change make NEUTRON_ENFORCE_SCOPE flag to
True by default so that every job will run with Neutron
new defaults.
As old defaults are still supported (in deprecated way),
we will keep this flag so that we can have one job disable
it and test the old defaults.
Change-Id: I3361d33885b2e3af7cad0141f9b799b2723ee8a1
... so that we can use PyMemcacheCache backend. The MemcachedCache
backend, which has been used previously, has been removed in recent
Django, and we are switching the default backend in [1].
[1] https://review.opendev.org/c/openstack/horizon/+/891828
Change-Id: Ie1da8970628e34c41721198cdada8c7bb3b26ec0
Developers that need to stack and re-stack non-AIO compute-only
environments will want to be able to keep the compute node uuid the
same across runs. This mimics the behavior of a deployment tool that
pre-creates the uuids, so it matches pretty well. Default to the
current behavior of create-on-start, but allow forcing it ahead of
time to something specific.
Change-Id: Icab0b783e2233cad9a93c04758a5bccac0832203
Neutron has deprecated linuxbridge support and is only doing reduced
testing for the neutron-linuxbridge-tempest job, so we need no longer
run it in devstack, even less gate on it.
Signed-off-by: Dr. Jens Harbott <harbott@osism.tech>
Change-Id: Ie1a8f978efe7fc9b037cf6a6b70b67d539d76fd6
The depends-on patch adds a new backup_driver option to tempest.
The goal of this change is to be able to do a proper cleanup of
containers when swift is used as a backup driver.
Thich change makes sure that the new option is properly set to
"swift" when Swift is used as the driver.
Depends-On: https://review.opendev.org/c/openstack/tempest/+/896011/13
Change-Id: I76e7fd712ee352051f8aa2f2912a29abad9ad017
This makes the glance-api-remote setup honor the GLOBAL_VENV flag,
and not pass the --venv stuff to uwsgi if it is disabled. This should
fix the glance-multistore-cinder-import-fips job.
Change-Id: I2005da5ced027d273e1f25f47b644fecafffc6c1
local.sh, if present, will be executed at the end of stack.sh. The
sample file here is meant to be copied to devstack root if desired.
Unfortunately, due to Change I86ffa9cd52454f1c1c72d29b3a0e0caa3e44b829
changing to use OS_CLOUD in stack.sh, sourcing openrc here will cause
both OS_CLOUD and traditional OS_* env vars to be set, which causes a
conflict.
Change-Id: Id80b46acab7d600ad7394ab5bc1984304825a672
It has been very stable for some time and it is going to be a major
platform for the next cycle.
Signed-off-by: Dr. Jens Harbott <harbott@osism.tech>
Change-Id: Id2df9514b41eda0798179157282a8486b1e9ae23
The openeuler job running version 22.03 fails due to old libvirt.
Nova requires version 7.0.0 or greater.
Related-Bug: #2035224
Change-Id: I4ad6151c3d8555de059c9228253d287aecf9f953
In order for Ironic perform full testing with devstack, it uses
virtual machines attached to a ovs bridge network to simulate
bare metal machines. This worked great for OVS because often
OVS was already running on the nodes due to the package, and
we could just apply configuration and be done with it when
Ironic's devstack plugin was applying initial configuration and
setting up the test environment.
With OVN, and the requirement of a specific co-installed OVS
version, Ironic has discovered that we cannot perform this same
configuration without having already started OVN during the
initial system setup. Which is fine, but we can't initialize
and start OVN twice. It just doesn't work.
The original form of this patch was proposed by lucasgnomes
in order to validate that we, did, indeed, need to do this
to enable Ironic to successfully test an OVN based
configuration, and is now being revised to handle that case
automatically when Ironic is the selected virt plugin.
Co-Authored-By: Julia Kreger <juliaashleykreger@gmail.com>
Change-Id: Ifbfdaaa97fdbe75ede49dc47235e92a8035d1de6
Add's the OVN_BRIDGE_MAPPINGS variable to ovn_agent.
Uses the same format as OVS_BRIDGE_MAPPINGS, it defaults
to "$PYSICAL_NETWORK:$PUBLIC_BRIDGE".
This enables use of providernet for public network and
setting up additional bridges, for example a for baremetal.
Example:
Q_USE_PROVIDER_NETWORKING="True"
OVS_PHYSICAL_BRIDGE="brbm"
PHYSICAL_NETWORK="mynetwork"
PUBLIC_PHYSICAL_NETWORK="public"
PUBLIC_BRIDGE="br-ex"
OVN_BRIDGE_MAPPINGS="public:br-ex,mynetwork:brbm"
Change-Id: I37317251bbe95d64de06d6232c2d472a98c0ee4d
This was dropped in tempest, too[0], and we want to focus on getting and
keeping the jammy job stable.
Still retaining the nodeset definitions until we are sure they are not
needed in other projects.
[0] https://review.opendev.org/c/openstack/tempest/+/884952
Change-Id: Iafb5a939a650b763935d8b7ce7069ac4c6d9a95b
This was missed as part of [1], neutron sets
exec_dirs in rootwrap.conf differently so that
also needs to be fixed.
Without it neutron openvswitch jobs relying on
neutron-keepalived-state-change scripts were
failing when deployed with GLOBAL_VENV=True as
binaries no longer found at /usr/local/bin.
[1] https://review.opendev.org/c/openstack/devstack/+/558930
Closes-Bug: #2031415
Change-Id: I9aa56bff02594f253381ffe47a70949079f4c240
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
The base systemd unit file setup now writes an Environment= line to
the file for the venv. The glance-remote code was setting that to
point at the alternate config location, using iniset which was
clobbering the venv one. Switch to iniadd to fix.
Also, we need to explicitly put the --venv flag into the command since
we write our unit file ourselves. This probably needs a cleanup at
this point, but since the glance gate is blocked, do this for now.
Change-Id: I2bd33de45c41b18ed7d4270a7301b1e322134987
As a temporary workaround, let's set the GLOBAL_VENV to false
specifically for centos 9 stream and rocky distros where we
encountered issues after changing the default value
of GLOBAL_VENV to True in Devstack:
https://review.opendev.org/c/openstack/devstack/+/558930
Related-Bug: #2031639
Change-Id: I708b5a81c32b0bd650dcd63a51e16346863a6fc0
* etcd 3.3 is no longer maintained.
* etcd 3.4 removes deprecated interfaces, and clients may
need updated configs.
* The cinder backend coordination URL needs to explicitly
specify the version, until tooz can be updated
https://review.opendev.org/c/openstack/tooz/+/891355
* etcd only supports in-place upgrades between minor
versions, so any jobs testing upgrades could fail if
they skip from 3.2 directly to 3.4
Change-Id: Ifcecdffa17a3a2b1075aa503978c44545c4a2a3c
This reverts commit 113689ee4694de20c019735fdace447225aa18f7.
Reason for revert: systemd-252-17.el9 which includes the fix is now available in CentOS 9-stream repos.
Change-Id: I6fe19838a75a30fd5d2434c03b7f403f1c7e4b50
While the patch where this was first introduced and set to 120 [1] is
sensible for the vast majority of jobs, it's conceivable that some
jobs might want a different value.
Specifically, the whitebox-tempest-plugin changes configurations and
restarts Nova services, and to do so it waits for the service status
to update in the API before continuing with the tests. With the report
interval set to 120 and the down time threshold set to 720, the
service would continue showing 'up' in the API long after it was
actually down, causing the wait to time out.
Whitebox is a low-traffic project with only a couple of devstack jobs
that run tempest tests sequentially (concurrency=1). Its CI is also
pretty stable. It seems legitimate for it to keep the old default
values of report_interval and service_down_time.
This patch keeps the 120 default for NOVA_SERVICE_REPORT_INTERVAL, but
makes it configurable by individual jobs. Since the original patch
also introduced CINDER_SERVICE_REPORT_INTERVAL as a constant, make
that configurable as well.
[1] https://review.opendev.org/c/openstack/devstack/+/890439
Needed-by: https://review.opendev.org/c/openstack/whitebox-tempest-plugin/+/891612
Change-Id: I64fa2059537ea072a38fb4900d3c7d2d8f0ce429
glance and rally binaries are also needed.
Also make sure the cinder-rtstool is only called when cinder is actually
enabled.
Change-Id: I18113eabf2fa83e36bace276883775303f6a1e9a
This is being used in some nova jobs, so we need to add it. Also order
the list of linked binaries to allow easier maintenance.
Change-Id: Ief012f7842d6e14380c9575740d1856bc1f2355e
