Description of problem: User1 has a Manifest1 with access to Product1 and imports it into Org1. User2 has (different) Manifest2 which also happens to have access to Product1. When User2 tries to import Manifest2 into Org2, both web ui and cli state that he cannot import it as that product is already imported. To me this is a bug because it is very likely that this scenario could happen with high frequency in an enterprise environment, with several different groups using their own manifests that have access to the same channels. Version-Release number of selected component (if applicable): * candlepin-0.5.26-1.el6.noarch * candlepin-tomcat6-0.5.26-1.el6.noarch * katello-0.1.306-1.el6.noarch * katello-all-0.1.306-1.el6.noarch * katello-candlepin-cert-key-pair-1.0-1.noarch * katello-certs-tools-1.0.4-1.el6.noarch * katello-cli-0.1.107-1.el6.noarch * katello-cli-common-0.1.107-1.el6.noarch * katello-common-0.1.306-1.el6.noarch * katello-configure-0.1.104-1.el6.noarch * katello-glue-candlepin-0.1.306-1.el6.noarch * katello-glue-foreman-0.1.306-1.el6.noarch * katello-glue-pulp-0.1.306-1.el6.noarch * katello-qpid-broker-key-pair-1.0-1.noarch * katello-qpid-client-key-pair-1.0-1.noarch * katello-selinux-0.1.8-1.el6.noarch * pulp-1.0.0-8.el6.noarch * pulp-common-1.0.0-8.el6.noarch * pulp-selinux-server-1.0.0-8.el6.noarch How reproducible: Steps to Reproduce: 1. Run the attached script. 2. 3. Actual results: User2 cannot import Manifest2 Expected results: Additional info:
can you attach the manifests you used in this bug?
The import fails due to the following constraint in cp_content: "cp_content_label_key" UNIQUE, btree (label) If we remove that, I believe the main ramification would be that we need to append something to the repo name during cert generation in order to avoid having duplicate repo names in redhat.repo.
Products and content are supposed to be global, so these subsequent imports should be succeeding without creating a second copy of the product or it's content. It should just realize the content already exists and re-use/update it, not sure how this was missed.
Created attachment 573376 [details] catalina.out Candlepin logging from catalina.out
1. As the admin user I created the Pepsi organization (with Library --> Dev1 environments) 2. Imported manifest1 with access to some RHEL products. 3. Synced and promoted RHEL 6Server x86_64 RPMs to Dev1 environment (Library -> Dev1) 4. Added 1 more product and created manifest2 and imported it. 5. Added 2 more products and created manifest3 and imported it. 6. Created the Melitta organization (with Library --> Dev1 environments) 7. Imported manifest4, which was created from a different distributor, which failed with "This distributor has already been imported by another owner" tomcat error shows: Caused by: java.sql.BatchUpdateException: Batch entry 0 insert into cp_content (created, updated, contentUrl, gpgUrl, label, metadataExpire, name, releaseVer, requiredTags, type, vendor, id) values ('2012-04-18 15:26:09.843000 -04:00:00', '2012-04-18 15:26:09.843000 -04:00:00', '/content/beta/rhel/server/6/$releasever/$basearch/supplementary/source/iso', 'http://', 'rhel-6-server-supplementary-beta-src-isos', '86400', 'Red Hat Enterprise Linux 6 Server - Supplementary Beta (Source ISOs)', NULL, 'rhel-6-server', 'file', 'Red Hat', '678') was aborted. Call getNextException to see the cause.
The issue has to do with old manifests, somewhere along the line content 678 had it's "label" changed, the two values in question were: rhel-6-server-supplementary-beta-source-isos rhel-6-server-supplementary-beta-src-isos When Candlepin is doing it's import, it is checking if content already exists by looking for it by *label*, which in this case tells us it does not exist, but it actually does if the older one was imported previously, and thus content ID 678 can't be inserted into the db. We should be using content ID to look up content as this will never change. Also, Importer is reporting any constraint exception as "distributor already in use", which is totally inaccurate and misleading. Fixed for both coming soon.
The content label changing fix is in candlepin.git master: cf9ec25ccb6f97b46cc7162329f0937090e72fd2 Fixing the distribution error message has also been corrected and waiting for approval, but will handle this outside of this bug.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: See comment#23 for proposed release note
*** Bug 818682 has been marked as a duplicate of this bug. ***
Release Note added. Link: http://documentation-stage.bne.redhat.com/docs/en-US/CloudForms/1.0/html-single/Release_Notes/index.html#sect-Release_Notes-System_Engine-System_Engine_Considerations-known_issues_16 Regards, Shikha
(In reply to comment #26) > Release Note added. Link: > > http://documentation-stage.bne.redhat.com/docs/en-US/CloudForms/1.0/html-single/Release_Notes/index.html#sect-Release_Notes-System_Engine-System_Engine_Considerations-known_issues_16 Please note, the proposed release note has a typo ... > "Customers installing Cloudforms 1.0 should generate and download new > Subscription Manifests from the Red Hat Customer Portal before importing into > the Red Hat Content Provider. This will ensure taht they have the latest and > ^^^^^^ > most up to date subscription data and will avoid issues with invalid data.
Fixed the typo. Link: http://documentation-stage.bne.redhat.com/docs/en-US/CloudForms/1.0/html-single/Release_Notes/index.html#sect-Release_Notes-System_Engine-System_Engine_Considerations-known_issues_16 Regards, Shikha
Verified using: * candlepin-0.7.8-1.el6cf.noarch * candlepin-selinux-0.7.8-1.el6cf.noarch * candlepin-tomcat6-0.7.8-1.el6cf.noarch * katello-1.1.12-7.el6cf.noarch * katello-all-1.1.12-7.el6cf.noarch * katello-candlepin-cert-key-pair-1.0-1.noarch * katello-certs-tools-1.1.8-1.el6cf.noarch * katello-cli-1.1.8-4.el6cf.noarch * katello-cli-common-1.1.8-4.el6cf.noarch * katello-common-1.1.12-7.el6cf.noarch * katello-configure-1.1.9-3.el6cf.noarch * katello-glue-candlepin-1.1.12-7.el6cf.noarch * katello-glue-pulp-1.1.12-7.el6cf.noarch * katello-qpid-broker-key-pair-1.0-1.noarch * katello-qpid-client-key-pair-1.0-1.noarch * katello-selinux-1.1.1-1.el6cf.noarch * pulp-1.1.12-1.el6cf.noarch * pulp-common-1.1.12-1.el6cf.noarch * pulp-selinux-server-1.1.12-1.el6cf.noarch
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. http://rhn.redhat.com/errata/RHSA-2012-1543.html