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
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 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 515c295721.
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 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
These dummy variables were for the nodepool.yaml template during
testing, but are no longer referenced. Clean them up.
Change-Id: I717ab8f9b980b363fdddaa28e76cd269b1e4d876
This reverts commit e76e0089d1.
Reason for revert: Facebook mirrors are out of sync for more then 24h that does break CI and block progress. Let's try out another rax mirror
this time.
Change-Id: Ibb0a23ee790aeea5e4f5d05ce731791bd380976a
This is just enough to get the cloud-launcher working on the new
Linaro cloud. It's a bit of a manual setup, and much newer hardware,
so trying to do things in small steps.
Change-Id: Ibd451e80bbc6ba6526ba9470ac48b99a981c1a8d
This should only be landed as part of our upgrade process. This change
will not upgrade Gerrit properly on its own.
Note, we keep Gerrit 3.5 image builds and 3.5 -> 3.6 upgrade jobs in
place until we are certain we won't roll back. Once we've crossed that
threshold we can drop 3.5 image builds, add 3.7 image builds, and update
the upgrade testing to perform a 3.6 -> 3.7 upgrade.
Change-Id: I40c4f96cc40edc5caeb32a1af80069ef784967fd
This provider is going away and the depends-on change should be the last
step to remove it from nodepool. Once that is complete we can stop
trying to manage the mirror there (it will need to be manually shut
down), stop managing our user accounts, and stop writing cloud.yaml that
include these details for inap/iweb on nodepool nodes.
Note we leave the bridge clouds.yaml content in place so that we can
manually clean up the mirror node. We can safely remove that clouds.yaml
content in the future without much impact.
Depends-On: https://review.opendev.org/c/openstack/project-config/+/867264
Change-Id: I01338712aeae79aa78e7f61d332a2290093c8a1b
Docker-compose exec allocates a tty by default unlike docker exec. New
Ansible doesn't provision a tty which causes docker-compose exec to fail
under Ansible now. Address this by passing -T to docker-compose exec
commands which stops allocating a tty. We didn't need one to gracefully
stop zuul services.
Change-Id: Ib52f184f771ae4530f6b6531257dda5d8443043c
I'm not sure if this is clearer or not (which is why I proposed it
separately here).
From inspection of the code, adding "state: latest" just means Ansible
runs "install -U" ... which is pretty much the same thing as adding
--upgrade. Which is clearer, I'm not sure?
Change-Id: I6e31523686555e33d062f3b05f2385d7e21e2620
Zuul