Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 608657 - libsmbclient/samba3x tech-preview packages are not removed from the supplementary channel after an import on disconnected Satellite
libsmbclient/samba3x tech-preview packages are not removed from the supplemen...
Status: CLOSED CURRENTRELEASE
Product: Spacewalk
Classification: Community
Component: Server (Show other bugs)
1.1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Miroslav Suchý
Red Hat Satellite QA List
:
Depends On:
Blocks: space11 587550
  Show dependency treegraph
 
Reported: 2010-06-28 08:18 EDT by Miroslav Suchý
Modified: 2010-08-19 04:25 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 587550
Environment:
Last Closed: 2010-08-19 04:25:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Miroslav Suchý 2010-06-28 08:18:16 EDT
+++ 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:
Always

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:


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


sync_handlers.py:
def link_channel_packages(batch, strict=1):
    importer = packageImport.ChannelPackageSubscription(batch,
        diskImportLib.get_backend(),
        caller="satsync.linkPackagesToChannels", strict=strict)
    importer.run()
    importer.status()
    return importer

server/importlib/packageImport.py:
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. 

Cliff


--- 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 08:23:30 EDT
Option --consider-full implemented in commits 
357f4f02969c20ca16039fb1e65c6c831b025399
eb3be31dc6d547f891c246671cff1d7055d9c2d9
I verified that it works exactly as we expected.
Comment 2 Milan Zázrivec 2010-08-19 04:25:05 EDT
Spacewalk 1.1 has been released.

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