I wonder if this results from bug 591291 - Tomas?

This doesn't seem to be somehow connected with bug 591291. There're different API calls involved in every BZ and there doesn't seem to be a shared code.

If errata.applicableToChannels returns correct list of channels, it doesn't look like a problem in API.

However, I followed the reproducer, but didn't see the misbehavior.
1. I cloned the channel accrording to 1.)
2. I run a lighter export:
rhn-satellite-exporter --dir=clone-test-rhel-x86_64-server-5 --channel=clone-test-rhel-x86_64-server-5 --no-rpms --no-packages --no-kickstarts
3. erratum files look good and contain the correct channel list
in clone-test-rhel-x86_64-server-5/errata dir:

# zgrep RHSA-2010:0490-1 */*.xml.gz 
0/rhn-erratum-1520.xml.gz:<?xml version="1.0" encoding="UTF-8"?><rhn-satellite generation="2" version="3.5"><rhn-errata><rhn-erratum advisory="RHSA-2010:0490-1" org_id="" channels="clone-test-rhel-x86_64-server-5 rhel-x86_64-server-5" cve-names="CVE-2010-0542 CVE-2010-0540 CVE-2010-1748" packages="rhn-package-9524 rhn-package-9525 rhn-package-9526 rhn-package-9527 rhn-package-9528 rhn-package-9529" id="rhn-erratum-1520">

it looks like all the errata xml.gz files contain the correct channel list
# zgrep -l clone-test-rhel-x86_64-server-5 */*.xml.gz | wc -l
1532
# find -type f | wc -l
1532
# zgrep -l channels=\"clone-test-rhel-x86_64-server-5\ rhel-x86_64-server-5\" */*.xml.gz | wc -l
1532


Stephan, could you provide more detailed information, how to reproduce it?
Do you run the API as sat admin, or org admin?

hmm, this is strange. One difference is that I have more channels in my satellite.

I tried again with rhn-satellite-exporter --dir=/backup/dump/sat-exporter-test --channel=clone-test-rhel-x86_64-server-5 --no-rpms --no-packages --no-kickstarts

I'm analyzing the results with the attached script:

./errata-xml-parse-test.py /backup/dump/sat-exporter-test/errata clone-test-rhel-x86_64-server-5

results:
...
RHBA-2009:0220-2     4 False
RHBA-2009:1244-2     4 False
RHEA-2008:0370-7     5 False
Total Errata Files:  1552
Errata Files Parsed: 1552
Max. Channel Count:  8
Found Channel Label clone-test-rhel-x86_64-server-5: 6 times

./errata-xml-parse-test.py /backup/dump/sat-exporter-test/errata clone-test-rhel-x86_64-server-5 | fgrep True
RHSA-2010:0580-1     5 True
RHSA-2010:0585-1     4 True
RHBA-2010:0247-1     2 True
RHEA-2010:0136-1     5 True
RHBA-2009:1374-1     2 True
RHSA-2010:0578-1     8 True

Finally I found out that the problem is caused by rhn-satellite-exporter using outdated cached xml files in /var/cache/rhn/xml-errata/ via /usr/share/rhn/common/rhnCache.py

So if you now clone rhel-i386-server-5 to clone-test-rhel-i386-server-5 and run
rhn-satellite-exporter --dir=clone-test-rhel-i386-server-5
--channel=clone-test-rhel-i386-server-5 --no-rpms --no-packages
--no-kickstarts
you should see the same effect.

Shouldn't rhnCache.py invalidate outdated files once in a while?

Created attachment 436910 [details]
Script for parsing errata XML files generated by rhn-satellite-exporter

Since it looks like a backend issue, passing to Server component.

Stephan, I'm currently at the customer where you encountered this problem. I have done a couple of tests using the method described in comment #2.

As you already found out, the root cause is invalid data in /var/cache/rhn/xml-errata. The easy fix is to remove the old /var/cache/rhn/xml-errata directory, which is automatically recreated when rhn-satellite-exporter is run.

I've done various tests with different lists of errata for the same channel, and it looks like it's only the old xml-errata directory which prevented updates. I think some old Satellite version caused this problem, and once we let the latest Satellite 5.3 create the directory from scratch, it's good.

Correction for comment #6: The contents of /var/cache/rhn/xml-errata are not updated when we merge additional errata from the Red Hat into our clone channel. As a workaround, I'm now always deleting /var/cache/rhn/xml-errata before running rhn-satellite-exporter.

Hitting this bug at a major Australian retailer with 4 Satellites.
Trying the workaround now, will let you guys know how it goes.

Aurelien (GPS Sydney, AU)

Workaround seems to work fine to the customer.

Cheers,
Aurelien.

Fixed in spacewalk master by
commit 2989f2487a80ba2aeca1953e280671200d36e6e5
    620486 - errata xml caching doesn't work for cloned channels

Fixed spacewalk package: spacewalk-backend-1.5.10-1

Backported to SATELLITE-5.4 as
commit 7d7641c2ff7abe03031624f348de71a9d3c10d52
    620486 - errata xml caching doesn't work for cloned channels
   (cherry picked from commit 2989f2487a80ba2aeca1953e280671200d36e6e5)
   Conflicts:
        backend/satellite_tools/disk_dumper/dumper.py

Verified.

[root@ errata]#rhn-satellite-exporter --dir=clone-test-rhel-x86_64-server-5 --channel=clone-test-rhel-x86_64-server-5 --no-rpms --no-packages --no-kickstarts

[root@ errata]# find -type f | wc -l
1672

[root@ errata]# zgrep -l channels=\"clone-test-rhel-x86_64-server-5\.\*\ rhel-x86_64-server-5\.*\"  */*.xml.gz | wc -l
1672

Verified in stage w/ spacewalk-backend-1.2.13-52 -> release pending.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

https://rhn.redhat.com/errata/RHEA-2011-0875.html