Bug 506548

Summary: Yum repodata takes a very long time to generate on latest builds of Satellite 530
Product: Red Hat Satellite 5 Reporter: Steve Salevan <ssalevan>
Component: ServerAssignee: Justin Sherrill <jsherril>
Status: CLOSED DUPLICATE QA Contact: Steve Salevan <ssalevan>
Severity: medium Docs Contact:
Priority: medium    
Version: 530CC: pkilambi
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-06-17 17:46:47 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 Steve Salevan 2009-06-17 17:39:13 UTC
Description of problem:
If a user creates a channel on a Satellite or runs a satellite-sync, it will take a considerably longer amount of time for the corresponding Yum repodata to generate for these channels than it would take on a 520 Satellite.  For instance, I created a channel containing one package on a 6/5 build 530 Satellite, and it took over an hour for the repodata to generate.

This is more of a 'soft' bug, as I don't have any further concrete details or educated hunches to add, but this problem has become pervasive enough to require some attention.

Version-Release number of selected component (if applicable):
530, 6/12 build

How reproducible:
Always

Steps to Reproduce:
1. Sync a few channels (including a RHEL 5 channel) to a Satellite
2. Register a RHEL 5 system and subscribe it to a child channel
3. Run a few operations requiring a Yum repodata download for one of the child channels, such as a package install
  
Actual results:
Yum repodata takes a long period of time to generate if at all

Expected results:
Yum repodata generates within a reasonable amount of time (< 1 hour)

Additional info:

Comment 1 Pradeep Kilambi 2009-06-17 17:46:47 UTC

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