Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
The json parse error should be fixed by [1], I would expect 6.11 to be free from this bug, although I can't say for certain as I have not managed to reproduce it myself.
[1] - https://github.com/ansible/ansible-runner/pull/638
In one of the case of satellite 6.11, user has 3 sidekiq workers and each of them have the exact same default configuration, causing same issue.
Upon following solution, manual changes made inside /etc/foreman/dynflow/worker-*.yml files gets overwritten with every installer run ( which is expected ).
To resolve this, executing installer option i.e. <--foreman-dynflow-manage-services false> will unmanage dynflow configuration and allow manual modifications of dynflow workers to remain intact. But It's not an acceptable solution for the end-user
User rather would like to be able to control the remote_execution queue assignment for individual workers with other method, instead of manually updating the worker configurations.
Copying from BZ https://bugzilla.redhat.com/show_bug.cgi?id=2135790 that is closed as duplicated.
The issue on Satellite version 6.11 is not only the the undefined method or nilclass, but even worser that it has also tasks of the job in Pending state that cannot be cleaned up by a regular user in the UI.
Job execution with concurrency set broken with nilclass at 100 servers out of 116 if batch size >= 100 is having all servers > 100 in a pending task state and the job is hangs/fails.
How reproducible:
Always.
Steps to Reproduce:
Job details for reproducer:
- Type: SSH Command
- Query '*' (make sure > 100 servers are there)
- Command: 'date'
- Concurrency: 30
Actual results:
Job on ~120 servers with concurrency 30 and the following Capsule batch sizes:
- 50: ok
- 99; ok
- 100: FAIL - Pending tasks without progress
- 101: FAIL - Pending tasks without progress
- 150: FAIL - Pending tasks without progress
Expected results:
It should not fail
Additional info:
Issue related to 'Concurrency level limited to: 30 tasks at a time'.
If do not set the concurrency level it successfully processes all ~116 servers.
If set the concurrency to 30 tasks then it exactly hangs/fails again at ~100
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 (Important: Satellite 6.15.0 release), 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-2024:2010