Description of problem: It is possible -- somehow -- to have the sync UI tell the user that there was a problem with the sync, while at the same time the Notifications UI says repo synced successfully. This may be a dupe, but I wasn't able to find the an original bz. I don't *think* it is the same thing as bug #753128 - but if it is, that bug fails. Version-Release number of selected component (if applicable): CloudForms System Engine Version: 1.1.12-7.el6cf How reproducible: Unsure Steps to Reproduce: 1. Create a Provider, "Fedora", a Product, "Fedora 16", and a repo, "Fedora 16 x86_64" with a URL of http://download.fedoraproject.org/pub/fedora/linux/releases/16/Everything/x86_64/os/ 2. Attempt to sync this repo. It will take a very long time (and be sure you have enough disk space) 3. Wait for completion and/or fail. 4. Observe Sync UI 5. Observe User Notifications UI. Actual results: * Within the sync UI itself, user gets "Error syncing!" * Within the User Notifications UI, user gets "Repository 'Fedora 16 - x86_64' finished syncing successfully." Expected results: * User should get either a success or a fail in both locations, not one of each. Additional info: It is exceedingly difficult to find any error in the logs, though something did bubble up to the katello logs. * We are told of one error: 2012-09-18 11:41:04,037 4449:140498962470656: grinder.ParallelFetch:INFO: ParallelFetch:253 ParallelFetch: 32029 items successfully processed, 32029 downloaded, 1 items had errors * Though grinder log apparently sees three (or six) [root@se-rhelbox pulp]# cat grinder.log|grep ERROR 2012-09-18 11:21:23,987 4449:140499266545408: grinder.BaseFetch:ERROR: activeobject:162 gmime-2.5.8-1.fc16.x86_64.rpm size mismatch, read: 0 bytes, was expecting 170796 bytes 2012-09-18 11:21:25,823 4449:140498951980800: grinder.BaseFetch:ERROR: activeobject:162 pl-static-5.10.2-7.fc16.1.x86_64.rpm size mismatch, read: 0 bytes, was expecting 458693 bytes 2012-09-18 11:21:25,824 4449:140498972960512: grinder.BaseFetch:ERROR: activeobject:162 libopensync-plugin-gpe-0.22-4.fc15.x86_64.rpm size mismatch, read: 0 bytes, was expecting 26488 bytes 2012-09-18 11:21:40,545 4449:140499266545408: grinder.BaseFetch:ERROR: activeobject:162 gmime-2.5.8-1.fc16.x86_64.rpm size mismatch, read: 0 bytes, was expecting 170796 bytes 2012-09-18 11:21:51,256 4449:140498951980800: grinder.BaseFetch:ERROR: activeobject:162 sems-mailbox-1.4.2-1.fc16.x86_64.rpm size mismatch, read: 0 bytes, was expecting 370993 bytes 2012-09-18 11:21:51,334 4449:140498972960512: grinder.BaseFetch:ERROR: activeobject:162 libopensync-plugin-gpe-0.22-4.fc15.x86_64.rpm size mismatch, read: 0 bytes, was expecting 26488 bytes * Pulp log itself doesn't show any real errors: 2012-09-18 12:42:07,260 4449:140498962470656: pulp.server.tasking.task:INFO: task:454 Task succeeded: Task 5f5c4d05-019a-11e2-819d-525400a5f611: _sync(Test_Org_1347934614-Fedora_16-Fedora_16_-_x86_64, synchronizer=<pulp.server.api.synchronizers.YumSynchronizer object at 0x7fc87c89b2d0>, skip={}, max_speed=None, threads=4, progress_callback=<bound method RepoSyncTask.progress_callback of <pulp.server.api.repo_sync_task.RepoSyncTask object at 0x7fc87c89b250>>) 2012-09-18 13:00:02,706 4449:140498972960512: pulp.server.tasking.task:INFO: task:454 Task succeeded: Task ae1b3161-0106-11e2-96e2-525400a5f611: cull_audited_events(, ) * Error that bubbled up to production.log: [DEBUG: 2012-09-17 16:31:03 #4131] Processing response: 200 [DEBUG: 2012-09-17 16:31:03 #4131] Resource GET request: /candlepin/owners/ACME_Corporation/servicelevels [DEBUG: 2012-09-17 16:31:03 #4131] Processing response: 200 [ERROR: 2012-09-18 14:03:06 #4272] Task PulpSyncStatus (8) is in error state Prad has told me that if pulp sees an error such as the package mismatches above, it will re-attempt to retrieve those packages later. So maybe the error refers to one of these packages, and perhaps on this package later succeeded. I have no idea... and the webui isn't clear either as to whether the sync was actually successful.
This bug was closed because of a lack of activity. If you feel this bug should be reconsidered for attention please feel free to re-open the bug with a comment stating why it should be reconsidered.