[Pulp-list] Package Upload Questions

[Pradeep Kilambi]

On 06/16/2011 09:16 AM, Jay Dobies wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> This is a follow up to the discussion yesterday of what constitutes an
> error for package upload. Right now I'm mainly concerned with what the
> RHUI interface is going to look like. I want to make sure we handle
> anything the server reports as an error and shows the user the right
> message. Here's the code I'm using to upload packages. It pretty much
> just uses the code the CLI uses.
>
>
>          # Upload the bits to the Pulp server
>          upload_id = self.upload_api.upload(filename)
>
>          # Tell the Pulp server that an RPM was uploaded
>          metadata = pulp.client.utils.processFile(filename)
>          uploaded = self.upload_api.import_content(metadata, upload_id)
>
>          # Associate the package with all specified repos
>          for repo_id in repo_ids:
>              self.repo_api.add_package(repo_id, [uploaded['id']])
>
>
> So for the following questions, can you let me know what the behavior is
> and which of the calls I'm making would throw the exception if one occurs?

There are two steps here,

* uploading the bits, here we check to make sure the pkg with same nvrea 
+ checksum exists if not we log an error and return a None instead of 
pkg object:

log.error("Package %s Already Exists on the server skipping upload." % 
pkgname)

which is not what you saw, now the second step is the associations, the 
error you're seeing should happen in the association phase

"Package with same filename [%s] already exists in repo [%s]"

> - - Upload the same package to the same repo it was uploaded to before.

both the step will log an error message, so basically a noop in the end.

> - - Upload the the same package name but different bits (checksum is
> different) to the same repo it was uploaded to before.

this should succeed in both steps.

> - - Upload the same package (and bits) but this time to a different repo.

in this case, the first step will raise an error messgae on server and 
skips writing the bits to filesystem.
The second step should succeed.

Considering the above cases, we're not necessarily raising an exception, 
we're just returning back None/an error message vs a valid pkg object. 
Its probably ok to change log.error to log.info or warning for first 
step where we're skipping the bits. But in second case, i would prefer a 
log.error as we send that back to client

~ Prad