Bug 864034 - Grinder fails to report back to pulp about failed sync of a package out of entire repository
Grinder fails to report back to pulp about failed sync of a package out of en...
Product: Pulp
Classification: Community
Component: user-experience (Show other bugs)
Unspecified Unspecified
high Severity unspecified
: ---
: Sprint 41
Assigned To: Pradeep Kilambi
Preethi Thomas
: Triaged
Depends On: 861513
  Show dependency treegraph
Reported: 2012-10-08 08:13 EDT by Bryan Kearney
Modified: 2013-09-09 12:34 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 861513
Last Closed: 2012-10-22 13:43:48 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Bryan Kearney 2012-10-08 08:13:15 EDT
+++ This bug was initially created as a clone of Bug #861513 +++

Description of problem:

While verifying https://bugzilla.redhat.com/show_bug.cgi?id=791252, I followed the steps mentioned in the linked BZ (https://bugzilla.redhat.com/show_bug.cgi?id=767281) and moved a package from the custom repository as my sync was taking place. Grinder log shows a WARNING when it could not get to the package that got removed, but otherwise, the repository was synced and the web ui displayed a successful message. Katello seems to listen to pulp errors only, and as grinder does not pass this warning back to pulp, Katello cannot report that even though the sync process completed, there were missing packages.

The solution may be to make pulp aware of this case so that Katello can handle it properly.

Version-Release number of selected component (if applicable):

* 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-9.el6cf.noarch
* katello-all-1.1.12-9.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-5.el6cf.noarch
* katello-cli-common-1.1.8-5.el6cf.noarch
* katello-common-1.1.12-9.el6cf.noarch
* katello-configure-1.1.9-4.el6cf.noarch
* katello-glue-candlepin-1.1.12-9.el6cf.noarch
* katello-glue-pulp-1.1.12-9.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

How reproducible:

Steps to Reproduce:
1. Create a repository with a good number of packages
2. Sync it and during the process, remove one or more packages from the repository
3. See more details in the following BZ: https://bugzilla.redhat.com/show_bug.cgi?id=767281
Actual results:

Expected results:

Additional info:

--- Additional comment from pm-rhel@redhat.com on 2012-09-28 17:54:12 EDT ---

Since this issue was entered in bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.
Comment 1 Pradeep Kilambi 2012-10-17 12:03:29 EDT
hmm reading through the referenced bug(767281), I assume we're talking about the retry warning from comment https://bugzilla.redhat.com/show_bug.cgi?id=767281#c1 . The retry warning is legitimate as the job of that thread to download the removed package is done and there are no more retries left. If you notice, after the retry warning, we show a 404 warning. Even though its logged as a warning in the grinder.log, the fetch call returns an error here
LOG.warn("ERROR: Response = %s fetching %s." % (status, fetchURL))
 return (BaseFetch.STATUS_ERROR, "HTTP status code of %s received for %s" % (status, fetchURL))

Did you guys look at the sync report? So from what i see the error should be in the sync report. Katello should look at the report and determine how they like to present this to the end user.
Comment 2 Eric Helms 2012-10-22 13:43:48 EDT
After some investigation, this issue is a bug in the way Katello is handling pulp responses after a sync and is therefore not a pulp issue. See https://bugzilla.redhat.com/show_bug.cgi?id=861513 for further information and resolution.

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