Bug 129178 - [RFE] Vetting System for Packages in RHN
[RFE] Vetting System for Packages in RHN
Status: NEW
Product: Spacewalk
Classification: Community
Component: Server (Show other bugs)
0.3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Todd Warner
Red Hat Satellite QA List
: FutureFeature
Depends On:
Blocks: spacewalk-rfe
  Show dependency treegraph
 
Reported: 2004-08-04 15:19 EDT by Jack Neely
Modified: 2016-07-14 01:22 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-16 14:44:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jack Neely 2004-08-04 15:19:49 EDT
Description of problem:

Looks like I haven't filed this one yet.  I'm sure you'll love it.  :-)

I need a vetting system for packages in RHN.  I would like to be able
to specify package regex's that cannot be distributed to my clients
until they have been approved by someone with that capability in their
RHN account.  Possibly this feature might be attached to custom
sub-channels.

Most of the time the normal updates from RH work fine.  However, in
certain situations I need the ability to release a custom package with
my Proxies simultaniously.  Also if certain packages break I have a
mission critical situation where several 100 machines must be manualy
fixed.  That isn't acceptable.

Example:  I maintain OpenAFS for NCSU.  I need to keep the kernel
packages installed on clients in sync with my openafs kernel modules.
 Right now I just hope that somebody doesn't upgrade and reboot before
I have the chance to get new openafs packages into RHN.  If a machine
boots without afs it is unusable by any user.

Example:  Bugs in these packages cause big headaches: kernel,
kerberos, up2date, hesiod, sendmail (I need custom version), krbafs
Comment 1 Bret McMillan 2004-08-04 15:38:50 EDT
Here's the currently recommended technique:

1.  have a test channel, 'test-channel-a', and subscribe
'test-system-1' to 'test-channel-a'.  assume you have a production
channel 'prod-channel-b' with a system subscribed to it, 'prod-system-2'.

2.  push release candidate kernel + module rpms to 'test-channel-a'

3.  run 'up2date -u' on 'test-system-1', begin qa

4.  if the packages are ok, use the channel management features to
copy the kernel + module packages from 'test-channel-a' to
'prod-channel-b'

5.  run 'up2date -u' on 'prod-system-2' to deploy new packages to the
production machine

Is there some reason that does not meet your needs?
Comment 2 Jack Neely 2004-08-16 10:06:05 EDT
This is not sufficant.  In fact, this gives me the exact reciprocal
problem.  Unless I miss my guess, with this suggestion using custom
base channels I then have to approve _all_ package errata and lose the
handiness of the extra Red Hat managed subchannels.

I want to build on top of Red Hat's QA, not replace it.  I don't have
time to "approve" every errata as fast as they come out.  

The issue that started this was the fact that I wanted control of when
my clients see kernel errata and kernel errata only.  This is so I can
release OpenAFS modules at the same time kernel are release so I don't
have drift between the currently installed kernel and my custom kernel
modules.
Comment 3 Amy Owens 2008-10-16 14:44:18 EDT
This bug has been closed due to inactivity.  Please open a new bug with specific details if this problem is still occurring or if an enhancement is needed.
Comment 4 Jack Neely 2008-10-23 14:41:50 EDT
Re-opening and moving to the Spacewalk product.
Comment 5 Clifford Perry 2009-07-27 15:40:20 EDT
Not on current roadmap for spacewalk 06, nor 07. Moving to space07 tracker for now for re-review at start of 07 cycles, mid to late Aug. 

Cliff
Comment 6 Jan Pazdziora 2010-11-19 11:04:46 EST
Mass-moving to space13.
Comment 7 Miroslav Suchý 2011-04-11 03:33:26 EDT
We did not have time for this one during Spacewalk 1.4 time frame. Mass moving to Spacewalk 1.5.
Comment 8 Miroslav Suchý 2011-04-11 03:37:10 EDT
We did not have time for this one during Spacewalk 1.4 time frame. Mass moving to Spacewalk 1.5.
Comment 9 Jan Pazdziora 2011-07-20 07:51:40 EDT
Aligning under space16.
Comment 10 Jan Pazdziora 2011-08-16 01:07:12 EDT
Moving back to NEW -- we don't have any patch to review nor anybody actively working on it.

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