From dc387dad55826d491977c8292fe6b8e7b89c762e Mon Sep 17 00:00:00 2001 From: Adam Williamson Date: Fri, 14 Jun 2019 08:33:48 -0700 Subject: [PATCH] openqa: partially revert @jcline's broker config change d76e5206 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 --- playbooks/groups/openqa.yml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/playbooks/groups/openqa.yml b/playbooks/groups/openqa.yml index 3f259d6d19..a167b303e8 100644 --- a/playbooks/groups/openqa.yml +++ b/playbooks/groups/openqa.yml @@ -76,7 +76,9 @@ - "org.fedoraproject.prod.bodhi.update.request.testing" - "org.fedoraproject.prod.bodhi.update.edit" vars: - rabbitmq_server: "rabbitmq01.stg.phx2.fedoraproject.org" + # yes, even the staging scheduler listens to production, it + # has to or else it wouldn't schedule any jobs + rabbitmq_server: "rabbitmq01.phx2.fedoraproject.org" tags: ['rabbit'] when: deployment_type == "stg" - role: rabbit/queue