Bug 585901 - Java repodata generator does not recurse for comps file
Summary: Java repodata generator does not recurse for comps file
Alias: None
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Server
Version: 530
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Tomas Lestach
QA Contact: Pavel Kralik
Depends On:
Blocks: sat531-blockers
TreeView+ depends on / blocked
Reported: 2010-04-26 11:28 UTC by Jan Pazdziora
Modified: 2018-11-14 18:55 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-05-27 07:04:52 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2010:0443 0 normal SHIPPED_LIVE Red Hat Network Satellite bug fix update 2010-05-27 07:04:49 UTC

Description Jan Pazdziora 2010-04-26 11:28:03 UTC
Description of problem:

When we wrote the original comps-serving code for cloned channels (bug 457478 and bug 452046), we recursed through all the cloned-from channels, not just did look at the immediate predecesor.

When the code was rewritted to Java, this was lost.

Version-Release number of selected component (if applicable):

Satellite 5.3.x.

How reproducible:

Looking at code. Also, reports by users.

Steps to Reproduce:
1. Have Satellite and client system with RHEL 5 registered to it. Have the RHEL 5 channel synced.
2. Verify that the client can do yum clan all ; yum grouplist Core > /dev/null without error and check that /var/cache/yum/rhel-i386-server-5/repomd.xml contains group data that point to comps file, and that the comps file was retrieved as well.
3. Clone channel from that RHEL 5 channel and change the base channel to this new cloned one.
4. Repeat step 2 and verify that it still works.
5. Clone channel from that cloned channel and change the base channel to this new cloned one.
5. Repease step 2.
Actual results:

It fails, if you have Java repodata generator (the default).

It passes if you use Python.

Expected results:

It should work in all cases.

Additional info:

The problem is that while we have

    def get_comps_file(self):
        """ Return a file-like object of the comps.xml for the channel. """
        if self.channel.comps:
            comps_view = view.CompsView(self.channel.comps)
            return comps_view.get_file()
        elif comps_mapping.has_key(self.channel.label):
            comps_view = view.CompsView(Comps(None, 
                os.path.join(CFG.mount_point, comps_mapping[self.channel.label])))
            return comps_view.get_file()
            if self.channel.cloned_from_id is not None:
                log_debug(1, "No comps and no comps_mapping for [%s] cloned from [%s] trying to get comps from the original one." \
                          % ( self.channel.id, self.channel.cloned_from_id ))
                cloned_from_channel = rhnChannel.Channel().load_by_id(self.channel.cloned_from_id)
                cloned_from_channel_label = cloned_from_channel._row['label']
                return Repository(rhnChannel.channel_info(cloned_from_channel_label)).get_comps_file()
        return None

in Python's Repository class, so we effectively recurse, in Java, this was only written as

        if (compsMapping.containsKey(channel.getLabel())) {
            compsPath = compsMapping.get(channel.getLabel());
        else if (channel.isCloned()) {
            // If its a cloned channel see if we can get the comps
            // from the original channel.
            ClonedChannel clonedCh = (ClonedChannel) channel;
            Channel origChannel = clonedCh.getOriginal();
            compsPath = compsMapping.get(origChannel.getLabel());

        return compsPath;

No recursion here.

If would also like to point out that in Python, by default we get the comps information from the database from that cloned-from channel, not just the static mapping.

Comment 2 Tomas Lestach 2010-05-05 15:25:47 UTC
Recursion implemented for comps search.

spacewalk.git: 5b0da627a2788330dfd60ef04b072b4dea416d05

Comment 3 Tomas Lestach 2010-05-06 07:57:08 UTC
one more commit

spacewalk.git: 4145a5cdbaac43ebda4b4600af3dacf0a003a9c9

Comment 9 errata-xmlrpc 2010-05-27 07:04:52 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.