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.

https://github.com/pulp/pulp_rpm/blob/pulp-2.1/pulp_rpm/src/pulp_rpm/extension/admin/upload/errata.py#L144


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


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 --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.