so, this was working before somehow, but it was pretty clearly
wrong. We were using queues owned by openqa.stg on the prod
rabbitmq instance for the cases where the openQA "stg" consumers
need to listen to prod queues. This can only have been working
with an openqa.stg user on prod, which seems wrong. Instead,
these three consumers should do it the way the relval and
relvalami consumers do - use a queue owned by the "openqa" user,
but with a suffix so they have a different queue from the actual
prod queue. The upshot of this is that in the configs, we should
go from:
amqp_url = "amqps://openqa:@rabbitmq.fedoraproject.org/%2Fpubsub"
...
queue = "openqa.stg_scheduler"
- which is weird and I have no idea how it ever worked - to:
amqp_url = "amqps://openqa:@rabbitmq.fedoraproject.org/%2Fpubsub"
...
queue = "openqa_scheduler_stg"
- which seems much more sensible.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is triggered by
https://pagure.io/fedora-infrastructure/issue/11375 , but the
changes are rather extensive. Unfortunately, some of the
relevant files got messed up by the alphabetical sort thing that
got run on several group variable files a while ago, so that
confuses the diff a bit - I had to unwind those changes to make
the files readable again in order to make these changes.
Ultimately the goal here is to make the config more consistent
and more functional - the variables used and their names should
be more consistently related to what they're actually *for*,
which I didn't entirely understand when setting this up. So
we have variables for the username being used in each case and
we use that variable where we're referring to the username, for
instance. This should also make the whole thing about the cases
where listeners on the openQA stg/lab instance need to listen
to prod messages clearer, too. It also makes the user creation
clearer by doing it explicitly, just once per user, instead of
haphazardly doing it implicitly through the queue definitions.
And finally it should also actually fix 11375, by giving the
appropriate write permissions to each user.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
db-koji01 is our only postgresql 15 install so far, but split out the
config from the 12 one we are using on RHEL8 to avoid making changes
there.
Also, lets try tweaking things:
- I am bumping cpus up to 88
- Tweak max workers/etc
- Try a higher i/o level since this db server is running on a virthost
with ssds.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
The 2023-05 git builds look good on stg, and are now in u-t, so
drop the scratch repos on stg and enable u-t on prod so we get
the builds from u-t everywhere.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We moved to timescaledb over on db-datanommer02 a while back, so this vm
it just sitting there doing nothing. ;)
So, lets drop it off and save some resources.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
This space was in a networking cage thats going away and all the
machines there are old and out of warentee.
This space was intended for disaster recovery purposes.
For that now we have a internal vm that can access our mirrored netapp
storage, so we can sync anything off it we need to when iad2 is down.
I will be resetting up a batcave13 in another datacenter to allow us a
backup ansible/dns control host. bastion13/ns13/proxy13 will likely just
go away forever. download-rdu01 should be replaced by the new
download-cc-rdu01 once we have the new hardware in place for that.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
We need this to try and relay in emails.
It turns out to be bordering on impossible to do this sanely with our
current setup, so make a fedora vm that lets us use saslauthdb to have a
specific (small) list of users that can authenticate and relay emails
via bastion and out. We can't do this on rhel, because they don't build
the saslauthdb backend. We can't use any of the other backends because
they either don't work or would allow any fedora user to relay, which we
do not want.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
