Hide Forgot
Created attachment 566125 [details] Sync errors sorted by type and time (/var/log/katello/production.log) Description of problem: After importing a custom manifest generated from access.qa.redhat.com, I perform a provider sync. Due to some errors in uploading content to the CDN, some of the package URLs result in incorrect permissions (e.g 403 Forbidden). It seems that the synchronization never completes (or takes *HOURS*) when 403's occur. I'm not sure if katello should be failing the synchronization sooner, or if it is retrying an expected number of times. Something seems inefficient in the handling of these errors, but I'm not clear where the fault is. Version-Release number of selected component (if applicable): * candlepin-0.5.22-1.el6.src.rpm * katello-0.1.300-1.el6.src.rpm * katello-certs-tools-1.0.2-2.el6.src.rpm * katello-cli-0.1.100-2.el6.src.rpm * katello-configure-0.1.100-7.el6.src.rpm * katello-httpd-ssl-key-pair-1.0-1.src.rpm * katello-qpid-broker-key-pair-1.0-1.src.rpm * katello-selinux-0.1.7-1.el6.src.rpm * katello-trusted-ssl-cert-1.0-1.src.rpm * pulp-0.0.267-2.el6.src.rpm How reproducible: * 3 of 3 attempts have highlighted this problem Steps to Reproduce: 1. ks provider update --name "Red Hat" --url http://cdn.rcm-qa.redhat.com 2. curl -o /tmp/manifest.zip "http://file.rdu.redhat.com/jlaska/manifests_accessqa.zip" 3. ks provider import_manifest --name "Red Hat" --file /tmp/manifest.zip 4. ks provider synchronize --name "Red Hat" Actual results: Progress: [##################################################] 100.0% Expected results: I'd expect the sync to complete, and report errors. Instead the sync remains at 100.00% and does not exit until the 403 permission problems are resolved on the server. Additional info: * How many times should katello/pulp retry downloading a rpm before moving on? the attached re-parse of /var/log/katello/production.log seems to indicate a high amount of retry.
Created attachment 566126 [details] katello-debug-20120227142624.tar.gz
The sync did complete ... it just takes *forever* Provider [ Red Hat ] synchronized With all these 403 errors encountered during synchronization ... should the sync have completed successfully?
The question for me on this issue is should the katello sync have returned a failed status if many of the CDN URL downloads were unsuccessful?
James - this does not change anything, the actual fix is delivered with the bug 798376.
QA note: To verify start a sync using the katello cli, break it and see if it correctly reports an error. In the production.log there should also be error message. This bug can be verified together with https://bugzilla.redhat.com/show_bug.cgi?id=798376
Hey Lukas, thanks for the updates ... I'm moving this to MODIFIED until the version referenced by fixed_in is included in an official rel-eng puddle. Moving to ON_QA before those conditions exists causes the bug to fall off the ACK viewer, and the Quality team to attempt to verify when the fix is not yet included in CloudForms proper.
mass move ON_QA after brewing
Verified: * candlepin-0.5.26-1.el6.noarch * candlepin-tomcat6-0.5.26-1.el6.noarch * katello-0.1.304-1.el6.noarch * katello-all-0.1.304-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.105-1.el6.noarch * katello-cli-common-0.1.105-1.el6.noarch * katello-common-0.1.304-1.el6.noarch * katello-configure-0.1.106-1.el6.noarch * katello-glue-candlepin-0.1.304-1.el6.noarch * katello-glue-foreman-0.1.304-1.el6.noarch * katello-glue-pulp-0.1.304-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.9-1.el6.noarch * pulp-1.0.0-5.el6.noarch * pulp-common-1.0.0-5.el6.noarch * pulp-selinux-server-1.0.0-5.el6.noarch