Bug 608657 - libsmbclient/samba3x tech-preview packages are not removed from the supplementary channel after an import on disconnected Satellite
Summary: libsmbclient/samba3x tech-preview packages are not removed from the supplemen...
Alias: None
Product: Spacewalk
Classification: Community
Component: Server
Version: 1.1
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Miroslav Suchý
QA Contact: Red Hat Satellite QA List
Depends On:
Blocks: space11 587550
TreeView+ depends on / blocked
Reported: 2010-06-28 12:18 UTC by Miroslav Suchý
Modified: 2010-08-19 08:25 UTC (History)
6 users (show)

Clone Of: 587550
Last Closed: 2010-08-19 08:25:05 UTC

Attachments (Terms of Use)

Description Miroslav Suchý 2010-06-28 12:18:16 UTC
+++ This bug was initially created as a clone of Bug #587550 +++

Description of problem:
The import of RHEL5-Server-Supplementary content doesn't appear to be cleaning up the samba3x tech-preview packages.

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

How reproducible:

Steps to Reproduce:
1. Export the latest rhel-x86_64-server-supplementary-5 channel.
2. Import it on a Satellite which has old rhel-x86_64-server-supplementary-5 channel with the tech-preview packages like 'samba3x'
3. After a successful import these packages are not being removed.
4. Now, if you remove the rhel-x86_64-server-supplementary-5 channel from the importing satellite server and sync it from RHN Hosted, you will see that these packages are being removed.
Actual results:
After a successful import these tech-preview packages are not being removed.

Expected results:
satellite-sync should behave in the same manner on channel dumps as it behaves when we sync a channel from RHN Hosted.

Additional info:
A workaround is to remove the old supplementary channel using spacewalk-remove-channel and then sync it again from the channel dumps.

--- Additional comment from cperry@redhat.com on 2010-05-11 14:46:03 EDT ---

Looking at code snippets:

        uq_pkg_data = uq_packages.values()
        # check to make sure the orgs exported are valid
            if OPTIONS.mount_point:
                importer = sync_handlers.link_channel_packages(uq_pkg_data, strict=0)
                importer = sync_handlers.link_channel_packages(uq_pkg_data)

def link_channel_packages(batch, strict=1):
    importer = packageImport.ChannelPackageSubscription(batch,
        caller="satsync.linkPackagesToChannels", strict=strict)
    return importer

class ChannelPackageSubscription(GenericPackageImport):
    def __init__(self, batch, backend, caller=None, strict=0):
        # If strict, the set of packages that was passed in will be the only
        # one in the channels - everything else will be unlinked
        GenericPackageImport.__init__(self, batch, backend)
        self.affected_channels = []
        # A hash keyed on the channel id, and with tuples 
        # (added_packages, removed_packages) as values (packages are package
        # ids)

Basically since you are using a -m mount-point option we switch strict off - as such, we never make the channel content *exactly* match that of the dump your importing from, which is the default state we have for sat-sync off Hosted or with inter-satellite-sync. 

The *very* short term and hackish solution is if the customer is confident in his full dump that he is importing from, edit and flip the bit from 0 to 1 in line in satsync.py:

importer = sync_handlers.link_channel_packages(uq_pkg_data, strict=0)

Right now the assumed behavior for myself was:
1 - sat-sync, inter-sat-sync and full dumps - KEEP everything in sync
2 - incrementals - additive only

This is in fact incorrect, both incrementals and full dumps are - additive only. 


--- Additional comment from jpazdziora@redhat.com on 2010-05-27 08:25:59 EDT ---

Cliff, how about adding another option to satellite-sync

  --consider-full   When this option is used, the export being synced will be
                    considered to be a full export; any package in the channel
                    but not in the export will be deleted

which the customer could use if they were confident that what they have is in fact a full dump and not an incremental. That way, no chaneg would be needed in the export (dump) format.

And of course, all that this option would do would keep the strict value 1, even for imports of channel dumps.

(The description would need to match what strict actually does, so that's just the first shot.)

Comment 1 Miroslav Suchý 2010-06-28 12:23:30 UTC
Option --consider-full implemented in commits 
I verified that it works exactly as we expected.

Comment 2 Milan Zázrivec 2010-08-19 08:25:05 UTC
Spacewalk 1.1 has been released.

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