Bug 64710 - Need to build RHN APIs
Summary: Need to build RHN APIs
Status: CLOSED DUPLICATE of bug 116359
Alias: None
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Other   
(Show other bugs)
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Greg DeKoenigsberg
QA Contact: Fanny Augustin
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2002-05-09 20:36 UTC by Isaiah Weiner
Modified: 2007-10-24 02:21 UTC (History)
5 users (show)

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

Attachments (Terms of Use)

Description Isaiah Weiner 2002-05-09 20:36:12 UTC
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:

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 

Additional info:

Comment 1 Greg DeKoenigsberg 2002-05-14 20:17:01 UTC
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:

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)

...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 20:39:26 UTC
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 12:51:25 UTC

*** This bug has been marked as a duplicate of 116359 ***

Comment 4 Red Hat Bugzilla 2006-02-21 18:48:52 UTC
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.