Bug 1098264 - Syncing yum repo does not decrement size_left or items_left within task if packages have already been synced in another repo
Syncing yum repo does not decrement size_left or items_left within task if pa...
Status: CLOSED DUPLICATE of bug 1095332
Product: Pulp
Classification: Community
Component: rpm-support (Show other bugs)
2.4.0
Unspecified Unspecified
medium Severity unspecified
: ---
: 2.4.0
Assigned To: pulp-bugs
pulp-qe-list
: Triaged
Depends On:
Blocks: 950743
  Show dependency treegraph
 
Reported: 2014-05-15 11:37 EDT by Justin Sherrill
Modified: 2014-08-19 23:31 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-05-15 18:59:21 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)
Task json (3.10 KB, text/plain)
2014-05-15 11:37 EDT, Justin Sherrill
no flags Details

  None (edit)
Description Justin Sherrill 2014-05-15 11:37:20 EDT
Created attachment 895993 [details]
Task json

Description of problem:

Currently sync tasks do not seem to be incrementing size_left, items_left, or rpm_done.

This occurs both in the progress report and the 'result'

      "content": {
        "size_total": 88162120, 
        "items_left": 186, 
        "items_total": 186, 
        "state": "FINISHED", 
        "size_left": 88162120, 
        "details": {
          "rpm_total": 186, 
          "rpm_done": 0, 
          "drpm_total": 0, 
          "drpm_done": 0
        }, 


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

pulp-server-2.4.0-0.13.beta.el6.noarch

How reproducible:
Always

Steps to Reproduce:
1.  Create a yum repo with a feed url
2.  Sync the repo
3.  Examine the sync task (pulp-admin tasks details --task-id=b16f4fe9-1343-468c-a6f9-3a356a003368)

Actual results:
size_left, items_left, and rpm_done 

Expected results:
size_left, items_left, and rpm_done should all decrement as the sync progresses and should be 0 (assuming it did not error)


Attached full task object
Comment 1 Justin Sherrill 2014-05-15 11:55:12 EDT
Hrmmm, this may be a little more odd than i thought.  Syncing a new repo the sync seems to just be complete randomly before it is done.  See:


    "details": {
      "content": {
        "size_total": 3286182868, 
        "items_left": 1671, 
        "items_total": 3480, 
        "state": "FINISHED", 
        "size_left": 1506688624, 
        "details": {
          "rpm_total": 3480, 
          "rpm_done": 1809, 
          "drpm_total": 0, 
          "drpm_done": 0
        }, 
        "error_details": []
      }, 


In this case the task was complete (in fact it went on to publish the distributors), but there were no errors.
Comment 2 Justin Sherrill 2014-05-15 11:58:17 EDT
but note in the scenario of comment #1, all 3480 packages did actually sync.  Looking at the repo's packages afterwards seems to indicate that.
Comment 3 Justin Sherrill 2014-05-15 12:23:24 EDT
Ahh, I think i've figured this out.  If the package has already been synced, it and thus the packages do not need to be imported the rom_done count and size_left count will not decrement.  

So the reproduction steps should be:

1.  Create Repo A with a feed URL
2.  Sync Repo A
3.  Create Repo B with the SAME feed URL
4.  Sync Repo B

Result:  Repo B's counts will not be decremented.
Comment 4 Sayli Karmarkar 2014-05-15 18:59:21 EDT
This is a dup of https://bugzilla.redhat.com/show_bug.cgi?id=1095332 and I am already close to fixing it. Basically when we remove packages which are already downloaded from the to_be_downloaded list, we were not updating the progress for new number and size of packages. That is why the size and number of packages are reducing for the packages getting downloaded but do not reach zero at the end.
Comment 5 Sayli Karmarkar 2014-05-15 19:00:15 EDT
Meant to close it as a dup, not NOTABUG.

*** This bug has been marked as a duplicate of bug 1095332 ***

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