Description of problem: I re-sync the satellite capsule repo and sync was completed successfully w/ a few new packages. Later when I publish the associated CV and promoted it. However when I ran yum repolist on registered capsule , it was still showing the old packages. Looks like new rpms were not correctly published: On Satellite filesystem I see the updated packages under "/var/lib/pulp/content/units/rpm/" as below: -bash-4.2# find / -name satellite-capsule-6.2.7* /var/lib/pulp/content/units/rpm/0f/3bd1531109d30323715d950d98e4b7c55fc33b6de4db40e176b75c2bc7bdc9/satellite-capsule-6.2.7-1.0.el7sat.noarch.rpm But I don't see this in published CV 'rhel7_capsule_cv' under 'Library': -bash-4.2# cd /var/lib/pulp/published/yum/https/repos/Default_Organization/Library/rhel7_capsule_cv/content/dist/rhel/server/7/7Server/x86_64/sat-capsule/6.2/os/ -bash-4.2# ll | grep satellite-capsule-6.2.7 CV publish/promote was successful and we can see package count updated on UI. But actually no new package published/promoted to selected env. Version-Release number of selected component (if applicable): upgrade sat6.1.11 -> 6.2.z How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: newly synced packages should be published/promoted to next env Additional info:
As per dev investigation, issue seems to be related to repo publishing. the repo isn't auto publishing after syncing. just for reference, pasting the irc chat here: thank you Justin. <jsherrill> sghai: no not CV publishing, repo publshing, in pulp when you sync a repo its set to auto publish the yum metadata. in 6.1 we triggered it manaully so this auto publish was turned off, in 6.2 we turned it back on <jsherrill> and that turning back on isn't working correctly.
Opened PRs: https://gitlab.sat.lab.tlv.redhat.com/satellite6/katello-installer/merge_requests/84 https://gitlab.sat.lab.tlv.redhat.com/satellite6/katello/merge_requests/279 however i still need to chat with Chris about this issue
Verified this issue with sat6.2.8 snap2 Now I can successfully publish/promote the newly synced packages and packages are available under selected CV through filesystem: -bash-4.2# cd /var/lib/pulp/published/yum/https/repos/Default_Organization/Library/rhel7_capsule_cv/content/dist/rhel/server/7/7Server/x86_64/sat-capsule/6.2/os/ -bash-4.2# ll | grep satellite-capsule-6.2.7 lrwxrwxrwx. 1 apache apache 143 Feb 14 07:59 satellite-capsule-6.2.7-1.0.el7sat.noarch.rpm -> /var/lib/pulp/content/units/rpm/0f/3bd1531109d30323715d950d98e4b7c55fc33b6de4db40e176b75c2bc7bdc9/satellite-capsule-6.2.7-1.0.el7sat.noarch.rpm Also, similar packages I can fetch on registered capsule. Before: ========= repo id repo name status !rhel-7-server-rpms/x86_64 Red Hat Enterprise Linux 7 Server (RPMs) 13,578 !rhel-7-server-satellite-capsule-6.2-rpms/x86_64 Red Hat Satellite Capsule 6.2 (for RHEL 7 Server) (RPMs) 300 after: ====== repo id repo name status !rhel-7-server-rpms/x86_64 Red Hat Enterprise Linux 7 Server (RPMs) 13,578 !rhel-7-server-satellite-capsule-6.2-rpms/x86_64 Red Hat Satellite Capsule 6.2 (for RHEL 7 Server) (RPMs) 332 see the difference in capsule packages, before fix, count was 300 and after fix count is 332.
Workaround: On both the Satellite and the capsule, run: #this sets auto_publish to true mongo pulp_database --eval 'db.repo_distributors.update({"distributor_type_id": "yum_distributor"}, {"$set": {"auto_publish": true}}, {"multi": true});' #this causes pulp to actually sync the repository, forcing a publish mongo pulp_database --eval 'db.repo_importers.update({"scratchpad": {$ne: null}}, {$set: {"scratchpad.repomd_revision": null}}, {"multi":true})' And then re-sync the repositories on your Satellite, followed by a full capsule sync (if the problem is on the capusle as well)
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:0447