migrated notes from infra/hosts
motd changes; excluding CSI infos
removed csi_* vars from group_vars; converted csi_purpose & csi_relationship into notes
fixed merge conflicts
minor changes; var
updating YAMLs & playbooks
udpated YAMLs & playbooks again
updated correctly; buildhw.yml
fixing merge conflicts
dest added in motd.yml
ansible-lint requires that variables for roles are prefixed with the
name of the role. This commit prefixes the variables for the
rabbit/user role with user_ as required by ansible-lint
Signed-off-by: Ryan Lerch <rlerch@redhat.com>
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>
We defined all these in an inventory variables, but also listed
the same keys explicitly in the queue configs in the group
playbook. Let's not do that.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
As with fedora_nightlies, I'm offloading this from my personal
domain. Happily this one doesn't need a consumer, it just runs
hourly. Again we just dump the output in openQA's public dir.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is to get it off my personal domain (finally). Having it on
the openQA server is still a bit of a hack, but at least it's
under fedoraproject.org now and off my hands. This is a consumer
that runs a static site generator which produces a page full of
links to the most recent nightly compose images, basically.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
In phx2 we used a vpn to openqa01 and all the proxies reached it on
that. In IAD2 that network is more isolated and cannot connect to the
vpn, so we just access it from the IAD2 proxies. If this turns out to be
a problem later we can adjust the RHIT firewall, re-enable vpn and
re-add it to all the proxies.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
Since we no longer have any machines in phx2, I have tried to remove
them from ansible. Note that there are still some places where we need
to remove them still: nagios, dhcp, named were not touched, and in cases
where it wasn't pretty clear what a conditional was doing I left it to
be cleaned up later.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
We don't really want/need these roles in IAD yet at all, but the
way the plays are right now we're sort of required to do them.
This skips the queues and roles if a key variable isn't defined,
which should let us skip these cleanly for the IAD deployment.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
autocloud is dead. We don't need this any more. I'll decommission
the bits from the hosts manually.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
I just wrote an additional consumer class in relvalconsumer that
should update the new AMI info pages for composes whenever a new
AMI is published; this should enable that new consumer.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The default was changed from 01 to 03, and I'm not sure why, and
this playbook fails where it used to succeed. So see if changing
this helps.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Using the mechanism I just invented...we need to be able to
publish to queues prefixed with 'openqa' and 'ci', on both prod
and stg.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
OK, now this is the *fourth* time I've done this, maybe I'll
screw it up a bit less this time? Maybe?
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This was kinda...a mess. I had just dumped the queue creation
in the staging NFS client play for some reason, and it still
had 'when' conditionals from when I only wanted the messaging
stuff to happen on staging. This cleans all that up and creates
separate plays for the queue creation and NFS client stuff.
The plays should also be in the right *order* now, so we get
the NFS mounts created and the AMQP queues set up *before* we
run the roles.
The way this was set up was intentional. For staging rabbitmq_
server is already set as the staging broker in openqa_stg group
vars; the setting here was an intentional override for it to use
the prod broker just for the scheduler queue. It has to do that
because it schedules jobs in response to composes and updates;
composes and updates almost never happen in the staging env, so
if we had the openQA staging scheduler listening to the staging
broker it'd almost never schedule any jobs. It has to listen
to the production broker and schedule jobs when real composes
and updates happen.
Still, perhaps the group var setting isn't working here, so
let's keep the explicit setting of the staging server here for
the other two queues and see if that helps that case.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
