People are starting to use this service so having performance metrics
over time is a good thing. We also want to avoid having our cert expire
unexpectedly.
Change-Id: I744b3e68f8f483b36c0d8ecb6f6f46a484a3577a
This is a rebuilt host for this mirror, the old one has been removed.
Depends-On: https://review.opendev.org/727899
Change-Id: Icaf4ad1d88a40c0abdfe1e87386b3c557de062a1
Due to the way OpenStack Ansible and Nova work we can't update the value
for our ssh keys entries in nova. We need to create a new key then
switch everything over to that. Unfortunately, we've had a few people
request their keys be removed and a few others that haven't been active
since the last rotation. That means now is a good time to do a rotation
to clean up the set of valid keys.
Change-Id: Idb7c5eaa546096784e428b3cde61581dcc9050a2
This server was removed everywhere but our inventory. I checked it
doesn't show up in a nova listing. Remove it from here so we can remove
it from the emergency.yaml file as well.
Change-Id: I154f7c16166e6ac6610c0ea02e5d59fa7baa25c0
If we match these explicit paths, don't allow the regex matches to
run. Otherwise, we might redirect "/http-bind" to "/" which doesn't
work.
Also, restore the default meet.conf to the upstream; we're not
intending to carry any local changes to the rootfs.
Change-Id: I119d8c223291d79bd5fe0977264dec4bae126280
The string previously expected in the docs.airshipit.org site is no
longer used there, so pick another which will get the
system-config-run-static job passing again.
Change-Id: I8bf0da25408412dc80ff8cb6d26c185234916941
New opendev.org CI mirrors for OVH regions. The old BHS1 mirror was
in the openstack.org domain, so is added new. There was an old GRA1
mirror in the opendev.org domain, so remote it and increment the
ordinal in its short hostname to avoid a collision in the inventory
cache.
This is being done to switch to un-billed flavors in this provider,
to simplify internal billing for their donation of resources.
Change-Id: I05770856b5704aa438ed6bc54ec42ba9efb5cd2a
Our zk config is a little too brittle. Let's just use the inventory
vars instead of detected network facts.
Change-Id: I288990edf587bc8394c9473388a858f46efb0691
The zuul_restart.yaml playbook expects to be able to load start.yaml and
stop.yaml files from each of the zuul service roles. Before this change
the zuul-executor role was missing this file. Add it so that the
zuul_restart.yaml playbook can run successfully.
Change-Id: I6573129170cbe7ac36a7c6b6f7ea05b29eb1fe5b
Many people put hyphens (-) and underscores (_) in their pad names,
and Jitsi-Meet seems to support them in its room names too, so add
them to our rewrite regex.
Change-Id: I819b8d56bf839cf743319e9cd823440c7d910001
We build our own docker images for several services, but weren't
triggering production test runs when the docker images are updated. Fix
this and force chagnes to dockerfiles, which produce new images, to
trigger production test runs of those services.
Change-Id: I18962663f168bbf6380e315d96b18751a46ceb58
We already run accessbot in project-config when the accessbot
script changes. We don't need to run it whenever any of the puppet
or other config on eavesdrop runs, not do we need to run it
hourly. Just run it nightly and on changes to the actual
accessbot config.
Change-Id: Idd47f7c96f677fd1e1c8da3be262a52a70646acd
Follow-on to addition for executors in
I0126f7c77d92deb91711f38a19384a9319955cf5 to keep the base roles focal
clean.
Change-Id: I40fdf1b2b7d012f4ce5d013528f4460d277e44d4
Our .zuul.yaml file has grown quite large. Try to make this more
manageable by splitting it into zuul.d/ directory with jobs organized by
function.
Change-Id: I0739eb1e2bc64dcacebf92e25503f67302f7c882
We noticed that our zuul scheduler was running out of disk and one of
the causes of this is we are pulling all of the wonderful new zuul
images and not pruning them. This happens because we were only pruning
when (re)starting services and we don't do that automatically with Zuul.
Address this by always pruning after pulling even if we don't restart
services. This should be safe because prune will leave the latest tagged
images as well as the running images.
This should keep our disk consumption down.
Change-Id: Ibdd22ac42d86781f1e87c3d11e05fd8f99677167
On our zuul-scheduler host the /root/.bup dir is extremely large. On
closer examination this appears to be due to large file indexes. Looking
at the host we've noticed that we are backing up the status.json backups
as well as job runtime files which can and do change frequently which
could lead to very large file indexes.
We don't actually need to back these up permanently so exclude them from
bup's list. the /var/lib/zuul/backup dir contains status.json backups
which are really only useful in the immediate time frame and the times
db is something we can live without if we lose it (we'll just build a
new one).
Change-Id: Id3029eec3a6478c496712876b9ec753029313efa
