Bug 1422943

Alex, can you reproduce this please.  Sounds like a distributed configuration problem.

Yes.
Are you seeing a different behavior in your test environment?

Today I deployed a fresh appliance, a single appliance.  Using this as a fresh test environment and disabling the reporting role, I see the report stay queued indefinitely.

Unlike the original scenario scenario, there are no other workers to pick it up, but it still allowed me to queue it.  Enabling the reporting role again, the task was picked up and executed.

I'm not sure what specific output to share with you to assist, but here are the tasks to show the stalled report, and then I re-enabled the reporting role, and the report runs.  finally, the queue clears.


vmdb_production=# select id,priority,method_name,state,queue_name,class_name,zone,role,msg_timeout from miq_queue;
       id       | priority |      method_name      | state | queue_name | class_name |  zone   | role | msg_timeout 
----------------+----------+-----------------------+-------+------------+------------+---------+------+-------------
 10000000003106 |      100 | _async_generate_table | ready | reporting  | MiqReport  | default |      |        3600
(1 row)

vmdb_production=# select id,priority,method_name,state,queue_name,class_name,zone,role,msg_timeout from miq_queue;
       id       | priority | method_name | state | queue_name |     class_name     |  zone   |    role    | msg_timeout 
----------------+----------+-------------+-------+------------+--------------------+---------+------------+-------------
 10000000003183 |       20 | dispatch    | ready | generic    | JobProxyDispatcher | default | smartstate |         600
(1 row)

vmdb_production=# select id,priority,method_name,state,queue_name,class_name,zone,role,msg_timeout from miq_queue;
 id | priority | method_name | state | queue_name | class_name | zone | role | msg_timeout 
----+----------+-------------+-------+------------+------------+------+------+-------------
(0 rows)

In the original environment, the software was updated from 4.1 to 4.2 (Version 5.7.1.3.20170221135006_818f133)

Within the UI zone (2 appliances), one appliance had the "reporting" role, and the other did not.  From the one that did not have the role, a report was submitted, and was picked up and processed by the one that had the role enabled.  (success!)

From the (DB zone), there is only the single DB appliance.  It has only the DB role, and the UI/Web roles enabled.  I submitted a job from there, and it remained queued indefinitely.

I enabled the "scheduler" role on the DB, and the queued job did not process.  I submitted a new reporting job, and it also remained queued indefinitely.

I enabled the "notifier" role on the DB, and the queued jobs did not process.  I submitted a new reporting job, and it also remained queued indefinitely.

I disabled "scheduler" and "notifier" roles and enabled "reporting", and all 3 jobs were processed.

So, it appears that the "reporting" role is all that's really needed (other than the UI role) to log in to the webUI and submit/run a report successfully.  Workers with the role enabled within that zone will pick it up and run it, even if the one you submit it from doesn't have the role.  But jobs submitted in zones where no workers have the role will queue indefinitely.

works as designed