This is done for a number of reasons. First it will allow us to update
the python version used in the images as we can have a 3.10 builder and
base images (but not a 3.10 openjdk:11 image). Second it will allow us
to easily switch to openjdk 17 by simply updating the package we install
and some paths for the jdk location.
The goal here is to have more control over the images so that we can do
things like change python and java versions when we want to.
Depends-On: https://review.opendev.org/c/opendev/jeepyb/+/870873
Change-Id: I7ea2658caf71336d582c01be17a91759e9ac2043
This stops us installing our locally patched git package and shifts to
installing git from debian bullseye. This should pull in git
2.30.2-1+deb11u1 which includes the same patches we made but in the
upstream package.
Reviewers should double check this correct up to date version of git is
installed in the image build.
Note we don't do a straight revert because we need to explicitly install
git to upgrade git on the base image as it has not updated yet.
Change-Id: I34b170f59bc648a8917176ded66ffaea9425c4b9
This reverts commit 3f2cc870b8b0f5aac5249b2f33ac5dfd0ae383db.
Upstream Debian has updated git to 2.30.2-1+deb11u1 which patches git
for the issues we manually patched to cover. We don't need the manual
patch anymore and can switch to the distro hence this revert.
Reviewers should double check that the image build process installs the
expected 2.30.2-1+deb11u1 version.
Change-Id: I6e6c817f078160412983e170abcaa9591a8daaa5
This reverts commit eb823707ab1ba333eedecd2845b6fdb1fab56bba.
Upstream Debian has updated git to 2.30.2-1+deb11u1 which patches git
for the issues we manually patched to cover. We don't need the manual
patch anymore and can switch to the distro hence this revert.
Reviewers should double check that the image build process installs the
expected 2.30.2-1+deb11u1 version.
Change-Id: I17fd16a88fbcaa9bbd5d32bfc6d4bb8cdd52ce99
This updates our Gitea installation to 1.18.3. We bump our go verison to
1.19 to match upstream, disable some newer features in app.ini, and
synchronize our template files with upstream edits.
Otherwise not much stood out to me in the changelog as far as backward
compatibility goes:
https://github.com/go-gitea/gitea/blob/v1.18.3/CHANGELOG.md
Reviewers should look this over and double check that though.
Change-Id: I9679fb4908621a065ab3a0bc670a0e96ea15f476
This explicitly disables gitea federation and repo migrations.
Federation is disabled by default currently, but disabling it explicitly
ensures that won't change on us later. Migrations aren't something we
need so we disable them.
Change-Id: Ic7f3f3fe6927b2ff13509050d0113e01622ed51e
Pull in updated git packages to address CVE-2022-23521.
This is a direct copy of work done in
Ib08ff1fc7b3c8623fa6b927f3010af72e1b946cf
git is included from the openjdk base image
Change-Id: Ia219a2485d166bc192f2172b56a076c94de38e0c
This checks out master of the reviewnotes plugin which includes fixes
for flogger compile time log string checks brought in by a recent Bazel
update. Unfortauntely no 3.6.x tag includes these fixes yet. Judging by
the change log this should be safe though.
Change-Id: I71d4e7732a49236af9f8f558743c19f3dad9818e
Pull in updated git packages to address CVE-2022-23521.
This is a direct copy of work done in
Ib08ff1fc7b3c8623fa6b927f3010af72e1b946cf
Change-Id: Ie7d4c3c50f4b72e83f32c91f17ea7e893c3d943a
Because of templating and variable expansion reasons, this variable
doesn't have the leading "open"
(I22c67c1dfe07d442fb930317adc42a0c970621ab).
Change-Id: If73bae24e57d1f4de1b46e89e95ffd98493ecb33
Emperically raw images start on the new cloud, while qcow2 ones don't.
Let's use raw, which is inline with OSUOSL (the other arm64 cloud) too.
Change-Id: I159c06b710580c36fa16c573bee7302949cf7257
The template files we override do not appear to have changed between
1.17.3 and 1.17.4. This update should get us into a spot where we can
plan to upgrade to 1.18.
Change-Id: I9690a7339bb8ca913ca279c9eaf3ff13eefff9e1
The mix of <Location> and ProxyPass [path] <target> lead to some issue.
This patch corrects them and makes the config more consistent.
Until now, the last URI was actually an error page from the main galaxy
website. With this change, we now hit the S3 bucket as we should,
allowing ansible-galaxy to download the archive, validate its checksum,
and install the intended collection/role.
This patch was fully tested locally using the httpd container image, a
minimal configuration adding only the needed modules and the
ansible-galaxy vhost/proxy, and running ansible-galaxy directly.
In addition, this patch also makes a better testing of the proxy, using
cURL until we actually download the file.
Since ansible galaxy will provide a file under any condition, we also
assert the downloaded file is really what it should be - a plain
archive. If it's a miss on S3 side, it would be a JSON. And if we get an
ansible galaxy answer, that would be an HTML file.
The following commands were used:
Run the container:
podman run --rm --security-opt label=disable \
-v ./httpd.conf:/usr/local/apache2/conf/httpd.conf:ro \
-p 8080:8080 httpd:2.4
Run ansible-galaxy while ensuring we don't rely on its own internal
cache:
rm -rf operator ~/.ansible/galaxy_cache/api.json
ansible-galaxy collection download -vvvvvvv \
-s http://localhost:8080/ -p ./operator tripleo.operator
Then, the following URI were shown in the ansible-galaxy log:
http://localhost:8080/http://localhost:8080/apihttp://localhost:8080/api/v2/collections/tripleo/operator/http://localhost:8080/api/v2/collections/tripleo/operator/versions/?page_size=100http://localhost:8080/api/v2/collections/tripleo/operator/versions/0.9.0/
Then, the actual download:
http://localhost:8080/download/tripleo-operator-0.9.0.tar.gz
Then the checksum validation, and eventually it ended with:
Collection 'tripleo.operator:0.9.0' was downloaded successfully
Change-Id: Ibfe846b59bf987df3f533802cb329e15ce83500b
This reverts commit 515c29572190158428ac172febbf6871cf8977ee.
We found the reason why nodepool-builder wasn't starting was that when
we had the system-python and upstream-python installed at the same
version at the same time, the upstream-python was not built to use
relative libraries and hence started using the libpython.so from the
system-python. This meant it was looking for libraries installed in
the system-python path (dist-packages) not the pip/upstream path
(site-packages). This was reported and upstream are currently
evaluating a fix for that [1]
In the mean time, we merged Ib3dfda3df69e7ab359b96cd1865e47c7e1e8047b
which also avoids this problem by not including the "unstable" distro
in the image. Since the system-python 3.11 packages were coming from
"unstable", this avoids the "same version" of the problem; the
upstream-python won't pick up the older version's libpython.so.
After this change the image is actually broken with this, because it
directs the system-python (now 3.9 since the change) to the 3.11
libraries, which obviously doesn't work. Thus revert this now.
[1] https://github.com/docker-library/python/pull/785
Change-Id: I814d5920d8203bcb9f60b9769164c3d2a925f526
Now that we've dropped gerrit 3.5 we can convert label functions to
submit requirements. This is required for Gerrit 3.7 but is optional
under 3.6. Eventually we'll need to do this for all of our custom labels
prior to the 3.7 upgrade.
Change-Id: I4dda45040842de76c12f36b5b6d6b5948d82077a
The arm builder image has a weird python path for some reason we
don't understand yet. Override it (the same path should work
for both arm and x86) until we figure that out and fix it.
Change-Id: I170859bade9f1369d8482c660d72a39db11aaff0
The pytest-testinfra repository default branch is "main", not master.
Overriding this in the zuul job/config will allow to actually run
system-config-run-base-ansible-devel job (or, at least, start it).
Change-Id: Ie42c078fa51bcda8e26264e4b2e19e2447ab89ad
The new nb04 builder hosted in OSUOSL does not have an ipv6 address.
Check if the host being setup defined public_v6, if not then use the
ipv4 addresses of the ZK hosts.
Change-Id: I9ee09006cb7f61e5c1adbb489e8145e59cbbc281
The modified section of the rules.v6 template looks at the groups in
the iptables_allowed_groups list and then allows access for each host
specified in that group.
Currently this extracts the 'public_v6' from the hostvars[host]
directly, but this fails if the host in question doesn't actually have
an ipv6 address.
Modify this so we check if the variable exists, and then reference it
via the hostvars dict. Note that in gate testing, ipv6 may be empty
string (set from nodepool values), while it may not be a value at all
if it is left out of the production inventory.
"hostvars[host]['public_v6'] | default(False)" should catch both
cases.
Change-Id: I90069efc7d72d881ec57670b9c6b426a8a5422a3
If this flag is set, the logs are copied into the published job.
There's no need to save an encrypted copy of the same thing.
Change-Id: I32ac5e0ac4d2307f2e1df88c5e2ccbe2fd381839
If infra_prod_playbook_collect_log is set, then we copy and publish
the playbook log in the job results.
Currently we skip renaming the log file on bridge in this case,
meaning that we don't keep logs of old runs on bridge. Also, there is
a bug in the bit that resets the timestamp on the logfile (so it is
timestamped by the time it started, no ended) that it isn't checking
this flag, so we end up with a bunch of zero-length files in this
case.
I guess the thinking here was that since the log is published, there's
no need to keep it on bridge as well.
The abstract case here is really only instantiated for
manage-projects, which is the only job we publish the log for. Today
we wanted an older log, but it had already been purged from object
storage.
It seems worth keeping this on-disk as well as publishing it. Remove
the checks around the rename/cleanup. This will also fix the bug of
zero-sized files being created, because the renamed file will be there
now.
Change-Id: Ic5ab52797fef880ae3ec3d92c071ef802e63b778
This disables the upgrade testing temporarily with the intention of
adding it back again when we build 3.7 images and can test the 3.6 to
3.7 upgrade.
Change-Id: I102795248ab9e692e4558257d94d5b3e0b73267e
