Bug 962922 - errata upload improperly handles IOError
errata upload improperly handles IOError
Product: Pulp
Classification: Community
Component: user-experience (Show other bugs)
Unspecified Unspecified
low Severity unspecified
: ---
: 2.4.0
Assigned To: Michael Hrivnak
Preethi Thomas
: Triaged
Depends On:
  Show dependency treegraph
Reported: 2013-05-14 15:08 EDT by Michael Hrivnak
Modified: 2014-08-09 02:55 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-08-09 02:55:12 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 Michael Hrivnak 2013-05-14 15:08:00 EDT
Description of problem:

When creating an errata for upload such as the example here: https://pulp-rpm-user-guide.readthedocs.org/en/pulp-2.1/recipes.html#create-your-own-errata

... if one of the CSV files does not exist on disk, odd things happen. The worst is that an upload call is made to the server anyway, and the "metadata" field (which should be a dict full of metadata) has the integer value 74.

"Where does 74 come from" you ask? Funny story. When a function returns an error code in python instead of raising an exception, misunderstandings can happen. In this case, a function "generate_metadata" is supposed to return a dictionary with metadata, but if an error happens, it returns an integer error code. It so happens that "os.EX_IOERR" equals 74.


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

How reproducible:

Assuming a repository exists with the name "repo" and the CSV files listed below do not exist...

pulp-admin rpm repo uploads erratum --erratum_id=DEMO_ID_1 \
  --title="1: pulp-test-package bit conservation" \
  --description="1: pulp-test-package now conserves your precious bits." \
  --version=1 --release="el6" --type="bugzilla" --status="final" \
  --updated="`date`" --issued="`date`" --reference-csv=references.csv \
  --pkglist-csv=package_list.csv --from=pulp-list@redhat.com --repo-id=repo
You can see in ~/.server_calls.log that the "metadata" field sent to the server equals "74".

On 2.1.1-1, a friendly "package_list.csv file not found" type error is actually printed to the user's terminal. None the less, it shouldn't be making a server call at all in this case.

On 2.2, the friendly error message is gone, and this generic message appears instead:

"The web server reported an error trying to access the Pulp application. The
likely cause is that the pulp-manage-db script has not been run prior to
starting the server. More information can be found in Apache's error log file on
the server itself."

In either case, the error work flow needs to be fixed, and probably the error message delivery will take care of itself. Generally speaking, this is why we should stick to the python way of conveying errors with exceptions.
Comment 1 Michael Hrivnak 2014-05-13 14:18:02 EDT
It looks like this has been fixed at some point. On 2.4, I see an error message "Package list CSV file [package_list.csv] not found"
Comment 2 Preethi Thomas 2014-06-02 15:29:35 EDT
[root@hp-dl380pgen8-01 ~]# rpm -qa pulp-server
[root@hp-dl380pgen8-01 ~]# 

[root@hp-dl380pgen8-01 ~]# pulp-admin rpm repo uploads erratum --erratum-id=DEMO_ID_1   --title="1: pulp-test-package bit conservation"   --description="1: pulp-test-package now conserves your precious bits."   --version=1 --release="el6" --type="bugzilla" --status="final"   --updated="`date`" --issued="`date`" --reference-csv=references.csv   --pkglist-csv=package_list.csv --from=pulp-list@redhat.com --repo-id=repo
                              Unit Upload

Extracting necessary metadata for each request...
Package list CSV file [package_list.csv] not found

... completed
Comment 3 Randy Barlow 2014-08-09 02:55:12 EDT
This has been fixed in Pulp 2.4.0-1.

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