This ditches the ability to choose between fedora-messaging and
fedmsg and always uses fedora-messaging; with this, we'll switch
the prod instance to fedora-messaging also (fingers crossed).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
I cargo-culted this from the Bodhi config but it's a special
Bodhi thing we don't have, so drop it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We had this for fedmsgs and it's pretty important, so let's try
and do it for fedora-messaging. The role has a generic setup,
infra-appropriate values are set in the group vars.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Remove ppc64-test instance in cloud.
Remove template conditionals that no longer apply since ppc64 is gone.
Remove buildvm-ppc64 instances.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
I thought just having it WantedBy remote-fs.target should be
enough, but in fact this mount often fails on boot, and I forget
to check all the worker boxes until a bunch of tests fail and
everyone is sad. Let's try After=network-online.target and see
if that helps.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
jcline said it'd be nice for consumers to provide more info
about themselves, so here's some more info!
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Now I've built the whole thing and it works, I feel like this
is a cleaner design: we use a lot more role variables in the
messaging config files, set defaults for them that are
appropriate for non-infra use, and set the correct values for
the infra servers in the group vars. Let's just hope I got it
all right...
Signed-off-by: Adam Williamson <awilliam@redhat.com>
There are several variables we set to the same value for openQA
prod and staging servers. Instead of duplicating these between
the openqa and openqa_stg groups, let's invent an openqa_common
and put them in there, and add both servers to it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
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>
