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:
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):
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
6. see Description
6. stats to match reality and be aligned to each other
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 firstname.lastname@example.org
Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/25282 has been resolved.
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:
Steps were also reproduced on sat6.5 snap 20.
- package versions:
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):
"success_count"=>3} ... OK
In this case everything works as I expect.
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.