This doesn't do anything substantial yet, but we'd like to start running
the server soon in order to test it out.
Change-Id: I9eb2bccd6e5e9a064cbaff10676aeb1af6653f98
Related to the parent change we want to ensure that the test deployment
of gitea is using a valid secret. This new value was generated via:
`sudo docker exec gitea-docker_gitea-web_1 gitea generate secret JWT_SECRET`
On a held test node and should be more valid than the previous value.
Change-Id: I8cbbaf061e168c2874eb244ff18da6ee544e0d80
During the Gitea 1.22.1 upgrade we had failures because gitea wanted to
write back to its app.ini config file and couldn't do so due to file
permissions. We address that by fixing the formatting for one entry in
the template then separately update a secret var to match what ended up
being deployed to gitea09. In theory this should make everything line up
such that we don't actually need to write back to the file at all.
If this continues to fail we will instead update file permissions and
let gitea rewrite its file instead. But that would be the next thing to
try.
Change-Id: Ic3a6e2dd25ec906c234c2fea26b68eb8f742201c
The linaro mirror node only has a 100GB cache volume to be shared
between OpenAFS and Apache. Each cache gets a ~50GB filesystem dedicated
to it. Unfortunately we were telling Apache's cache pruning system to
limit to 60000M which is large than 50GB. THis resulted in the cache
filling up and I think it may also be the source of errors.
Address this my reconfiguring htcacheclean to limit to ~40GB. This limit
is set with some buffer space as htcacheclean runs periodically and has
to keep things low enough to avoid filling up.
Change-Id: I7af3daa396b1631feefed5952460b8a9710b25b5
Jaeger just released 1.59.0 and that appears to have broken Zuul's
quickstart again. Pin to the 1.58.1 release which should be what we were
running before the 1.59.0 update out of an abundance of caution.
Change-Id: Iefed34f8df2eb105efa1b68edb5d5c76104f836f
This newer version actually restores APIKEY authentication, but we
already converted to oauth2.0 so we don't revert. Otherwise it seems
like there are a number of small fixes. Full change log here:
https://github.com/ether/etherpad-lite/blob/v2.1.1/CHANGELOG.md
In this change we resync configuration template files which results in a
few small updates. We also realign the dockerfile with upstream which
also results in a few small updates one of which is bumping the nodejs
version to 22 from 20.
Change-Id: I39664fde59a7cc9fdf2451d41018ae11b9e99b79
Changes made on our side to make this upgrade happen:
* Update the gitea checkout tag to v1.22.1
* Update the golang container version to 1.22 as gitea 1.22 has an
undocumented hard dependency on golang 1.22 or newer.
* Update our overridden template files to match latest gitea template
changes.
* Update our app.ini config to switch from [oauth2].ENABLE to
[oauth2].ENABLED as the previous config string is deprecated and will
be removed in 1.23.0 per:
...es/setting/oauth2.go:124:loadOAuth2From() [E] Deprecation: config
option `[oauth2].ENABLE` presents, please use `[oauth2].ENABLED`
instead because this fallback will be/has been removed in v1.23.0
The full release notes for this release can be found here:
https://github.com/go-gitea/gitea/blob/v1.22.1/CHANGELOG.md
I've including the list of breaking changes below with my own
annotations on how/whether they affect us.
* BREAKING
* Improve reverse proxy documents and clarify the AppURL guessing behavior (https://github.com/go-gitea/gitea/pull/31003) (https://github.com/go-gitea/gitea/pull/31020)
* This isn't actually a breaking chagne but they have improved docs
around how to properly set Host and X-Forwarded-Proto headers for
gitea to enable better logging behind a reverse proxy. We should
investigate.
* Remember log in for a month by default (https://github.com/go-gitea/gitea/pull/30150)
* Default was a week. We should consider rolling back to low values
since we don't have real users.
* Breaking summary for template refactoring (https://github.com/go-gitea/gitea/pull/29395)
* All custom templates need to follow these changes
* I don't think we're using any of the changed methods/functions in
our templates. Testing should help confirm this.
* Recommend/convert to use case-sensitive collation for MySQL/MSSQL (https://github.com/go-gitea/gitea/pull/28662)
* This is the doctor update to address case sensitivity problems
between git and gitea. We'll need to test this as part of our
upgrade process and testing.
* Make offline mode as default to not connect external avatar service by default (https://github.com/go-gitea/gitea/pull/28548)
* We are already disabling gravatar. I think this will disable it
harder.
* Include public repos in the doer's dashboard for issue search (https://github.com/go-gitea/gitea/pull/28304)
* This affects end user dashboard info rendering which we don't use.
* Use restricted sanitizer for repository description (https://github.com/go-gitea/gitea/pull/28141)
* We already control what goes into repo descriptions via
projects.yaml. Shouldn't really affect us.
* Support storage base path as prefix (https://github.com/go-gitea/gitea/pull/27827)
* This change looks scary at first glance but appears to only affect
minio storage systems (which is like an s3 abstraction layer). We
store things to disk and shouldn't be affected if I read the PR
correctly.
* Enhanced auth token / remember me (https://github.com/go-gitea/gitea/pull/27606)
* THis appears to improve security but it isn't clear what the
effect on end users is. We'll see if our CI jobs are happy with
new token generation I guess.
* Rename the default themes to gitea-light, gitea-dark, gitea-auto (https://github.com/go-gitea/gitea/pull/27419)
* If you didn't see the new themes, please remove the [ui].THEMES config option from app.ini
* We don't do anything special for themes so this should noop for
us.
* Require MySQL 8.0, PostgreSQL 12, MSSQL 2012 (https://github.com/go-gitea/gitea/pull/27337)
* Our version of MariaDB should be new enough to rough rough feature
equivalent with MySQL 8.0 and newer. We might consider helping
upstream add MariaDB testing if they haven't already though.
Change-Id: Ifb4f0d92d70bc06f717e6535f1b67a221e127180
It looks like the :latest image may be the head of the main branch,
which is cool, we do that too, but apparently Jaeger does not test
their releases with Zuul, and it appears they have merged something
that breaks our usage for it. They may be starting v2 development
and thus may be intentionally merging backwards incompatible changes.
To address this, use the :1 image tag, so that we are still compatible
with Zuul.
Change-Id: I7f9602fbd2d98502c5c88641f61b4e408aa1525d
Also add zuul-role-integration jobs for noble to ensure things generally
work as expected on noble, and specifically verify from the testing logs
that the exclusion is effective.
Change-Id: Ic722e992038b3d740108594d80d66f0befc153c7
In change I9e21eb19b85c9a4b19f5e6c5d03a89c89028bbc4 we incorrectly
adjusted Exim's smtp_accept_max_per_host option from 10 to 50 rather
than setting the smtp_accept_queue_per_connection option we actually
needed. Add this parameter as a new tunable in the role, set the
other option back to its prior value, and update comment references
accordingly.
Change-Id: I13f0275202eba8b5190a76bff921f1ac5adbeea0
Now that CentOS 7, 8 and 8-stream have been removed from mirroring we
can drop the mirror script for these releases entirely. Note that
9-stream and beyond use the newer centos-stream script instead and are
not affected.
Once this is completed we should be able to clean up the afs volume for
centos entirely as well (though it is empty currently and has a very low
cost in that state).
Change-Id: I744c61e3386d4ea54efaae9c3a46fd08878263ff
There is a README and a few empty directories to clean up from the
8-stream mirror content. This should be safe to land at any time since
the mirror is no longer functional after upstream cleanup that we
synced.
Change-Id: I467c1f575e9461a8bf8d37697161e65114e5161a
In order to avoid tripping Exim's threshold for punting deliveries
to periodic queue processing, make sure to set Mailman's
mta.max_recipients value less than Exim's smtp_accept_max_per_host.
This should eliminate the "no immediate delivery: more than X
messages received in one connection" errors in Exim's mainlog.
While we're at it, increase both for greater throughput.
Change-Id: I9e21eb19b85c9a4b19f5e6c5d03a89c89028bbc4
This distro release has gone eol and the package repos were
automatically cleaned out for us by upstream. This has resulted in jobs
no longer functioning. Cleaning out the jobs is the first step in
eventually removign the nodesets and image builds from zuul+nodepool.
Change-Id: I873c2b719bad1e9c7b482a42a8566b6b06d447fc
This removes leftover inmotion clouds.yaml related configs from our
configuration management. We remove the hardcoded cert (since the old
cloud used a self signed cert) and various ansible vars used in testing.
Note we keep the ansible task to write out special cloud certs so that
we don't have to reinvent this code in the future / remember we had it
once and unrevert it, but we feed that task an empty list making it a
noop currently.
Change-Id: I2a6fdf06879023ab6ee65437a592d55a8c0eb371
This installs the golang based compose (v2) tool. Also make it the
python based tool optional, but installed by default.
The docker compose v2 tool comes from either:
- Disrto : Moby Engine : docker-compose-v2 : Focal -> Oracular
- Upstream : Docker Inc : docker-compose-plugin : Trusty -> Noble
With manual checking I can't see any distro older than focal that makes
use of the install-docker role, and all in-tree users pull from
upstream, so I think adding the golang compose tool without checking
the release is safe.
Change-Id: Ib8b5af40e626cd2d1a12b643f348001b9fdf4586
Now that we're properly Zuuling the things, it would be great to get
Matrix messages about it. Yay for distributed chat systems!
Change-Id: I2f355b98d93ae43aad72e80532450054caeec35b
In the previous change we set the top level ansible role git repo dir as
safe for git to perform clones against. It seems that for this to work
the way we want it to we actually need to mark the .git dir as safe
instead. Go ahead and do so here.
Change-Id: Id877c721e94d015f68cb51fb862b220da0414970
By default mailman3 uses a single outgoing mail runner. We have seen
lists with large membership (openstack-discuss for example) delay mail
delivery for 5-10 minutes. In an attempt to increase throughput we bump
the number of outgoing runner instances to 4.
This upstream thread [0] has more info on this and other tuning options
we might consider. We start with this one as the other options have
behavior implications and will need more thought.
[0] https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/W4F2OEM4VIEEU4U6MAPVMFIEGERBMY55/
Change-Id: I9e353960fe55468be1dadffd37aada7da6ed7db0
This adds upgrade testing of gerrit from 3.9 to 3.10. This is the very
first step in the very long process of eventually upgrading to Gerrit
3.10.
Change-Id: Iaa77287b1334dc761e8de815704fec4d8d69d863
When updating jitsi-meet to jammy we switched to using {meetpad,jvb}99
as the hostnames but were setting host-vars for {meetpad,jvb}01. Fix that
Also a pointless and harmless ')' was left in a comment so clean that up.
Change-Id: Iad3079d9295559fd286bb41361f4de26efc14091
This removes management of the inmotion cloud mirror and cloud launcher
configs in prepration for retirement of this cloud. We don't remove the
cloud from clouds.yaml files as it is a bit more ambiguous as to how
long that will be useful (potentially necessary for manual cleanup
steps). Instead when we get around to adding openmetal after inmotion
has been shutdown and resurrected as a new openmetal cloud we can
replace clouds.yaml config then.
This cleanup is necessary to avoid errors when the cloud goes away. We
will be working with OpenMetal to make this happen. It shouldn't matter
if we land this before or after the project-config changes for nodepool
cleanup as things are decoupled sufficiently well.
Change-Id: I9d224318a9cfac35b867babff92e1071ca23c574
Our install-ansible-role role is used to install the cloud launcher and
puppet ansbible roles on bridge. It does this by cloning the zuul repos
for these roles into the appropriate ansible role path location. Recent
versions of git will not clone repos owned by different users by default
due to security concerns. This breaks install-ansible-role because zuul
owns the zuul repos and install-ansible-role is cloning as root. In this
case we do trust the zuul repos though so we mark them as safe
directories in the root .gitconfig file.
Change-Id: I0cc4a011bbfb484fcc2ccf0d8b1d254c01fc03d6
