Bug 1301736 - Repo syncs resulting in PLP0000: Importer indicated a failed response do not index successfully obtained packages
Repo syncs resulting in PLP0000: Importer indicated a failed response do not ...
Status: NEW
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Repositories (Show other bugs)
6.1.6
All Linux
unspecified Severity high (vote)
: Unspecified
: --
Assigned To: satellite6-bugs
Katello QA List
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-25 16:11 EST by Craig Donnelly
Modified: 2017-04-19 03:57 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
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 Craig Donnelly 2016-01-25 16:11:47 EST
Description of problem:

When syncing a custom repository (product), if there are some packages that fail to download we now receive the error:

PLP0000: Importer indicated a failed response.

The rest of the sync information is still there indicating successfully downloaded packages (if any) and how many failed.

For my example, I synced EPEL 5 and received:

New packages: 4941 (3.68 GB).
Failed to download 3296 packages.
PLP0000: Importer indicated a failed response.

When we goto the EPEL product and check this EPEL 5 repo now, it shows 0 packages and 0 errata available.

How reproducible: So far, 100%.


Steps to Reproduce:
1. Add custom product (Like EPEL).
2. Sync EPEL (typically, it will fail to download /all/ packages on the first sync, and you will see the results I have above.
3. Check product page under repo tab and view that it shows 0 packages in repo even though there were some successfully downloaded per the task data.

Actual results: Packages are not indexed after encountering a partial sync completion and do not show up under the product repo.


Expected results: Packages that were successfully synced should show up under the product.


Additional info: I was able to get some of the package count to show up after I ran a re-index following recieving this error during a sync of EPEL 5, although the number that appears under the product is smaller than the number the task reported to download successfully.
Comment 1 Craig Donnelly 2016-01-25 16:15:57 EST
This bug may relate to these two fixes that were implemented into Satellite 6:

https://github.com/Katello/katello/pull/5680
https://github.com/Katello/katello/pull/5567
Comment 2 Bryan Kearney 2016-07-26 15:06:03 EDT
Moving 6.2 bugs out to sat-backlog.
Comment 3 Michael Hrivnak 2016-12-05 15:03:30 EST
Brad, I think the component for this should not be Pulp. Perhaps you can find a better one for it?
Comment 4 Michael Hrivnak 2016-12-12 16:46:04 EST
I'm changing the component since the issue appears to be with how and when katello queries pulp. Let me know if there's anything to be done on the pulp side for this.
Comment 5 Brad Buckingham 2017-01-05 10:26:39 EST
Justin, with the changes that have gone in to Satellite 6.2, would the described behavior still exist?
Comment 6 Justin Sherrill 2017-01-05 14:06:58 EST
I believe this behavior still exists.  What works now on (some time before 6.2.6) is that re-syncing will properly re-index the content even if nothing changed on the 2nd sync.

We might have to think about this a bit, lets say I sync a repo and it syncs some of the rpms, but not all.  Does the metadata for that repo get generated? Should it?   

If it doesn't get generated (and thus the client will not see the new rpms), should we index them?
Comment 9 Michael Hrivnak 2017-01-05 14:50:12 EST
(In reply to Justin Sherrill from comment #6)
> We might have to think about this a bit, lets say I sync a repo and it syncs
> some of the rpms, but not all.  Does the metadata for that repo get
> generated? Should it?   

Yes it gets generated. Download errors are so common for yum repos that we just note the error in the task status, but the overall task succeeds, and a publish task gets queued as normal.

You can know for sure if new metadata gets generated based on whether a publish task gets queued and succeeds.

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