Right now we only exclude the builders on 10.3.169 from using the
registry cdn (ie, the x86_86 builders), but we also make aarch64
containers/images and we should exclude it too ( 10.3.170.x ).
This might fix a weird compose failure we have been getting on
aarch64 ostree installer images.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
db-datanommer01 is still around, but won't be for much longer.
We switched to timescaledb on db-datanommer02.
So, move monitor-dashboard over.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
This vm is to allow the creation of reports about contibutor numbers
from datanommer db. It should be short lived. Once the reports are
developed, they can be moved to openshift or some other place.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
We don't have any more fedora instances that are f34 or before (with
xinetd was dropped) and now we have some rhel9 hosts that don't have
xinetd.
So, adjust the tasks to always use the systemd service on fedora and
rhel9 and use xinetd on rhel7/8.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
The last time they were re-installed they defaulted to 1500 and it's
causing some problems for some of them at least (01-08 for sure).
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
First we need to pipe stderr into the grep to filter out the timescaledb
warnings. So, |& does that.
Then, there's no reason to backup the staging database. Disable that.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
db-datanommer02 uses timescaledb. When you do a pg_dump there's warnings
due to this, but according to upstream they are all completely harmless.
So, to avoid an email to everyone every day, lets just try and supress
these, but yet hopefully not supress real errors if they every occur.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
The messaging bridge queues have very specific setup, we can't use the
rabbit/queue role because it binds all queues to both amq.topic and
zmq.topic and we don't wan't that for the bridges.
This reverts commit 649eec104d.
The datanommer_ro user was created in the task, but never got privilege to read
from datanommer2 db. This commit is fixing that.
Signed-off-by: Michal Konečný <mkonecny@redhat.com>
We switched a while ago to db-datanommer02 which is a timescaledb from
the old db-datanommer01. However, backups were not working right until
recently. Now that they are, switch backups to backup 02 instead of 01
and also copy that one public. This should allow us to retire
db-datanommer01 entirely now.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
