The image size limit for glance using the unified limits is
set to 1000MB (~1GB). This is pretty low given that a volume's
minimum size is 1GB and when uploaded to glance fills out the
whole limit.
The limit issue can also be seen by a recent tempest change[1]
where uploading two volumes failed[2] across various jobs due
to this limit.
We do have a config option in devstack
``GLANCE_LIMIT_IMAGE_SIZE_TOTAL`` but that will need to be
configured for various jobs and a 2GB seems to be a sensible
default which this patch configures.
[1] https://review.opendev.org/c/openstack/tempest/+/938592
[2] Jan 07 23:05:33 devstack-ceph cinder-volume[909965]: ERROR
oslo_messaging.rpc.server cinder.exception.ImageLimitExceeded:
HTTP 413 Request Entity Too Large: The request returned a 413
Request Entity Too Large. This generally means that rate limiting
or a quota threshold was breached.: The response body:: Project
dfe8648c188d46409349eac2c449c0b4 is over a limit for [Resource
image_size_total is over limit of 1000 due to current usage
1024 and delta 0]
Change-Id: I533b7444e5f71275ea3d5c18914e306b1dbbc5cb
(cherry picked from commit 9a1cdbc3c8)
(cherry picked from commit 6285006ce2)
These jobs are currently broken due to a partial migration to um/2023.1.
Because the older branch is now in unmantained mode, these jobs are
not longer executed in this stable branch.
Related-Bug: #2089522
Change-Id: I53309fa74dac0e2659f5f08bcd188b5e563ecb95
Only branches with stable/ as prefix were considered
but now we have branches even with different
prefix like unmaintained/, fix it to consider
such cases by using a generic filter instead of
assuming branch name starts with stable.
Change-Id: I967de13094ff6df46737a22d4e1758f9900dfbc9
(cherry picked from commit 4d69238383)
Without this, running DevStack on an `aarch64` environment will end
up in cpu_model set to "Nehalem" and cpu_mode set to "host-passthrough"
which does not work.
This patch drops that value under aarch64 environments.
Change-Id: I30be5a388dda5ccf08718670dbb14a28a4a8a8eb
(cherry picked from commit 28bed125a2)
We want to run these only on the master branch, need to clean up after
branching.
Change-Id: I42a651e9d07485c7a3e61fcc2380e33fb4ee6b0b
(cherry picked from commit e3494203fd)
Downloading an image can fail due to network issues, so let's
retry 5 times before giving up. We have seen issues in CI due
to network issues as described below and in the Related-Bug:-
Often times fetching Fedora image in FIPS jobs fails due to
"GnuTLS: One of the involved algorithms has insufficient security level."
This occurs when request to pull image is redirected to a mirror that's
incompatible with FIPS enabled system.
Making multiple attempts to download images could provide better chance of
pulling images from different mirrors and avoid failure of the job.
This will also save a few rechecks.
Related-Bug: #2045725
Change-Id: I7163aea4d121cb27620e4f2a083a543abfc286bf
(cherry picked from commit 6b0f055b4e)
This commit cap the network, volume and swift extensions on
Tempest's config option api_extensions.
In 2023.2, new extension in neutron are:
- port-hint-ovs-tx-steering
- enable-default-route-bfd
- enable-default-route-ecmp
- standard-attr-fwaas-v2
- allowed-address-pairs-atomic
- network_ha
- security-groups-rules-belongs-to-default-sg
- port-hardware-offload-type
and no new extensions in swift and cinder.
Change-Id: Ic5a2389083f66940739efd01b703fbae96bd5d24
As added in notes for INSTALL_TEMPEST variable we need to set
this as False for stable branch so that devstack does not
install Tempest at system wide.
Change-Id: Id47f3c34affb9a903b94963c1ffdd484a3cc74bc
devstack-platform-rocky-blue-onyx is failing 100% on the newly
created stable/2023.2 branch. Below is the failure while setting
up the devstack for stable/2023.2
https://zuul.opendev.org/t/openstack/build/f25dd57dbf6c491c8b5c1318b4eff5a2
Making it non voting until issue is resolved.
Related-Bug: #2038733
Change-Id: Ibb496353640d179f19b99efcdf0068303476da06
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
(cherry picked from commit ca4d5132e6)
Update the URL to the upper-constraints file to point to the redirect
rule on releases.openstack.org so that anyone working on this branch
will switch to the correct upper-constraints list automatically when
the requirements repository branches.
Until the requirements repository has as stable/2023.2 branch, tests will
continue to use the upper-constraints list on master.
Change-Id: I081d176fff9699f1b77777b3b7d23e8ae1f6bdd3
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
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 113689ee46.
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
