Description of problem: After replacing a component in a Composite Content View the Activation key still includes references to the old repositories. In the example below the composite content view has a component replaced changes the used repository from "HOICI-1_0_0-ci" to "HOICI-1_0_0-sp17". But as can be seen after a clean registering, the old content is still available. # subscription-manager register --org="Hilti" --activationkey="TestActKey" --force # yum repolist Loaded plugins: changelog, downloadonly, package_upload, product-id, security, subscription-manager This system is receiving updates from Red Hat Subscription Management. https://li-lc-1017.hag.hilti.com/pulp/repos/Hilti/Library/Test/custom/HOICI/HOICI-1_0_0-ci/repodata/repomd.xml: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found" Trying other mirror. Hilti_HOICI_HOICI-1_0_0-sp17 | 2.1 kB 00:00 Hilti_HOICI_HOICI-1_0_0-sp17/primary | 3.8 kB 00:00 Hilti_HOICI_HOICI-1_0_0-sp17 16/16 repo id repo name status Hilti_HOICI_HOICI-1_0_0-ci HOICI-1.0.0-ci 312 Hilti_HOICI_HOICI-1_0_0-sp17 HOICI-1.0.0-sp17 16 repolist: 328 Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Create Product TestProduct 2. Create repo TestRepoA in TestProduct 3. Create repo TestRepoB in TestProduct 4. Create Contentview TestViewA 5. Assign repository TestProduct/TestRepoA 6. Publish TestViewB 7. Create Contentview TestViewB 8. Assign repository TestProduct/TestRepoB 9. Publish TestViewB 10. Create Composite Content View TestComposite 11. Add Component TestViewA to TestComposite 12. Publish TestComposite 13. Create Activation Key TestActKey 14. Assign TestComposite to TestActKey 15. Assign Subscription TestProduct to TestActKey 16. Client: Register with subscription-manager register --org="MyOrg" --activationkey="TestActKey" --force 17. Client: List repos subscription-manager repos --list 18. Add Component TestViewB to TestComposite 19. Remove Component TestViewA to TestComposite 20. Publish TestComposite 21. Client: Register with subscription-manager register --org="MyOrg" --activationkey="TestActKey" --force 22. Client: List repos subscription-manager repos --list Actual results: The list contains also the obsolete (and not accessible) repositories of TestProduct/TestRepoA. Updating yum metaata fails, e.g. yum repolist Expected results: Only TestProduct/TestRepoB is availabel to the client yum repolist works Additional info:
Created attachment 995522 [details] Dynflow planning output The dynflow output shows: - 1 component is added with repo HOICI-1.0.0-sp17 - 1 component is removed with repo HOICI-1.0.0-ci - Candlepin update is still including 2 content_ids: content_ids: - '1421224072547' - '1424770949654' Analyzing the sourcecode of the publish action it comes from the following scenario: - repo HOICI-1.0.0-sp17 is already added during the planning to the environment - repo HOICI-1.0.0-ci is still kept in the environment, it will be removed later in the run - in the next steps of the planning phase the repos associated with the environment contains both HOICI-1.0.0-sp17 and HOICI-1.0.0-ci - later in the planning phase Candlepin SetContent gathering the repos to publish, it contains therefor both HOICI-1.0.0-sp17 and HOICI-1.0.0-ci Important to reproduce is to update the Composite ContentView with both an Add and Remove of repos.
Another thing that can be seen is the action Actions::Katello::ContentView::UpdateEnvironment is called twice: - from the Actions::Katello::Repository::Destroy that is called for each repo - directly from Actions::Katello::ContentView::Publish after finishing all actions The call from Actions::Katello::Repository::Destroy shall be prevented as the single finalization call from Publish will take care of it.
Created redmine issue http://projects.theforeman.org/issues/9566 from this bug
Upstream bug assigned to jsherril
Confirmed that the patch works
Moving to POST since upstream bug http://projects.theforeman.org/issues/9566 has been closed ------------- Justin Sherrill Applied in changeset commit:katello|dc0eff9c88866ea3f5acc2677086aecb3399e63d.
VERIFIED : # rpm -qa | grep foreman foreman-postgresql-1.7.2.14-1.el6_6sat.noarch rubygem-hammer_cli_foreman_bootdisk-0.1.2.5-1.el6_6sat.noarch foreman-gce-1.7.2.14-1.el6_6sat.noarch ruby193-rubygem-foreman-tasks-0.6.12.3-1.el6_6sat.noarch rubygem-hammer_cli_foreman-0.1.4.7-1.el6_6sat.noarch foreman-compute-1.7.2.14-1.el6_6sat.noarch ruby193-rubygem-foreman-redhat_access-0.1.0-1.el6_6sat.noarch rubygem-hammer_cli_foreman_discovery-0.0.1.4-1.el6_6sat.noarch foreman-selinux-1.7.2.13-1.el6_6sat.noarch foreman-libvirt-1.7.2.14-1.el6_6sat.noarch foreman-ovirt-1.7.2.14-1.el6_6sat.noarch ruby193-rubygem-foreman_bootdisk-4.0.2.10-1.el6_6sat.noarch ruby193-rubygem-foreman_gutterball-0.0.1.9-1.el6_6sat.noarch foreman-debug-1.7.2.14-1.el6_6sat.noarch rubygem-hammer_cli_foreman_tasks-0.0.3.3-1.el6_6sat.noarch qe-sat6-rhel66.usersys.redhat.com-foreman-proxy-1.0-2.noarch foreman-vmware-1.7.2.14-1.el6_6sat.noarch ruby193-rubygem-foreman_discovery-2.0.0.9-1.el6_6sat.noarch foreman-proxy-1.7.2.4-1.el6_6sat.noarch qe-sat6-rhel66.usersys.redhat.com-foreman-client-1.0-1.noarch qe-sat6-rhel66.usersys.redhat.com-foreman-proxy-client-1.0-1.noarch foreman-1.7.2.14-1.el6_6sat.noarch ruby193-rubygem-foreman_hooks-0.3.7-2.el6_6sat.noarch ruby193-rubygem-foreman_docker-1.2.0.7-1.el6_6sat.noarch
This bug is slated to be released with Satellite 6.1.
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/RHSA-2015:1592