Bug 224357

Summary:	system requirement of "6 GB storage per channel" too low to store "mature" channels
Product:	Red Hat Satellite 5	Reporter:	Riaan van Niekerk <riaanvn>
Component:	Docs Reference Guide	Assignee:	John Ha <jha>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Red Hat Satellite QA List <satqe-list>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	500	CC:	adstrong, cperry, stanislav.polasek
Target Milestone:	---	Keywords:	Documentation
Target Release:	---
Hardware:	All
OS:	Linux
URL:	http://www.redhat.com/docs/manuals/RHNetwork/satellite/4.1.0/s1-requirements-hardware.html
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-09-30 09:20:08 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Riaan van Niekerk 2007-01-25 12:46:01 UTC

The system requirements for Satellite mention "6 GB storage per channel, in the
/var/satellite/ directory by default but configurable at install"

This is completely insufficient to store the packages of current RHEL 3 / RHEL 4
channels. e.g. the channel dump for RHEL 4 x86_64 is 30 ISOs (including
incremental dumps), 18 GB. I have no reason to believe that once this data is
imported to /var/satellite, it will use any less.

I would recommend a more generous estimate of 15 to 20 GB per channel

Comment 1 Michael Hideo 2007-06-20 01:31:48 UTC

Moving Bugs to John Ha and assigning.

Re-prioritization meeting on June 20, 7PM EST.

Comment 2 Riaan van Niekerk 2007-09-11 14:54:44 UTC

This same insufficient 6 GB per channel is still present in the RHN Satellite 
5.0 documentation:

http://www.redhat.com/docs/manuals/satellite/Red_Hat_Network_Satellite-5.0.0/
html/Installation_Guide/s1-requirements-hardware.html

Comment 3 Michael Hideo 2007-10-23 02:47:52 UTC

Removing automation notification

Comment 4 Riaan van Niekerk 2009-09-30 09:20:08 UTC

I see this is fixed in the latest version