Description of problem: Packages which originate from different sources (e.g. CentOS and Red Hat) will reside in different channels and will share the same nvrea, created errata should be able to reference packages from both channels. When adding two such packages (which originate from different sources, are in different channels and have the same nvrea) to an errata, the second package is not added to the errata. No errors are reported. Publishing the errata correctly identifies on the "Publish Errata" confirmation page that the package is available in both channels, but once published, the errata does not list the 'missing' package in the "packages" summary tab. Version-Release number of selected component (if applicable): Spacewalk 1.7 + PostgreSQL DB on CentOS 6.2 x86_64 How reproducible: Always Steps to Reproduce: 1. Create an Errata using the WebUI 2. Select Packages->Add and search for a package known to be from different sources in two channels with the same nvrea e.g.vsftpd-2.2.2-6.el6_0.1-x86_64 from a CentOS-6-x86_64 channel and RHEL-6-x86_64 channel 3. Click "Add Packages" Actual results: A confirmation message returns: "2 packages added to errata" but only one package (the first in the list) is added. Expected results: Both packages selected to be added to the errata. Additional info: Attempting to add the 'missing' package reports "1 package added to errata" but still doesn't add the package to the errata. Removing the existing package and replacing with the skipped package from the other channel succeeds at the expense of not being able to add the original package (like above). Using the API, adding the packages using individual calls to errata.addPackages returns "1" package added for the first package and "0" for the second. Attempting to add both packages in the same API call (to an empty errata) returns "1" package added.
Ive run into this issue too and so has almost every one else who as written an errata publishing and or syncing script. this also effects spacewalk 1.8 my experience with testing with 1.8 was slightly different errata.addPackages returned 1 for both adds but only actually added the first package. This has been discussed in two threads on the mailing list in the last few days https://www.redhat.com/archives/spacewalk-devel/2012-November/msg00050.html and here https://www.redhat.com/archives/spacewalk-list/2012-November/msg00173.html There is also a more insidious problem is in the errata.create API call with publish what happens is the first package then gets copied to the channel that contains the second package. This breaks yum's ability to resolve what package is the correct one, which breaks updating and kickstarting utilizing the second channel. Ive done some experiments which had some interesting results I can add the additional packages to the errata manually via SQL and it works as expected " spaceschema=# select id from rhnErrata where advisory_name like 'SLBA-2012:1302'; id ------- 29954 (1 row) spaceschema=# select * from rhnerratapackage where errata_id = '29954'; errata_id | package_id | created | modified -----------+------------+-------------------------------+------------------------------- 29954 | 107482 | 2012-11-21 18:12:48.351349-05 | 2012-11-21 18:12:48.351349-05 29954 | 107483 | 2012-11-21 18:12:48.351349-05 | 2012-11-21 18:12:48.351349-05 (2 rows) spaceschema=# insert into rhnerratapackage (errata_id,package_id,created,modified) VALUES(29954,107890,'2012-11-21 18:12:48.351349-05','2012-11-21 18:12:48.351349-05'); INSERT 0 1 spaceschema=# insert into rhnerratapackage (errata_id,package_id,created,modified) VALUES(29954,107889,'2012-11-21 18:12:48.351349-05','2012-11-21 18:12:48.351349-05') ; INSERT 0 1 spaceschema=# " then I refreshed the page listing the packages in the errata and I got this " CentOS 6 FastTrack (x86_64) sha256:e85a76b7a959db0566c656b82fb4ad69ddec2ab448e111086716c63e18945c33 cvs-1.11.23-15.el6-x86_64 sha256:455178ca3ab78b5f0403da16f4512ac9f5d2481e191329f5b7f02ef7b05b2423 cvs-inetd-1.11.23-15.el6-noarch Scientific Linux 6 Updates FastBug (x86_64) sha256:b2c4eeb020973c966747ccbd2711ae8f25f1f35f2be12211e21ba4118fef4e2f cvs-1.11.23-15.el6-x86_64 sha256:d09f12ee26dada51aafa210846c120dff2fab3a8ff17ec1fb6d510677cfb6784 cvs-inetd-1.11.23-15.el6-noarch " so we know the problem is not a limitation in the database schema
by the way the errata.create bug effects rhn-clone-errata.py and centos-errata.py its the root cause of the issue where they copy packages to other channels.
I started to look into some of the Java code for this and came to a unexpected conclusion. I'm still investigating but it looks like this isn't really bug. Its more of a side effect of a design decision which hadn't taken every thing into account, so we possibly should reclassify this as an RFE. now I still need to look deeper but here is what I found so far from my quick look at the code in root/java/code/src/com/redhat/rhn/domain/errata/ErrataFactory.java starting at line 229 " /** * Takes a published or unpublished errata and publishes to a channel, creating * all of the correct ErrataFile* entries. This method does push packages to * the appropriate channel. (Appropriate as defined as the channel previously * having a package with the same name). * @param errata errata to publish * @param chan channel to publish it into. * @param user the user doing the pushing * @return the publsihed errata */ public static Errata publishToChannel(Errata errata, Channel chan, User user) " starting at line 257 here is the second issue " /** * Private helper method that pushes errata packages to a channel */ private static Errata publishErrataPackagesToChannel(Errata errata, Channel chan, User user, Set<Package> packages) { for (Package pack : packages) { //push the package to the approrpiate channel chan.addPackage(pack); " also suspect files are root/java/code/src/com/redhat/rhn/manager/channel/ChannelManager.java In general there needs to be two things added 1) A check added to see if the package push is really needs to really happen. right now the assumption is that if there is a package with the same NERVA are the same package. This is probably true in most satellite installs with only RHEL packages but as soon as you start adding custom packages, and other distributions this logic breaks down very quickly 2) An additional safety should be added to prevent multiple packages with the same nreva but different checksums from being added to the same channel
I am running into the same issue with Spacewalk 1.9. It makes an interesting statement when version 1.9 is considered stable and bugs submitted against version 1.7 still hold a status of "NEW" As pointed out by Marino, it appears his behavior (while unexpected by most users of the API) is "by design." The behavior being that the author of the function seems to have decided to sanity check the package inclusion in channels and "correct" them. This creates multiple levels of inconsistencies which should have been addressed by now. The most major inconsistencies: (1) It isn't clear what behavior should take place as part of "publish" as setting the publish flag in create() will not manipulate the channels. (2) None of the other API functions seems to have the same sort of sanity checking and leave it up to the SOAP client to do make any additional API calls to keep things sane. (3) All other API functions seem to be try to limit their scope of modification to what is implied by the function name, namespace of the function and the variables passed to the function. This is the only function I can find which manipulates the package membership in a channel without being passed any package IDs. (4) All the other API functions seem to try to do one specific task and leave it up to other functions to do their tasks. On point 4, publish() seems to be the most likely API call to time-out when the Spacewalk server is under high I/O (such as from several clients accessing it for updates). I believe this is partly because it is taking on too many things in a single API call.
This bug is still present in version 2.2
Spacewalk 2.8 (and older) has already reached it's End Of Life. Thank you for reporting this issue and we are sorry that we were not able to fix it before end of life. If you would still like to see this bug fixed and are able to reproduce it against current version of Spacewalk 2.9, you are encouraged change the 'version' and re-open it.