Bug 666463

Description of problem:  The rhnplugin provided by yum-rhn-plugin does not respect yum's metadata_expire setting, and therefore all channels from RHN/RHNS use the default expiration time of 6 hours (21700 seconds).  

This came up in regards to an issue reported while the customer was using Satellite.  The customer pushed new packages to their Satellite base channel and taskomatic successfully regenerated the repodata for that channel.  They then scheduled a package upgrade from the satellite, which triggered the clients to run a yum update, but the metadata had not yet expired and thus the packages could not be installed without either

a) waiting 6 hours for the metadata to expire, OR
b) manually running 'yum clean all' on all of the clients

This is very inconvenient for the customer, considering they are looking to roll out satellite with several thousand clients.  

In response to the customer's report, I reproduced the issue and attempted to prevent it by lowering the metadata_expire setting so that the clients would not have to wait so long after a package push.  When this was unsuccessful, further debugging showed that repos made available through rhnplugin were still calling withinCacheAge with an expiration_time of 21700, while standard yum repos (for instance epel) were respecting my custom metadata_expire setting.  

I have implemented and tested a patch (attached) against yum-rhn-plugin which allows rhnplugin-based channels to use this setting.  I tested the setting in [main] of yum.conf, [main] of rhnplugin.conf, and individual channels in rhnplugin.conf.  All were successful at expiring the metadata of rhnplugin-based channels after the configured amount of time.

Version-Release number of selected component (if applicable): yum-rhn-plugin-0.9.1-7.el6.noarch.  

How reproducible: Whenever RHN/RHNS channel metadata is updated and a client has updated its metadata within the last 6 hours.

Steps to Reproduce:
1. Create a channel in Satellite
2. Register system to channel
3. 'yum clean all; yum makecache' on system
4. Push new or updated packages to channel
5. Within 6 hours from step 3, EITHER:
  a. yum check-update / yum install <package>
   OR
  b. Schedule an install/upgrade of one of the new packages for this system using the satellite UI

Actual results: If the action was carried out with yum (5a), observe that the packages are not available.  If the action was scheduled through satellite (5b), observe that it is reported as successful but the packages are not actually installed/updated.  

Expected results: Packages are installed or updated

Additional info: Problem also exists on RHEL5, and if no objections to implementing this functionality are presented, I will be filing another bug against it as well