Hide Forgot
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:
Created redmine issue http://projects.theforeman.org/issues/25282 from this bug
I didn't try to reproduce this, but I can see how this might be happening.
Upstream bug assigned to aruzicka@redhat.com
Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/25282 has been resolved.
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.
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
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