We want to go ahead and install a custom OpenAFS package set on the
latest Ubuntu LTS too, so just drop the version restriction on that.
Also, the newer version of OpenAFS in our PPA should build properly on
ARM64 so we make the noble arm64 roles job voting again.
Change-Id: Iaa4ab95476dc7601ce45b25cb045ee990cdf1039
This reverts commit 95f0c32a61b27c0a9fb3a9c891420d9bcf841cca.
We add a bit more code on top of the revert to capture output in a log
file (pruning is very verbose) and rotate 30 daily copies of the log
file.
Change-Id: I1778989d676d316537cf135b8e14a255434091b4
CentOS ARM in particular complains bitterly if we try to upgrade openafs
on it and the kernel it is running is stale compared to packges in the
mirrors. This happens if our images have lagged behind upstream package
updates. To mitigate this we upgrade and reboot the system prior to
testing openafs installation.
To make arm64 reboots onto the new kernel reliable we manually run
grubby --set-default to explicitly set the default kernel to boot to the
newly installed kernel. Then we remove the old kernel with grubby and
finally generate a new grub config. This is necessary likely due to:
https://bugzilla.redhat.com/show_bug.cgi?id=2032680
Note we also do the reboot (but not grub(by) dance) on Debuntu for
symmetry.
Change-Id: If87a0b1d7dc063ac9122d85f65b6fe1c129d2052
Thiss adds vexxhost as a second openstack cloud connection to the
zuul launcher. This will help us benchmark image times for "raw"
images.
Change-Id: Ifdab5abb9915f384482eda844194f77e8d1b80ca
This adds documentation that should at least remind us that we have
a repo with the .deb files for our openafs packages and roughly
how to go about updating them.
Change-Id: I4e52be22eef0cf9daf8e3d92d3df04fa3a523c2f
This adds a retirement and purge list to the borg management role.
The idea here is that when a backed-up host is shut-down, we add its
backup user to the retired list. On the next ansible run the user
will be disabled on the backup-server and the backup repo marked as
retired. On the next prune, we will trim the backup to only the last
run to save space. This gives us a grace period to restore if we
should need to.
When we are sure we don't want the data, we can put it in the purge
list, and the backup repo is removed on the next ansible run (hosts
can go straight into this if we want). This allows us to have a
review process/history before we purge data.
To test, we create a fake "borg-retired" user on the backup-server,
and give it a simple backup. This is marked as retired, which is
reflected in the testinfra run of the prune script. Similarly a
"borg-purge" user is created, and we ensure it's backup dir is
removed.
Documentation is updated.
Change-Id: I5dff0a9d35b11a1f021048a12ecddce952c0c13c
We want to ensure multiple runs of acme.sh and the entire letsencrypt
machinery produce expected results so run the playbook twice in this
job.
Change-Id: I24afd27a07576bd8e30b4466d338310bdff89d49
We install acme.sh into /opt on our servers. Some of our servers rely on
/opt for data intensive activities and we can run out of disk space on
/opt/. When our daily Ansible runs fire and hit servers in this
situation we end up with corrupted acme.sh repos on those servers. Then
acme.sh roles fail.
Avoid this problem by only updating the git repo for acme.sh if it isn't
already up to date on the versions we expect. We can still fill the disk
but this won't affect acme.sh only server operations that rely on /opt
disk space.
This is an alternative to https://review.opendev.org/c/opendev/system-config/+/934247
which will try to force updates to occur regardless of git repo
corruption.
Change-Id: Ib0ad55de833a2c2d9e8cacec0493b8422e486789
This is follow-up of c28f5682fc1009384c7541604ccc6afa6467adf3 and
fixes the missing component to ensure all puppet 8 packages are synced.
Change-Id: Ic9e202cdc5038857d22ff9ec6a2b85164e85f9d3
The Django admin account is also a super user in Hyperkitty and
Postorius, providing a backdoor for systems administrators in a
pinch.
Change-Id: Ic2a8763186c8b6f689c7e8c2f016429944aad753
This appears to be a small update compared to other recent updates. In
particular the dockerfile has not changed and neither have the
settings.json files. The changelog can be found here:
https://github.com/ether/etherpad-lite/blob/v2.2.6/CHANGELOG.md
The only notable update there is that pads can be deleted by their
creators. I suspect this is a noop for us since we don't do
authenticated access, but we should check with a held node.
Change-Id: I4e935828912d004eb7694e981926557db8b26e56
When we bumped things up previously there was a bug in openafs that
prevented it from being built by dkms on newer platforms. This has since
been fixed in Debian and hopefully Noble as well. Bump up the node to
Noble to find out.
Change-Id: I954e02935ece1d348460316dcfea028452c19413
When we restarted Gerrit recently there were a number of caches that
were over their default max sizes so were pruned. Gerrit prunes daily at
0100 or when restarted. This gives us a good indication for which caches
are currently configured to be too small for typically operation as we
restarted several hours before 0100.
All of the logged cache pruning can be found in this paste [0]. Many of
these caches were floating around their configured maximum and we leave
them alone. However four related caches are well above their default max
which is a good indication we need to increase their sizes. The four are
identified below with their documented purpose/function from the
upstream docs [1]:
* cache "git_modified_files"
Each item caches the list of git modified files between two git trees
corresponding to two different commits. This cache does not read the
actual file contents nor does it include the edits (modified regions)
of the files.
* cache "modified_files"
Each item caches the list of modified files between two commits. This
cache is similar to the git_modified_files cache but performs extra
logic including filtering out files that are untouched by both
commits because they were purely modified between the parent commits.
* cache "git_file_diff"
Each item caches the pure git diff between two git trees for a
specific file path. The diff includes all the file attributes
(old/new paths, change/patch types) as well as the list of edits
corresponding to the modified regions in the file.
* cache "gerrit_file_diff"
Each item caches the diff between two git commits for a specific file
path. This cache is similar to the git_file_diff cache but performs
extra logic including identifying the edits that are due to rebase.
The diff for the "commit message" and "merge list" can also be
requested from this cache.
Entries in this cache are relatively large, so memoryLimit is an
estimate in bytes of memory used. Administrators should try to target
cache.diff.memoryLimit to fit all changes users will view in a 1 or 2
day span. The same applies for other diff caches:
"git_modified_files", "modified_files" and "git_file_diff".
The note at the end of cache "gerrit_file_diff" is what we use to
determine these new sizes though we're more conservative with the memory
limits (default of which is 10m for each of these caches) as memory is
more scarce than disk.
[0] https://paste.opendev.org/show/bk4pTIuQLCsWaF3dVVF7/
[1] https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#cache
Change-Id: I521b53c130892fc2152586da1c4858ea4099479f
Similar to I127ba4a2cf33f7ffcecdf81acfc5c38db565da82 we now need
to add the nodepool clouds.yaml to the zuul schedulers. When validating
and generating the config for the launchers, they need to access the
clouds.yaml file to learn some information about the cloud (eg, image
format). Therefore, they must have the same clouds.yaml that the
launchers use.
Change-Id: I4a7076e66c9f8eca936ca3a7902537d427a99323
There are new bugfix updates for both of the Gerrit images we are building.
Bump up to these new releases. As far as I can tell all plugins with fixed
tags have just been retagged (for both v3.9.x and v3.10.x).
Change-Id: Ie57b11a48919bd3fb0f27beaf8d92a99397bb10a
These images were kept around because zuul-operator was still relying on
them. Now that zuul-operator has updated to bookworm [0] we no longer
need to build and keep these images up to date. Drop them as the extra
effort is unneeded.
[0] https://review.opendev.org/c/zuul/zuul-operator/+/896142
Change-Id: I8d9ee1e4fa2b33fa37f75b27301e7e9f5559510e
This is defined in the big zuul group (and used by the zuul role),
so let's just rely on that definition.
Change-Id: I2c5b5d744a3506717d9c4ad15fa04344bb5890bd
This is a bugfix release with a number of improvements. The full
changelog can be found here:
https://github.com/go-gitea/gitea/blob/v1.22.3/CHANGELOG.md
There were no template changes in the template we override compared to
v1.22.2 (the current deployed version). No other build changes appear to
exist either (same golang version etc).
Change-Id: Id8d7057596e2a067534076507ffa64e4a85ac5e3
linuxcontainers mirror is not used by any maintained branch, thus can
be safely removed from mirrors
Change-Id: I6e223325af7d9cca55c76cc71c93ea20ad89ebbe
It seems these mirrors/repos are not used anywhere as of today and
can be safely removed from the list.
Change-Id: I4aee98aa6c159bb4617b0b584dee943f1070303c
