This reverts commit 1c188ad440.
Reason for revert: This change increases test failures; investigation is ongoing.
Change-Id: I3a101656ee0904e1cf6c856dba845385c333260f
I'm not sure if this is a good idea or not yet. Testing with MySQL
actually exposed the alembic transaction thing that is fixed in a
grandparent change. That said much of the world seems to be moving to
MariaDB so it might be a good idea for us to test that more explicitly?
We update bindep.txt which will install mariadb during CI job runs. We
also update our local test setup tooling to roughly match what will be
used in CI. For example the mariadb:10.6 docker image is chosen because
this is roughly equivalent to what Jammy packages.
Another good reason for this change is that Debian ARM64 does not
package MySQL and only packages MariaDB. This should give us better
compatibility for testing on architectures other than x86-64.
Change-Id: I9d00557ca5823da34278c3e9ecda2daaf13440b7
Recently I debugged an issue that reproduced on mysql 8.0 on Jammy but
not my local system. It took quite some time for me to realize that
there was a difference in database versions which ended up being
an important detail. Update our docker-compose to better match what we
get in CI.
Change-Id: I7de268acb81680f3e6b7d3b1aa057e7babd3fa62
The zookeeper containers entrypoint will try to switch to the user
'zookeeper' if the container is started with uid '0'. This can cause issues
when the uid for the zookeeper user inside the container and the
users uid outside the container differ since it will lead to zookeeper
getting access denied when trying to read the certificates.
This also adds logging configuration to make it easier to debug
zookeeper in the future.
Change-Id: I51db53fe093a294e804148f682053123f54adfe1
In case for whatever reason there is already another
MySQL server running on the standard port developers
may want to run the MySQL test-server on a different
port. This can be done by specifying an environment
variable "ZUUL_MYSQL_PORT":
export ZUUL_MYSQL_PORT=3307
tools/test-setup-docker.sh
tox -e py3
Change-Id: Id32bac1a87619803d973b066762d525bd9a4f913
When executing the unit tests with multiple schedulers in parallel a lot
of them are failing becasue there are too many open SQL connections.
However, executing those tests one after another doesn't end up in the
connection limit being exhausted. So this doesn't look like a shutdown
problem in Zuul.
Having a look at the MySQL server when it's under load during the tests
revealed that the default connection limit of 151 on the server side is
exhausted very quickly when a lot of tests are running in parallel (each
test running with two schedulers).
Therefore, this change increases the default MySQL connection limit to
300. We should keep in mind that this connection limit has to go in hand
with the number of schedulers used in the unit tests and the number of
tests executed in parallel. Maybe on the long term it might make sense
to cap the latter parameter somehow in the tox.ini file.
The same applies to the ZooKeeper connection limit which is configured
in tools/zoo.cfg.
Change-Id: Iff76e99ec82edc8e8bc110a22a096bb689d8dd1f
This mirrors the configuration in Nodepool for using TLS-enabled
ZooKeeper in tests. We use the ensure-zookeeper role in order
to get a newer ZooKeeper than is supplied in bionic.
Change-Id: I14413fccbc9a6a7a75b6233d667e2a1d2856d894
We currently have the test-setup.sh script that installs and
configures the services that are needed to run the zuul test
suite. However this needs mysql, postgres and zookeeper installed into
the system. It also messes with tmpfs mounts of zookeeper. This adds a
docker-compose based test setup that can ease the setup of the test
requirements on a developer machine.
Change-Id: Ib0e3f42898c6e9258625b03bcc363e91f4b7ee83
James E. Blair