Bug 1641266 - Wrong counts of success/fail/pending tasks on Bulk actions
Summary: Wrong counts of success/fail/pending tasks on Bulk actions
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Tasks Plugin
Version: 6.4
Hardware: x86_64
OS: Linux
medium
medium vote
Target Milestone: Released
Assignee: Adam Ruzicka
QA Contact: tstrych
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-10-20 17:50 UTC by Pavel Moravec
Modified: 2019-10-07 17:13 UTC (History)
7 users (show)

Fixed In Version: tfm-rubygem-dynflow-1.1.5,tfm-rubygem-foreman-tasks-0.14.4
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-05-14 12:38:16 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2019:1222 None None None 2019-05-14 12:38:25 UTC
Foreman Issue Tracker 25282 None None None 2018-10-23 10:02:59 UTC
Red Hat Knowledge Base (Solution) 4036601 Troubleshoot None Duplicated failed Capsule sync tasks after CV publish/promotion 2019-04-04 08:20:10 UTC

Description Pavel Moravec 2018-10-20 17:50:05 UTC
Description of problem:
(this was first seen in 6.3.4 but reproduced on 6.4 as well)

Running a bulk action, I get very contradicting stats about overall # tasks, successful/fail/pending/..

E.g. when I run auto-attach against 5 systems where two of them were deleted meantime, I see:
- parent task shows "5 task(s), 3 success, 4 fail"
- sub tasks show 4 success and 4 fail
- dynflow console of the parent task shows:
planned_count: 4
cancelled_count: 0
total_count: 5
failed_count: 4
pending_count: 1
success_count: 3

The failed tasks are two per each of 2 deleted system. Pending count might be consequence of that disbalance, but I already saw 10k total count, 0 failed, 9900 success and 100 pending (while there was _no_ pending, really).


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


How reproducible:
100%


Steps to Reproduce:
(I expect the problem is more generic but providing a particular reproducer I noticed at customer and by myself)
1. Have 5 Content Hosts
2. In WebUI, click to Content Hosts -> select all 5 of them -> Select Action -> Manage Subscriptions
3. Exactly now, unregister 2 from the Content Hosts
4. Now click to Auto-Attach button to trigger the bulk task.
5. wait till the task completes
6. check all possible stats about the bulk action


Actual results:
6. see Description


Expected results:
6. stats to match reality and be aligned to each other


Additional info:

Comment 1 Adam Ruzicka 2018-10-23 10:02:58 UTC
Created redmine issue http://projects.theforeman.org/issues/25282 from this bug

Comment 2 Adam Ruzicka 2018-10-23 10:05:45 UTC
I didn't try to reproduce this, but I can see how this might be happening.

Comment 4 pm-sat@redhat.com 2018-10-23 12:07:52 UTC
Upstream bug assigned to aruzicka@redhat.com

Comment 5 pm-sat@redhat.com 2018-10-23 12:07:55 UTC
Upstream bug assigned to aruzicka@redhat.com

Comment 8 pm-sat@redhat.com 2018-12-07 15:08:22 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/25282 has been resolved.

Comment 12 tstrych 2019-03-21 17:34:44 UTC
Hi, 
Steps were reproduced with 5 content hosts. Exactly same result as in comment #1. 
To be able register content hosts manifest and activation key were created. 
Content host machines were pure 7.6 RHEL.

Using Satellite 6.4.2. 
- package versions:
  tfm-rubygem-dynflow-1.0.5.5-1
  tfm-rubygem-foreman-tasks-0.13.4.3-1

Steps were also reproduced on sat6.5 snap 20.
- package versions:
  tfm-rubygem-dynflow-1.1.6-1
  tfm-rubygem-foreman-tasks-0.14.4.4-2

Results with 5 content hosts on sat 6.5:
- parent task shows "5 task(s), 3 success, 2 fail" ... OK
- sub tasks shows "5 task(s), 3 success, 2 fail" ... OK
- raw output (last tab): 
  {"planned_count"=>5,
   "cancelled_count"=>0,
   "total_count"=>5,
   "failed_count"=>2,
   "pending_count"=>0,
   "success_count"=>3} ... OK 

In this case everything works as I expect. 

Verified.

Comment 14 Pavel Moravec 2019-04-04 13:03:17 UTC
Alternative reproducer (also for testing):

- have 2 Capsules assigned to Dev Lifecycle environment
- switch down one Capsule
- promote some CV to Dev LE
- that will trigger a BulkAction task to sync the new content to Capsules
- this task has _three_ sub plans / three individual CapsuleSync tasks will be triggered - two of them for the shutdown Capsule

Comment 18 errata-xmlrpc 2019-05-14 12:38:16 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:1222


Note You need to log in before you can comment on or make changes to this bug.