Bug 1052273 - [RFE] Remote system management
Summary: [RFE] Remote system management
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Remote Execution
Version: Nightly
Hardware: Unspecified
OS: Unspecified
Target Milestone: Unspecified
Assignee: Ivan Necas
QA Contact: jcallaha
Depends On: 1194493
Blocks: 1296726
TreeView+ depends on / blocked
Reported: 2014-01-13 14:44 UTC by Duncan Innes
Modified: 2020-04-15 14:06 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2016-07-27 09:08:44 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 1473223 0 None None None 2016-04-27 06:35:23 UTC
Red Hat Product Errata RHBA-2016:1501 0 normal SHIPPED_LIVE Red Hat Satellite 6.2 Capsule and Server 2016-07-27 12:28:58 UTC

Description Duncan Innes 2014-01-13 14:44:08 UTC
When the functionality for remote system management (scheduling tasks on client systems) is designed, could the following please be taken into account:

Current Satellite uses either regular rhnsd check-in or prompts clients to immediately check-in via osad.  There seems to be no middle ground.

For sites with thousands of Katello clients, it could be ruinous to schedule tasks to operate on all clients immediately.  It is acknowledged that some tasks will be required immediately, but thought should be given to allow a more relaxed schedule for other tasks.

Could the following scheduling scenarios please be considered for Katello (regardless of the date/time set for a task):

1) Select date/time for task to begin
2) Select scheduling method to be used for *this* task (Immediate/Regular)

Tasks scheduled on the Regular scheduling method would only be picked up on the once-every-4-hours rhnsd style check-in (configurable I know).

Tasks scheduled on the Immediate scheduling method would result in the clients being prompted to carry out tasks as soon as possible after the scheduled date/time.

I understand AMQP will possibly be used to arrange this.  Not sure how that affects things.

Comment 1 Duncan Innes 2014-01-13 14:59:15 UTC

Under the current Satellite regime, if clients are configured with Push-to-Client, all scheduled tasks are carried out via osad.  There is no option to allow a task to be picked up only on a regular rhnsd check-in.

On small estates, this is not an issue.

When estates are scaled up to thousands or tens of thousands of clients, there are implications to scheduling tasks across all clients.

1) On a highly (or completely) virtualised environment, loading on the virtual hosts could rise to alarm levels if complex tasks are scheduled immediately across all clients

2) Load on the central Katello/Satellite system/smart-proxies could rise to unacceptable levels 

It would be polite to the infrastructure if tasks could be jittered in a way that spreads the load.

Certain tasks may be required immediately, so any jittering should be user defineable on a task by task basis.  i.e. jitter=0 for urgent tasks, jitter=4 hours for tasks that I'm more relaxed about.

Examples of such tasks:

Urgent: A failure of my single (bad design I know) NTP server prompts me to build a temporary NTP server.  I'll want to push out a new config and restart NTP immediately.

Relaxed: IT Security require a report (RPM verify for example) from all my machines by tomorrow.  I'd like to schedule the task to start outside business hours, but be jittered by 4 hours to ensure no spike load hits the virtual hosts.



Comment 2 Bryan Kearney 2014-01-21 19:07:19 UTC
Moving to Sat6 to be tracked there. Upstream bugs are moving to redmine.

Comment 3 RHEL Program Management 2014-01-21 19:17:18 UTC
Since this issue was entered in Red Hat Bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

Comment 15 David O'Brien 2016-04-18 00:48:04 UTC
Reset docs contact <> daobrien

Comment 16 jcallaha 2016-06-16 18:28:56 UTC
Verified in Satellite 6.2 Beta Snap 15.2

This feature has been fully delivered in Satellite 6.2 in the form of the Remote Execution plugin.

Comment 18 errata-xmlrpc 2016-07-27 09:08:44 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.


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