Bug 864034

Summary:	Grinder fails to report back to pulp about failed sync of a package out of entire repository
Product:	[Retired] Pulp	Reporter:	Bryan Kearney <bkearney>
Component:	user-experience	Assignee:	Pradeep Kilambi <pkilambi>
Status:	CLOSED NOTABUG	QA Contact:	Preethi Thomas <pthomas>
Severity:	unspecified	Docs Contact:
Priority:	high
Version:	1.1.0	CC:	ehelms, mmccune, omaciel, skarmark
Target Milestone:	---	Keywords:	Triaged
Target Release:	Sprint 41
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	861513	Environment:
Last Closed:	2012-10-22 17:43:48 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	861513
Bug Blocks:

Description Bryan Kearney 2012-10-08 12:13:15 UTC

+++ 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 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 16:03:29 UTC

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
<snip>
LOG.warn("ERROR: Response = %s fetching %s." % (status, fetchURL))
 return (BaseFetch.STATUS_ERROR, "HTTP status code of %s received for %s" % (status, fetchURL))
</snip>

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 17:43:48 UTC

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.