nirik and I went around and around a bit today and ended up back
where we started, but with a clearer understanding of where that
this. This explains it a bit better, and makes what's actually
going on in various places clearer with the use of appropriate
shared variables. This should not actually *change* anything at
all when deployed.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
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>
Turns out we never completed it's migration to fedora-messaging, so we
need to re-enable fedmsg for now until we do.
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>
This commit makes the coreos-cincinnati setup look similar to the
other CoreOS/OSTree apps that we own. Notable changes:
- We are still building via commit, we only track a single commit
and not a separate deploy/build one.
- We are now just outputting to a coreos-cincinnati-img:latest
imagestream tag.
- We are now using a fedora:38 imagestream tag as the from: in our
build and triggering new builds based on imagestream updates,
which means we'll get security updates more regularly.
- A bunch of quoting (") in yaml files was removed as it clouded the
diffs between this app and other apps.
- Some minor diffs between playbooks and other files were removed.
As part of an effort to make coreos-cincinnati look like the rest
of the CoreOS Apps we'll move all files into the templates dir
(because even if they aren't templatized they still work there)
and rename `buildconfig-stub.yml` to `buildconfig.yml`.
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>
