Bug 858398 - Sync UI says "Error syncing!" But Notifications UI indicates successful sync.
Sync UI says "Error syncing!" But Notifications UI indicates successful sync.
Status: CLOSED WONTFIX
Product: Red Hat Satellite 6
Classification: Red Hat
Component: WebUI (Show other bugs)
6.0.0
Unspecified Unspecified
unspecified Severity unspecified (vote)
: Unspecified
: --
Assigned To: Katello Bug Bin
Corey Welton
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-18 17:13 EDT by Corey Welton
Modified: 2014-03-18 13:37 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-03-18 13:37:57 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Corey Welton 2012-09-18 17:13:35 EDT
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.
Comment 2 Mike McCune 2014-03-18 13:37:57 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.