Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 647152

Summary: yum repodata expire too late - errata workflow broken
Product: Red Hat Enterprise Linux 5 Reporter: Tilman Baumann <tbaumann>
Component: yum-rhn-pluginAssignee: Miroslav Suchý <msuchy>
Status: CLOSED DUPLICATE QA Contact: Red Hat Satellite QA List <satqe-list>
Severity: high Docs Contact:
Priority: medium    
Version: 5.0CC: bugzilla-redhat, cperry, eliningt, mosvald, nbronson, vgaikwad, xdmoon
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-01-18 07:07:23 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:
Attachments:
Description Flags
a temporary patch which allows rhnplugin to read metadata_expire value from yum.conf none

Description Tilman Baumann 2010-10-27 12:08:56 UTC 
Description of problem:

There is a very general problem in yum rhnplugin and rhn_check.

It breaks down to the following individual problems:

Yum rhnplugin issues
- rhnplugin metadata don't expire for a very long time
- rhnplugin does not respect the yum.conf setting metadata_expire
- rhnplugin does not (seem  to) have a way of simply testing if server repodata are newer then what is currently worked with

rhn_check issues
- rhn_check will only call yum with very unspecific install options
- therefore it will return success even if it installed something completely different then what the user requested
- Most times this is due to old client side repodata still containing older versions

How reproducible:

Apply new package to channel and try to install it shortly after that.

There is a level of randomness, but chances are great that it will not see the new packages.

Steps to Reproduce:

1. Apply errata to channel (New repodata will be generated)

2. Schedule installation of this package on a system via rhn/satellite

3. rhn_check will run and (most likely) still use the old metadata.
Effect "yum install packagename" will not fail, but it will not install the version the user expected.
  
Actual results:

Some old package is installed.

Expected results:

Exactly the last version in the channel.


I see two options to solve that.

rhnplugin should check the repodata timestamp before it does anything and download changes if necessary.
(prefered option)
Something like a HEAD request on those details. That should be cheap enough to have to happen every time.
This option could be a parameter for yum which is not used by default but enabled when used by rhn_check.

rhn_check will do yum makecache before issuing yum jobs to be sure yum is up to date. (stupid, but will work)

Additional info:

This is connected to another generic problem with rhn_check. It will translate the job "install packagename-version.arch into "yum install packagename.arch" which will always install the last version (known by the client) and not do exactly what was requested.
I will create a BZ for that issue later...
Comment 2 Tilman Baumann 2010-12-01 17:46:17 UTC 
I think I just disproved my theory that rhn_check will ignore the version of the package scheduled for installation.
With yum-rhn-plugin-0.5.3-30.el5 rhn-check-0.4.20-33.el5_5.2 I have 

 [['iptstate', '1.4', '2.el5', '', 'x86_64']]
{   'flags': [],
    'packages': [(['iptstate', '1.4', '2.el5', '', 'x86_64'], 'i')],
    'probFilterFlags': [],
    'vsflags': []}

in transaction_data in /usr/share/rhn/actions/packages.py -> runTransaction via packages.update in /usr/share/rhn/actions/errata.py

Not sure if this was recently fixed. I was rather sure about that not being the case. I thought it would only call the equivalent of yum update packagename.

Anyway, this is not the main problem here of course.
I thought this was the reason install requests for package versions that yum does not know result in just the last known version being installed and rhn_check reportung success to rhn.
But as I said, this is only half of the problem.
Comment 5 Martin Osvald 🛹 2010-12-28 09:37:28 UTC 
Created attachment 470929 [details]
a temporary patch which allows rhnplugin to read metadata_expire value from yum.conf