We actually just build 3.6.4 and 3.7.1 images using 3.6.3 and 3.7.0
versions of plugins. We also deployed the resulting 3.6.4 image to prod.
Luckily for us 3.6.3 plugin tags match 3.6.4 and 3.7.0 tags match 3.7.1.
There was one exception which we were alredy checking out master for in
order to fix build errors. Now that there is a new reviewnotes tag for
3.6.4 we can drop the master checkout for that plugin and use the tag.
TL;DR this should be a noop for our images but is nice bookkeeping to
avoid surprises.
Change-Id: Ica8b3605ecb0f3f93747b904c39913800d1eee4e
We have added gitea09 to haproxy which allows us to remove one of the
old servers. Remove gitea08 since gitea01 is the host that gets backups
currently.
Note that this only removes gitea08 from haproxy and does not remove it
from gerrit replication or our inventory. We need to do this in a
multistep process to avoid a situation where gitea08 is still serving
requests but not receiving updates from Gerrit. Next step will be to
disable replication. Then we can remove it from inventory and finally
delete it altogether.
Change-Id: I26f368936819a41a7369d2d116e04151301ee0e2
Previously we only published qcow2 images, but on our ARM build we've
only got raw images which means nothing is published. Just prevent
publication of the vhd images and allow raw and qcow2 both to be
accessible.
Change-Id: Idb4b846a3a2fcc1840389e703bf6ff6357b836e9
The replication, manage-plugins, and delete-project plugins all seem to
want to write content out to /var/gerrit/data within the Gerrit
container. At /home/gerrit2/review_site/data we've got an old carried
over dir from previous installations but this does not appear to be bind
mounted.
Best I can tell the replication plugin may use this disk location to
keep track of tasks that are queued,running,etc and this may work around
the issues with autoreloading gerrit replication configs. However, we
don't get those benefits when we delete the container (as with
docker-compose down/up-d) as the content is ephemeral within the
container. Address this by bind mounting the location along with the
other bind mounts.
Note I have excluded this from backups as I think we don't need backups
of things like replication queues. That said depending on what the other
plugins use this for we may need to refine our backup rules in the
future.
Change-Id: If3a91aeb1bd86c8514179b8ecfde17e98c29af6a
The debian openjdk-11-jre-headless package lacks tools like jcmd which
can be useful for debugging the jvm and applications running on top of
the jvm. In particular I had to use `kill -3 $JVM_PID` to get a thread
dump (which worked) instead of jcmd during a recent Gerrit outage.
Since you don't know that you'll need these tools until its too late go
ahead and switch to the jdk package instead of the jre package to be
prepared in the future.
Change-Id: I09a81f1abc6e528b4ffd624050698a99c264f499
This upgrade bumps us up two minor releases for gitea. Changelogs can be
found here:
https://github.com/go-gitea/gitea/blob/v1.18.5/CHANGELOG.md
On the whole seems pretty minor for our uses. I did check the diffs
between 1.18.3 and 1.18.5 for template files we override and those diffs
are empty.
Change-Id: I68204afc28b6382559ece115994c36d35ab60844
Enable Gerrit replication autoreload to simplify the process of adding
new Gitea backend servers and removing old ones. Without this we would
need to enable remote Gerrit plugin administration (which is global for
all plugins including plugin installations) or restart Gerrit everytime
we want ot change the repliction config file.
Note we did have this setting set at one time and it was removed in
e7c6b7602609d14bc49eaca958bcdef788e861cf. This was due to replication
events being dropped and gitea's not being kept in sync when the plugin
updated its config. I think we can toggle this setting to true while we
add do gitea server work and plan for the occasional manual full sync to
ensure nothing gets missed. Then go back to having this set to false
long term when we are done.
Change-Id: I8cf37f6b84516e36deb143a36697874c640c0635
This updates the Gerrit role readme to be a bit more explicit that the
role is deploying both Gerrit and MariaDB.
Change-Id: Ibd39781f0560179d40c3d3d723eec2286dec8583
We didn't update this job's file matchers when review01 was replaced
with review02. That caused us to miss triggering this job when review02
hostvars updated. Fix that which should also cause this job to run since
we update the job.
Change-Id: I8b58ee26084681242b9881651d6eeab9ff8d5ad2
This should only be done after gitea09 is configured and has received a
full git sync from gerrit.
Change-Id: I96fbe9e46aa95e494ce2078bd838046a40badbe4
This is a new server that will need a full sync performed against it.
Don't land this change until after we've edited private vars for
gerrit_known_hosts_keys to add gitea09 there. Landing this change should
update both the replication config and the known hosts at that point.
Change-Id: Ia956e50c25fa91db0585b133415e3a587a3a9597
This adds a new Jammy Gitea09 server to our inventory. THis should
deploy Gitea and provision empty repos on it for entries in our projects
list. However, we'll need to do database surgery to carry over redirects
from an older server. It is for this reason we don't add the server to
the Gerrit replication list or our load balancer's pool.
We'll take this a step at a time and add the new server to those other
items when it is ready.
Change-Id: Idac0f250f74d8db4ff8d6d68c1a1c35c28a4660f
The previous change omitted the .asc suffix which is required since we
are writing this file out to that name. Without this `apt-get update`
fails due to being unable to verify the sources.
Change-Id: Ide9b02575967283ab7309071d9e12af5cdb15cc9
The last iteration of this donor environment was taken down at the
end of 2022, let's proceed with final config removal for it.
Change-Id: Icfa9a681f052f69d96fd76c6038a6cd8784d9d8d
We haven't used the Packethost donor environment in a very long
time, go ahead and clean up lingering references to it in our
configuration.
Change-Id: I870f667d10cc38de3ee16be333665ccd9fe396b9
The mirror in our Limestone Networks donor environment is now
unreachable, but we ceased using this region years ago due to
persistent networking trouble and the admin hasn't been around for
roughly as long, so it's probably time to go ahead and say goodbye
to it.
Change-Id: Ibad440a3e9e5c210c70c14a34bcfec1fb24e07ce
It seems that in django>=3.2 the assumption that an implicit primary
key would be an AutoField changed to becoming a BigAutoField (64-bit).
django warns now
Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'.
HINT: Configure the DEFAULT_AUTO_FIELD setting or the UsersConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
I think we took the hint to add this as BigAutoField.
However, it seems that we probably made the db tables with the smaller
field. When we now start the web container we are told that the
models don't match. When I ran "makemigrations" it made a bunch of
migration files to update to BigAutoField id's.
Because the migrations are made during the installation (I'm
guessing), the container doesn't have this migration included with it.
I think to avoid getting into a mess of migrations, we should just
leave this as is.
If upstream decides to set this on an application-basis I think that
will override this, and we will get a migration as part of the general
installation and that will work fine. The problem is just that we're
setting it "outside" the installation.
Change-Id: I1679631cd4f7ea14563aab07ad4450c35aa90fd8
In order to limit impact to Gerrit's embedded sshd from runaway
automated systems, we employ a concurrent connection limit. Having
the ability to diagnose that limit when users may be encountering it
is necessary. To that end, add a logging rule matching the
connection limit rule, and install an additional administrative tool
capable of interfacing with the kernel's connection tracking
feature.
Change-Id: If5e61bb34cbe2f9fe0c2db9b923842428771c5f0
We are currently getting deprecation errors on apt-get updates about
the docker key being in /etc/apt/trusted.gpg. Move it to a separate
key as is the fashion now.
Change-Id: I4e21656db9084d5c5e22281eb2d189b7fa8eaa00
Add logos for our cloud donors, similar to the
https://openinfra.dev/members/#infrastructure or
https://www.openstack.org/community/supporting-organizations/#infra-donors
lists.
Companies whose logos are listed on the OpenInfra members page have
given explicit permission to the foundation to display those logos
in order to promote their involvement in foundation-led activities,
which includes projects and communities represented by the
foundation (like the OpenDev Collaboratory). The agreements the
companies referenced in this change have entered into aren't limited
to specific web sites, so displaying them on opendev.org shouldn't
require that we seek additional permission in order to do so.
When adding these logos in a subdirectory (for ease of maintenance),
we need to update the copy step from the assets image to the gitea
image making it recursive, otherwise the directory will be omitted
form the final image build. It's also worth noting that COPY
directives in Dockerfiles behave in an odd and non-shell-like
manner, as they flatten the files when recursing source directories,
so you end up needing to force them into the intended target
directories.
Change-Id: I56279da7008cd4961c964b00f23a255e2865b602
This is required for jeepyb to be able to talk to git remotes via ssh.
Unfortunately this was missed when I converted us over to our python
images.
Change-Id: Id6d2eb25871420f2ec717b189beda1295ecc1f74
Docker-ce 23 upstream of us has a hard dep on apparmor but does not
properly express this in its packaging. This leads to errors like:
error: exec: "apparmor_parser": executable file not found in $PATH
Address this by manually installing (with Ansible) apparmor when we
install docker-ce from upstream.
Change-Id: I78607ca49cb7c46b57ec6e4d3489b548362358e5
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
All references to this cloud have been removed from nodepool, so we
can now remove nb03 and the mirror node.
Change-Id: I4d97f7bbb6392656017b1774b413b58bdb797323
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
