Bug 1076727

Summary: [RFE] Enhance spacewalk to allow for use of package cache
Product: [Community] Spacewalk Reporter: helfman
Component: ServerAssignee: Michael Mráka <mmraka>
Status: CLOSED CURRENTRELEASE QA Contact: Red Hat Satellite QA List <satqe-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 2.2   
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-03-21 10:58:13 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1484117    

Description helfman 2014-03-14 22:36:58 UTC
Description of problem:
Spacewalk seems to only have one operation for patches/installations. Download and install. From an operational point-of-view, it would be great to be able to separate these operations within the tool, or be given a way to do it.

So I could schedule a job everyday for yum download, and then have spacewalk use the yum download cache in evaluation before an update. So instead of updating 90 packages and pulling them all down, spacewalk may need to only grab 5 new packages, as the rest live on disk from previous pulls through a package tool (yum, spacewalk, apt, etc. ).

Consider an environment of 100+ machines being updated all at once. Lots of network operations, that can be distributed differently if the tool were aware of either staging downloads, and or package caches (spacewalk,yum,apt, etc.) and using that cache as part of operations for installations.

Thanks!

-jgh

Comment 1 Michael Mráka 2014-03-17 09:19:28 UTC
This feature is called 'Staging content'. It has to be enabled in
 Admin -> Organization -> "org_name" -> Configuration -> Enable Staging Contents.

When it's enabled and you schedule package update in the future then packages are downloaded several hours ahead of the planned update
(defined by stagingContentWindow in /etc/sysconfing/rhn/up2date). And at the scheduled time update is performed from cache.

Comment 2 Eric Herget 2017-09-28 18:09:21 UTC
This BZ closed some time during 2.5, 2.6 or 2.7.  Adding to 2.7 tracking bug.