The mariadb container is overriding these and we can race ansible
setting them back to root and the mariadb container starting up
resulting in a sad database.
Change-Id: Ib88f6aec83e73baf95a660165d13839f7baeed3d
We are currently re-chowning the running db directories back to root,
causing havoc for the db. Drop the explicit permissions to avoid
this.
Change-Id: I8d8ce5c62c660875d5c6eed54c686996576ec9df
We may see an archive with ".checkpoint" on the end, as described in
[1]; the short version is this that borg stamps this every 30 minutes
and may appear if a long backup is interrupted. Skip this when making
the list of archives to prune.
We noticed this on wiki-test; for clarity the list of archives looks
like
...
wiki-upgrade-test-filesystem-2021-02-16T02:56:09.checkpoint Tue, 2021-02-16 02:56:11 [c444a0765e5791f3f68f08624d1efd80bf8a3ebc96bb225f08e4013befa2b460]
wiki-upgrade-test-filesystem-2021-02-16T17:45:04 Tue, 2021-02-16 17:45:06 [b901b55ac3bf9abecba024caebad5ba7cd1a966e3f00b366f6cff45feba7bdff]
wiki-upgrade-test-mysql-2021-02-16T18:35:09 Tue, 2021-02-16 18:35:11 [1d38cd3b4b1b3927b543e4ccc6c794cd3a513a70979ff025bbf303e1fe5e490f]
wiki-upgrade-test-filesystem-2021-02-17T17:45:05 Wed, 2021-02-17 17:45:07 [f665e275c0014a21b82efaece5d36525a4ce6cb423253d5bd0b1323b230fa53a]
...
[1] https://borgbackup.readthedocs.io/en/stable/faq.html#if-a-backup-stops-mid-way-does-the-already-backed-up-data-stay-there
Change-Id: Ia33f46305ef8f541efb7c7150d4bb2e977b01d46
We previously set the limit to 70200M on a ~98GB filesystem.
Unfortunately we are able to jump from the ~70GB limit to a full
filesystem before htcachclean happens to run again. Reduce the limit to
60000M to give us more headroom and hopefully avoid filling the fs
between cache clean runs.
Change-Id: I8aa45eb0c396b54dbb3ec84e5ba8fd4ec7da9e27
Last week when we were attempting to only update the subset of projects
that were renamed in gitea we accidentally updated all projects. The
good news is this didn't take significant amounts of time (just a few
minutes).
We should be able to enforce the metadata for all projects given the
cost is now much lower than it was in the past. This will keep things up
to date after renames but also generally if projects update descriptions
or bug tracking locations.
Change-Id: Ief2bb1eb2b11a13fafbe52650317d54d6a0fc824
This reverts commit a39a939e0352741d0b2c43e96e660f52eac22245.
Turns out that ansible module args don't get typed the way we expect
them. This means having a Boolean or List type argument just ends up in
confusion and always_update being truthy every which way. Revert until
we can fix this properly.
Change-Id: I596fe6883098ba636b1cad5196d1fdd76ff19076
Setting the gitea_always_update var for the gitea-git-repos role to
a list will filter metadata updates to only the project names
included in the supplied list. False and True still have their prior
meanings of do no metadata updates or force metadata updates for
every project we host.
Add testing for this, and also actually test that the rename
playbook renamed something.
Get rid of the git clone in the playbook since it's no longer
relevant to how we run things anyway, we'll instead want to rely on
the Zuul supplied projects.yaml path.
Change-Id: Id8238b232caffc242c6bda9fe39eb7e65fe5e059
This removes the old config to choose the old change screen by default
as everything is polygerrit now.
We remove the pre plugin melody config as melody now ships as a plugin
and has separate configuration.
We remove old theming information as that is supplied via external files
now.
We remove anonymous git download config because we don't set
gerrit.canonicalGitUrl which is required for this to work. We don't set
that because we don't have a git:// server anymore.
Bump the lucene thread count from 4 to 8 as we have more cores on the
system we run on.
Finally add some comments to help make sense of config that is left in
place.
Change-Id: Ie0b48e544191839067e66647d2ea32f74ce19ed3
Having two groups here was confusing. We seem to use the review group
for most ansible stuff so we prefer that one. We move contents of the
gerrit group_vars into the review group_vars and then clean up the use
of the old group vars file.
Change-Id: I7fa7467f703f5cec075e8e60472868c60ac031f7
Previously we had set up the test gerrit instance to use the same
hostname as production: review02.opendev.org. This causes some confusion
as we have to override settings specifically for testing like a reduced
heap size, but then also copy settings from the prod host vars as we
override the host vars entirely. Using a new hostname allows us to use a
different set of host vars with unique values reducing confusion.
Change-Id: I4b95bbe1bde29228164a66f2d3b648062423e294
The gerrit config diff after the 3.3 ugprade [1] seems to remove some
quotes. We also quote the bug URL, because it seems to think the
trailing # is a comment now.
[1] https://etherpad.opendev.org/p/gerrit-upgrade-3.3
Change-Id: I3ca0ec925a0e6da33a1cbe2333c118b1baa7257c
While under development, the subdomain for the PTG site was
originally written as ptgbot.opendev.org and this is what was
communicated to event organizers. Mass communications subsequently
went out including this for URLs to the service. In order to make
the content from those announcements viable, add the additional name
to our configuration so we can redirect from it to the name we
eventually settled on.
While we're adjusting vhost metadata, make the ServerAdmin
directives between the HTTP and HTTPS vhosts for the service
consistent.
Change-Id: I726069f83b792fa31d92b759adc5c1214ca087fa
In order to use Rewrite* directives, mod_rewrite must be activated
in the vhost via RewriteEngine.
Change-Id: I495ee5e9fd3b1d489122d6e282d3a91d1035c126
The default channel name in the ptgbot role defaults did not
correctly specify a starting hash which it requires, but also the
test jobs seem to need it set in the eavesdrop group vars specific
to testing.
Change-Id: I16cdeac4f7af50e2cac36c80d78f3a87f482e4aa
This bumps the gerrit image up to our 3.3 image. Followup changes will
shift upgrade testing to test 3.3 to 3.4 upgrades, clean up no longer
needed 3.2 images, and start building 3.4 images.
Change-Id: Id0f544846946d4c50737a54ceb909a0a686a594e
Set the channel we want ptgbot joining in production with a group
var, like we do for statusbot's channel list. Correct the password
var name to match what's used in the template for production (and
matches the override set in our private hostvars on the bastion).
Clean up the unnecessary auth nicks list which was copied from the
statusbot config but is entirely unused. Also get rid of some
unnecessary empty lines in the defaults as they really don't make
the file any more readable.
Change-Id: Id026b89d642eae13feba374e4f3ec610b543e530
We set the letsencrypt_self_generate_tokens value to True in testing
which means the variable is valid and exists in testing. However, in
production this variable isn't set and doesn't ahve a default so we get:
The task includes an option with an undefined variable. The error was:
'letsencrypt_self_generate_tokens' is undefined
Fix this by setting the default value for this var to False. Also, add
it to the README of letsencrypt-request-certs as this is where it is
primarily used.
Change-Id: I862df6ea3ff7f3a1df2a088b04d230bb618aaa85
The dependent change exports the ptgbot website on port 8000 in the
container. Proxy this through apache.
Depends-On: https://review.opendev.org/c/openstack/ptgbot/+/812417
Change-Id: Idf9e9f5ffad981427d24a3476c0c1f244721d917
