Bug 2249736
| Summary: | "Actions::Katello::Applicability::Hosts::BulkGenerate" tasks are processed in the default queue instead of hosts_queue causing congestion. | ||
|---|---|---|---|
| Product: | Red Hat Satellite | Reporter: | Hao Chang Yu <hyu> |
| Component: | Hosts - Content | Assignee: | Hao Chang Yu <hyu> |
| Status: | CLOSED ERRATA | QA Contact: | visawant |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.13.6 | CC: | aruzicka, iballou, rlavi, visawant, zhunting |
| Target Milestone: | 6.15.0 | Keywords: | Patch, Performance, Triaged |
| Target Release: | Unused | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2024-04-23 17:15:39 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
Hao Chang Yu
2023-11-15 04:38:01 UTC
Since we moved to sidekiq, the queues are defined externally in workers' configurations. We can manipulate ForemanTasks.dynflow.config.queues all we want, but it should have no effect whatsoever. (In reply to Adam Ruzicka from comment #2) > Since we moved to sidekiq, the queues are defined externally in workers' > configurations. We can manipulate ForemanTasks.dynflow.config.queues all we > want, but it should have no effect whatsoever. If you are saying passing the “-C” in the sidekiq command, it is already configure like that in the Satellite but it is not working. Based on my test, it is indeed working after “ForemanTasks.dynflow.config.queues.add” is called so not why it has effect here. I see it now. Apparently dynflow needs to know that the queue exists, which the patch you suggested seems to do. The pool_size part is is the bit that gets ignored since the move to sidekiq. (In reply to Adam Ruzicka from comment #4) > I see it now. Apparently dynflow needs to know that the queue exists, which > the patch you suggested seems to do. The pool_size part is is the bit that > gets ignored since the move to sidekiq. Great! That will make the fix much easier. We will just need to remove the setting table check and pass any values for the pool_size. (In reply to Hao Chang Yu from comment #5) > (In reply to Adam Ruzicka from comment #4) > > I see it now. Apparently dynflow needs to know that the queue exists, which > > the patch you suggested seems to do. The pool_size part is is the bit that > > gets ignored since the move to sidekiq. > > Great! That will make the fix much easier. We will just need to remove the > setting table check and pass any values for the pool_size. Great! Passing without pool size worked. ~~~ ForemanTasks.dynflow.config.queues.add(HOST_TASKS_QUEUE) ~~~ Moving this bug to POST for triage into Satellite since the upstream issue https://projects.theforeman.org/issues/36921 has been resolved. 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 |