Red Hat Bugzilla – Bug 1004986
Refactor YumProfiler._translate_erratum()
Last modified: 2014-08-09 02:55:57 EDT
There are two problems with the _translate_erratum() method: 1) The _translate_erratum() function in the YumProfiler generates a string that contains the full NEVRA for each RPM than an erratum references, and inserts that string as the 'name' field of the "unit" dictionary that represents the RPM. This is a departure from what the install_units() method does with RPMs (it leaves the dictionaries as having all of the NEVRA fields.) The _translate_erratum() function should instead provide unit keys as its output, so that the output for RPMs and Erratum returned by install_units() is consistent. 2) In #980611, Erratum RPMs can end up with None as the Epoch due to a bug in Yum (which our distributor uses). When the Epoch for an RPM is None, _translate_erratum() ends up generating package names like <package_name>-None:<version>-<release>.<arch>. The -None ends up causing the consumer to fail to install the package, since there is likely not a package called <package_name>-None available to it. To fix this, the refactored _translate_erratum() should only include the Epoch in the unit key that it generates if one is available. I do acknowledge that there is a bit of a contradiction in my use of "unit_key" as the expected output of _translate_erratum(), since a unit key in this case does have an epoch, and I am suggesting that we drop epoch when it is unavailable. So what I mean by "unit_key" is "most complete version of a unit_key that we can generate here with the available information".
Fixing this bug should help us to resolve the symptoms (but not the true cause) of #980611. The cause of that bug is that Yum generates bad XML that lacks the epoch during publishing. This bug can only be fixed if we also fix #1004981, because the current _translate_erratum() depends on the agent only using the name field (which is the subject of that bug). These two bugs must be fixed for the same Pulp release.
This has been fixed as part of the new yum distributor
build: 2.4.0-0.7.beta
Preethi, to verify this bug you should try to make sure you can do these two things: 1) Use pulp-admin's rpm consumer section to install a package on a consumer by name only. 2) Use pulp-admin's rpm consumer section to install a package by name-version-release. I think the help text on the consumer install command just has --name, but you should be able to pass name-version-release. I think there might be a bug filed about that issue, but I can't remember for sure.
[root@yttrium ~]# pulp-admin rpm consumer package install run --consumer-id patch -n zebra Install task created with id [ ed338168-5424-49ba-944e-9b2437c75946 ] This command may be exited via ctrl+c without affecting the request. Refresh Repository Metadata [ OK ] Downloading Packages [ OK ] Check Package Signatures [ OK ] Running Test Transaction [ OK ] Running Transaction [ OK ] Install Succeeded +----------------------------------------------------------------------+ Installed +----------------------------------------------------------------------+ Name: zebra Version: 0.1 Arch: noarch Repoid: zoo +----------------------------------------------------------------------+ Installed for Dependencies +----------------------------------------------------------------------+ Name: lion Version: 0.4 Arch: noarch Repoid: zoo Name: elephant Version: 8.3 Arch: noarch Repoid: zoo Name: crow Version: 0.8 Arch: noarch Repoid: zoo Name: tiger Version: 1.0 Arch: noarch Repoid: zoo Name: dolphin Version: 3.10.232 Arch: noarch Repoid: zoo Name: gorilla Version: 0.62 Arch: noarch Repoid: zoo Name: bear Version: 4.1 Arch: noarch Repoid: zoo Name: kangaroo Version: 0.2 Arch: noarch Repoid: zoo Name: pike Version: 2.2 Arch: noarch Repoid: zoo [root@yttrium ~]#
This has been fixed in Pulp 2.4.0-1.