Bug 190153 - Push to client not flexible
Push to client not flexible
Status: CLOSED DUPLICATE of bug 193268
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Server (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Todd Sanders
Red Hat Satellite QA List
: FutureFeature, Reopened, Triaged
Depends On:
Blocks: 471262
  Show dependency treegraph
Reported: 2006-04-28 04:26 EDT by Duncan Innes
Modified: 2009-02-26 04:14 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-02-11 15:06:05 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Duncan Innes 2006-04-28 04:26:34 EDT
Description of problem: When push to client is configured, updates to that
client can no longer go via the next scheduled check-in

Version-Release number of selected component (if applicable): 4.0.6

How reproducible: Every time

Steps to Reproduce:
1. Configure a client for push-to-client from Satellite
2. Schedule some updates to the client
Actual results:
All updates are "sent" immediately via the push-to-client mechanism

Expected results:
Would like to be able to send updates via the standard rhn_check checkin
schedule unless I *REALLY* need the update pushed.

Additional info:
Client of mine is running large numbers of RHEL 4 WS in stores all round the
country.  Can't afford to send updates during the day, so rhn_check will only be
run once a day by the end-of-day script.  This will be the normal mechanism for
sending updates & new packages to the stores.

If there is an emergency situation that requires updates to go out immediately,
then we'd like the option to use the push-to-cliebt.

The default sending mechanism, however, should be the next scheduled check-in by
the client.
Comment 2 Bret McMillan 2006-09-05 13:48:35 EDT
What the osad & osa-dispatcher do are merely alert the client that something has
been scheduled.  The clients will check in, as they do periodically anyway, but
if the time is earlier than the "earliest action" value defined for the
scheduled action, nothing should happen.

As this behavior has not been reported, I'm going to close this bug.  If you're
seeing different behavior, please reopen the bug.
Comment 3 Duncan Innes 2006-09-06 11:39:28 EDT
I guess what I'm asking for is an enhancement rather than a bug - but do I not
put those in here too?  Or should I just ask my sales rep so they can forget it?

Anyway - enough sarcasm.

I recently worked for a client deploying a large Red Hat base; 700 Workstation
licenses and 4000 Desktop.

They were planning to run WS licenses for their store servers and I think
Desktop for everything else out in the field.

They were using Satellite to manage all these systems, and deploy their own Java
business app to the systems.

The query about Push to Client came up because it proved somewhat inflexible in
it's current configuration.

The way things work is that a store would run a batch job called "End Of Day". 
This would do some kind of database reconciliation and stock ordering.  Then it
would communicate these things to the central server.

We needed to ensure that a store would only ever check in to the Satellite
server and install updates during this "End of Day" procedure.  Only in
emergencies would we want to update any software on a store machine during the
online sales day.

If we enabled push to client, we would be able to push emergency items out in an
instant (e.g. an update to the cashpoint program was required one time due to a
bug that was sent out.  None of the stores that had applied the update could
take any cash in via the till - this would have been an ideal scenario for Push
to Client).

However, this would then remove from us the ability to have updates processed by
the End of Day process.  The schedule by which all updates were to be done was
when the manager of a store had manually run his/her End of Day process.  If the
process wasn't done, the updates wouldn't go out.

Setting the updates to run not before a selected time isn't valid as we had
instances where a store ran a special 24-hour opening (quite popular actually).
 The End of Day process wouldn't be run until the next evening - so that's when
the updates should go out, but only for that store.

What we effectively end up with is:

(*) Push to Client (immediately)
( ) Not before selected time

What we needed was:

(*) Push to Client (immediately)
( ) Next rhn_check (during End of Day process)
( ) Not before selected time

I know it's not a bug, but I thinks it's a pretty valid feature enhancement.

At the end of the day, it prevented Provisioning Entitlements being ordered for
all those machines.  We had to hand code a system to systematically log into
each of the 700 store servers and remotely run the rhn_check command via ssh. 
Not the messiest implementation in the world, but it would have been cleaner if
all the scheduling requirements could have been dealt with directly by Satellite.


Duncan Innes
Comment 4 Duncan Innes 2006-11-02 09:10:52 EST
Is there any comment on this?

With RHEL 5 coming out soon it would be nice to see this included.

I'm no longer in charge of the same 700 Satelite clients, but a slightly smaller
400 machine network.  The same issue still applies:

SOME updates should be pushed out via osa-dispatcher as they are urgent.

MOST updates we want to be picked up by the NORMAL rhn_check service which is
run as part of an overnight script that runs ONCE a day.

The "Not before a selected time" option doesn't count for us as we can never be
sure when the overnight script will actually get to the rhn_check section.  Some
machines have the script run manually by the user before they leave for the
evening rather than let cron pick the job up.

Duncan Innes
Comment 5 John Wregglesworth 2006-11-02 10:24:11 EST
This sounds like a useful enhancement. I'll put this on the triage list for our
RHEL 5-related satellite release so that it gets considered by project management.
Comment 6 Mike McCune 2007-04-05 11:24:37 EDT
moving to next release.  we ran out of time to implement this in the upcoming
500 Release.
Comment 7 Red Hat Bugzilla 2007-05-03 01:39:14 EDT
User wregglej@redhat.com's account has been closed
Comment 8 Duncan Innes 2008-04-21 16:38:04 EDT

Looks like you ran out of time during the 5.1 development phase too.

I've since come across 4 other large corporate users of Provisioning
entitlements that find this impossible to use in it's current state.

It surely can't be that difficult to have an extra scheduling algorithm that
doesn't post a jabber message to the system and just waits for the system to
check in?
Comment 10 Issue Tracker 2008-06-09 14:23:58 EDT
Who is the customer?
Rabobank AN#614568

What is the exact nature of the problem trying to be solved with this
When a client is enabled for provisioning and has the osad service running
properly, events can be picked up by the client in a matter of seconds.
The customer has now lost the ability to schedule event to happen the next
time a server checks in with the Satellite.

What, if any, business requirements are satisfied by this request? (What
is the use case context?)
Rabobank has servers which only run rhn_check via a daily cron job once
all other work is done.  He needs to be able to pick some events up (like
important package updates) at the end of this cron job so that updates
only happen when the machine isn't processing. 

List the functional requirement(s) for performing the action(s) that are
not presently possible. Please focus on describing the problem related
requirements without projecting any specific solution.

He needs to be able to schedule events to only be picked up when the
server next checks in on it's regular rhnsd schedule.

Something similar to: https://bugzilla.redhat.com/show_bug.cgi?id=190153

That the customer submitted nearly 2 years ago.
He needs the ability to schedule actions as follows

( ) Push to Client
(*) Next regular checkin
( ) Not before [Enter Date & Time here]

Each functional requirement must have clear acceptance criteria so Red Hat
understands what success looks like. If test cases can be provided this
would be even more ideal (bonus points for RHTS test cases).

There's a groups of servers in Rabobank that have a requirement that
package installs are only to be handled through the end-of-day script
which in some cases is run manually.  At this point, the databases and
services are offline and they permit package upgrades only in this state. 
They have no control over when the end-of-day script is run by the system

The result is that despite purchasing a large number of provisioning
licenses (247), they cannot use one of the key features of this license.

Configuring Push to Client is NOT viewed as a feature enhancement at
Rabobank as it REMOVES the ability to schedule updates for the next time
rhn_check connects to the satellite. 

What is the desired release vehicle to satisfy these requirements? Major
release Minor release

RHN/satellite 5.0

Please justify with reference to the release vehicle policy described in
the RHEL Inclusion Criteria wiki page

Issues impactic strategic/important customer

What package(s) are affected by this RFE? (List "new" if new technology
is likely to be required)

RHN Satellite

Who is the sales sponsor?
Will update later. 

What is the Red Hat business opportunity with this customer?
Will update later. 

What is the status and risk to the contract if this RFE is not satisfied?

Will update later. 

This event sent from IssueTracker by jwest 
 issue 172399
Comment 16 Clifford Perry 2009-02-11 15:06:05 EST

*** This bug has been marked as a duplicate of bug 193268 ***
Comment 17 Duncan Innes 2009-02-26 04:14:48 EST
Since I raise this request, and it has been marked as a duplicate of a NEWER bug, I would very much like to see the progress it makes.

Unfortunately, I don't have access to bug 193268.

Could this be opened, or could I be granted access to track this please?


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