Bug 1721679 - [RFE] Handle host-related tasks in separate queue to avoid conflicts with user-related actions [NEEDINFO]
Summary: [RFE] Handle host-related tasks in separate queue to avoid conflicts with use...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Hosts - Content
Version: 6.5.0
Hardware: All
OS: Linux
high
high
Target Milestone: 6.7.0
Assignee: Adam Ruzicka
QA Contact: Stephen Wadeley
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-06-18 21:03 UTC by Dylan Gross
Modified: 2020-04-14 13:25 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1814424 (view as bug list)
Environment:
Last Closed: 2020-04-14 13:24:36 UTC
Target Upstream Version:
aruzicka: needinfo? (mmccune)


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Foreman Issue Tracker 27248 High Closed Handle host-related tasks in separate queue to avoid conflicts with user-related actions 2020-11-20 15:36:15 UTC
Red Hat Bugzilla 1386283 high CLOSED [RFE] Job invocations should have a priority 2020-10-14 00:28:05 UTC
Red Hat Product Errata RHSA-2020:1454 None None None 2020-04-14 13:24:59 UTC

Description Dylan Gross 2019-06-18 21:03:47 UTC
1. Proposed title of this feature request

  [RFE] Create a tunable dynflow that allows for custom prioritization of tasks

3. What is the nature and description of the request?

  Occasionally on large satellites, certain actions in the environment may cause an influx of tasks that can starve out other more timely tasks, or tasks that have a higher business importance.   

For example, a change to repos across the environment may cause a high number of  tasks to regenerate errata applicability, which may interfere with something more user-driven like a Host Creation task from provisioning, or a one-time task like a host registration.

  Customer would like a way to prioritize certain tasks so that they can jump ahead of a potential wave of other less important tasks.


4. Why does the customer need this? (List the business requirements here)

   Certain actions in the environment like building a new host or registering it, or promoting new content have a higher expectation of availability, while others like package profile uploads can be done whenever.   Allowing for customer customization could help solve business priorities first.

5. How would the customer like to achieve this? (List the functional requirements here)

  The implementation is fairly open for discussion, but it is envisioned as a giving priority to certain task types over others.   (a "nice" system for foreman tasks may be a good analogy)

6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.

   Customer would prioritize certain task types, and then when an overwhelming number of tasks of a lower priority were encountered, the high-priority business task would succeed without having to wait for the numerous less important tasks.

7. Is there already an existing RFE upstream or in Red Hat Bugzilla?

  No.    There are BZs for improving the queue (BZ#1609371), but this RFE is asking for more of a user control over customization of priority.

8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)?

  No

9. Is the sales team involved in this request and do they have any additional input?

  No

10. List any affected packages or components.

11. Would the customer be able to assist in testing this functionality if implemented?

Comment 5 Ivan Necas 2019-06-21 07:49:41 UTC
Rather than with prioritization. it should be possible to use separate queue for host-related tasks to not infer with those triggered by users, similarly as we did for remote execution jobs https://bugzilla.redhat.com/show_bug.cgi?id=1386283

Comment 9 Ivan Necas 2019-07-08 15:15:44 UTC
I'm updating the summary to better cover the actions we are currently taking to address the core issue describe in the summary.

To prevent the user-related actions to be highly influenced by the hosts-related tasks (such as errata applicability calculations), the work for the hosts should be put on dedicated queue with independent set of worker threads to process, so if the host-workers get starved, the non-host work could still flow.

Comment 10 Ivan Necas 2019-07-08 15:17:18 UTC
Created redmine issue https://projects.theforeman.org/issues/27248 from this bug

Comment 11 Bryan Kearney 2019-07-08 16:06:55 UTC
Upstream bug assigned to inecas@redhat.com

Comment 12 Bryan Kearney 2019-07-08 16:06:57 UTC
Upstream bug assigned to inecas@redhat.com

Comment 14 Bryan Kearney 2019-08-14 08:06:21 UTC
Upstream bug assigned to aruzicka@redhat.com

Comment 15 Bryan Kearney 2019-08-14 08:06:23 UTC
Upstream bug assigned to aruzicka@redhat.com

Comment 16 Bryan Kearney 2019-08-14 16:06:38 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/27248 has been resolved.

Comment 30 errata-xmlrpc 2020-04-14 13:24:36 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-2020:1454


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