This service will be undergoing maintenance at 20:00 UTC, 2017-04-03. It is expected to last about 30 minutes
Bug 64710 - Need to build RHN APIs
Need to build RHN APIs
Status: CLOSED DUPLICATE of bug 116359
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Other (Show other bugs)
unspecified
All Linux
high Severity medium
: ---
: ---
Assigned To: Greg DeKoenigsberg
Fanny Augustin
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-05-09 16:36 EDT by Isaiah Weiner
Modified: 2007-10-23 22:21 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 13:48:52 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Isaiah Weiner 2002-05-09 16:36:12 EDT
Description of problem:
Cisco would very much like to put the final nail in their internal update 
mechanism channel.  This step will be to fully automate a single package's 
update.  In the reproducability section I've outlined what should happen.  It 
was represented to me by gdk this could be done already, so I expect it will be 
trivial.  The channel name will be cisco-sudoers, I can create it if you like.

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


How reproducible:
Always

Steps to Reproduce:
1. script dumps package into tree
2. script uses rhn_package_manager to update package in rhn channel
3. upon update in channel, rhn automatically pushes package to all subscribed 
systems
	

Additional info:
Comment 1 Greg DeKoenigsberg 2002-05-14 16:17:01 EDT
To address the issue in detail:

In the past, we *did* have an "automatic update" functionality, more than a year
ago now in the previous lifetime of RHN.  We removed it -- in part because it
was completely unreliable, in part because we felt that it was too dangerous to
leave in the hands of the majority of our customers.

When it did exist, it was a global pref, and was either "update this system
automatically always" or "don't."  There was no package granularity of any kind.

The heart of this request is the ability to do things programatically according
to certain criteria.  Let's build a sample API and walk the code path:

rhn.Login
SystemsInChannelFoo = rhn.GetSystemList (channel=foo)
SystemsWithPackageBar = rhn.GetSystemList (package=bar)
for each System in union (SystemsInChannelFoo, SystemsWithPackageBar) {
  rhn.scheduleAction (action=update, system=System, package=bar)
}
rhn.Logout

...which, when run by the script that currently pushes packages to the proxy,
would "automatically" update the correct machines.

SO... this means API work.  Which is an RFE, but an extremely important RFE.

We'll be discussing the requirements around building a set of basic APIs,
documenting them, and ensuring that they stay functional.
Comment 2 Todd Warner 2002-11-15 15:39:26 EST
Has this been addressed further at all???

This is a general RHN RFE, so I'm changing the Product as well (ie. not RHN Proxy 
Server specific).
Comment 3 Greg DeKoenigsberg 2004-06-12 08:51:25 EDT

*** This bug has been marked as a duplicate of 116359 ***
Comment 4 Red Hat Bugzilla 2006-02-21 13:48:52 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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