Bug 1687784

Summary: foreman-rake tasks:cleanup combining specific TASK_SEARCH and STATES can delete unwanted tasks as well
Product: Red Hat Satellite Reporter: Pavel Moravec <pmoravec>
Component: Tasks PluginAssignee: Adam Ruzicka <aruzicka>
Status: CLOSED ERRATA QA Contact: Vladimír Sedmík <vsedmik>
Severity: high Docs Contact:
Priority: high    
Version: 6.4.2CC: andrew.schofield, aruzicka, egolov, inecas, ktordeur, vsedmik, zhunting
Target Milestone: 6.6.0Keywords: Triaged
Target Release: Unused   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: tfm-rubygem-foreman-tasks-0.15.2 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-10-22 19:50:13 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Pavel Moravec 2019-03-12 11:35:38 UTC
Description of problem:
TASK_SEARCH and STATES parameters in tasks cleanup should work in conjunction. However, when combining some values of TASK_SEARCH and STATES, also unexpected tasks are removed.

Example:

TASK_SEARCH='result = pending or result = error' STATES='paused,planning'

will remove pending/running tasks (i.e. monitor event and LOCE task).


Version-Release number of selected component (if applicable):
6.4.2


How reproducible:
100%


Steps to Reproduce:
1. Have running Satellite with all "usual" tasks planned or running (monitor event, LOCE, Pulp disk space etc.)
2. Check tasks cumulative stats:

sudo su - postgres -c "psql -d foreman -c 'select label,count(label),state,result from foreman_tasks_tasks where state <> '\''stopped'\'' group by label,state,result ORDER BY label;'"

3. Remove tasks that with pending or error result AND in paused or planning state:

foreman-rake foreman_tasks:cleanup TASK_SEARCH='result = pending or result = error' STATES='paused,planning' VERBOSE=true

4. Check tasks cumulative stats again:

sudo su - postgres -c "psql -d foreman -c 'select label,count(label),state,result from foreman_tasks_tasks where state <> '\''stopped'\'' group by label,state,result ORDER BY label;'"


Actual results:
2. shows expected:
                    label                    | count |   state   | result  
---------------------------------------------+-------+-----------+---------
 Actions::Candlepin::ListenOnCandlepinEvents |     1 | running   | pending
 Actions::Katello::EventQueue::Monitor       |     1 | running   | pending
 CreatePulpDiskSpaceNotifications            |     2 | scheduled | pending
 CreateRssNotifications                      |     2 | scheduled | pending
 SendExpireSoonNotifications                 |     2 | scheduled | pending
                                             |     0 | pending   | success
(6 rows)

BUT 4. shows nothing:
 label | count |  state  | result  
-------+-------+---------+---------
       |     0 | pending | success
(1 row)


Expected results:
both 2. and 4 to show same "default" tasks


Additional info:
Per aruzicka++, the problem seems in missing parenthesis in the underlying postgres query (if I got it right), where the above query is translated to:

result=pending OR (result=error AND state in (paused,planning))

instead of proper:

(result=pending OR result=error) AND (state in (paused,planning))


BUT this does not explain deletion of tasks

CreatePulpDiskSpaceNotifications            |     2 | scheduled | pending

?

Comment 3 Adam Ruzicka 2019-03-12 11:40:29 UTC
Created redmine issue http://projects.theforeman.org/issues/26310 from this bug

Comment 4 Bryan Kearney 2019-03-12 12:02:03 UTC
Upstream bug assigned to aruzicka

Comment 5 Bryan Kearney 2019-03-12 12:02:05 UTC
Upstream bug assigned to aruzicka

Comment 6 Bryan Kearney 2019-03-20 16:02:20 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/26310 has been resolved.

Comment 9 Bryan Kearney 2019-10-22 19:50:13 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2019:3172