Bug 493817 - channel content won't get updated
channel content won't get updated
Status: CLOSED CURRENTRELEASE
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Server (Show other bugs)
530
All Linux
high Severity medium
: ---
: ---
Assigned To: Pradeep Kilambi
wes hayutin
:
Depends On:
Blocks: 485807
  Show dependency treegraph
 
Reported: 2009-04-03 05:36 EDT by Tomas Lestach
Modified: 2009-09-10 14:41 EDT (History)
1 user (show)

See Also:
Fixed In Version: sat530
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-10 14:41:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tomas Lestach 2009-04-03 05:36:01 EDT
Description of problem:
Channel content doesn't seem to get updated even after pressing "Update" button on the channel detail web page.

Version-Release number of selected component (if applicable):
Satellite 5.3.0

How reproducible:
always

Steps to Reproduce:
1. Create a new public child channel (WEBUI - Channels - Manage Software Channels - create new channel) with a Red Hat Enterprise Linux channel as parent.

2. Register a client to the Satellite. Subscribe the client to the newly created channel (<client> - Details - Alter Channel Subscriptions - check new channel - Change Subscriptions)

3. Push a package into the new channel. Make sure the package is not included in any channel the client is subscribed to.
rhnpush --server=<sat-server> -c <new-channel> <package>

4. Trigger the channel update by clicking on the "Update" button on the channel details page. Make sure you see your pushed package in the channel.

5. Run on the client:
# yum clean all
# yum repolist
on the client to verify it is subscribed to the channel

6. Wait some time. If following command is run to early, I get following error message:
Error: Cannot retrieve repository metadata (repomd.xml) for repository: <channel>. Please verify its path and try again

(Not sure if this is correct behaviour.)
# yum list all | grep <channel>
Anyway, after "some time" I see the uploaded package.

7. Remove the package and push another one to the channel and repeat steps 4 to 6.

Actual results:
When adding/deleting any package from the channel, I see immediately the correct status on the WEBUI, but not on the client.
After 25 minutes
# yum list all | grep <channel>
still displays the original package pushed in 3.) that I removed in 7.). (And I am not sure, if it gets updated, if I'd wait longer.)

If you'd run
# yum install <package>
it fails of course.
Error Downloading Packages:
  <package>: failed to retrieve getPackage/<package> from <channel>
error was [Errno 14] HTTP Error 404: Not Found

Expected results:
Any package add/removal shall immediately be visible for the clients.
This feature works as expected in Satellite 5.2, but not in Satellite 5.3.
Comment 1 Brandon Perkins 2009-04-07 11:38:42 EDT
Approved.   But please check that the problem isn't purely because of slow or under-resourced hardware.
Comment 3 wes hayutin 2009-04-23 14:21:22 EDT
This works after a few minutes.. which is the intent..
and should work immediately after the following query returns no results

SQL> select * from rhnRepoRegenQueue;

no rows selected



yum repolist works
yum list works
yum install works 


verified 422.2 build
Comment 4 John Matthews 2009-08-07 12:58:52 EDT
Move to RELEASE_PENDING

pushed new package
saw entry in rhnRepoRegenQueue

waited 1 or 2 minutes, task was picked up
repos were regenerated
Comment 5 Brandon Perkins 2009-09-10 14:41:10 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-1434.html

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