Description of problem: After pushing new packages to a spacewalk repository and triggering systems to update to this packages (via osad), the update won't work because of metadata caching problem. Version-Release number of selected component (if applicable): yum-rhn-plugin-0.6.2-1.el5 Spacewalk 0.6 How reproducible: Mostly Steps to Reproduce: 1. push new package to a dedicated spacewalk repository 2. check, that system in spacewalk has 1 package for update marked 3. check proper osad connection 4. trigger update via spacewalk Actual results: Nothing happen on system, but event is moved to history with "update succeeded": Summary: Package Install scheduled by *** Details: This action will be executed after 11/ 4/09 10:01:29 AM UTC. This action's status is: Completed. The client picked up this action on 11/ 4/09 10:01:37 AM UTC. The client completed this action on 11/ 4/09 10:01:40 AM UTC. Client execution returned "Update Succeeded" (code 0) Packages Scheduled: * package-version-release Time: 11/ 4/09 10:01:29 AM UTC Expected results: Package installed/updated on system Additional info: I believe, there are 2 issues here: 1) yum-rhn-plugin reports 0 while doing nothing 2) yum-rhn-plugin did nothing For 1) I have no solution but for 2) I digged deeper into the issue and found: local system check shows, that "yum update" also did not update the package, so 2 solutions: 2a) update would work if, action is triggered again after executing on the system "yum clean expire-cache" 2b) extending /usr/lib/yum-plugins/rhnplugin.py with --- /usr/lib/yum-plugins/rhnplugin.py.orig 2009-08-07 13:24:34.000000000 +0000 +++ /usr/lib/yum-plugins/rhnplugin.py 2009-11-04 10:35:46.000000000 +0000 @@ -256,6 +256,7 @@ self.retries = 1 self.throttle = 0 self.timeout = 60.0 + self.metadata_expire = 60 self.http_caching = True (hint found here: https://fedorahosted.org/spacewalk/browser/client/rhel/yum-rhn-plugin/rhnplugin.py?rev=20566c5ea64527c9159104b7c61bb70b149b6318) Is there any other way to configure metadata_expire for spacewalk repositories (e.g. on the server itself)?
Mass-moving to space13.
Problems described in this report have been addressed in bugs: https://bugzilla.redhat.com/show_bug.cgi?id=666876 and https://bugzilla.redhat.com/show_bug.cgi?id=666545 Thank you for your report and sorry for the delayed response.
This bug has been fixed in Spacewalk 1.3.