[Pulp-list] Package Upload Questions

[Jay Dobies]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>>          # 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:

I'm not sure I fully follow what you're saying (I can't tell what's the
result of the same NVERA v. the where the checksum plays into it). Is it:

- - If the same NVREA exists, we return None

or

- - If the same NVREA exists with the same checksum, we return None

or

- - If the same NVERA exists with a different checksum, we return None


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

I'm more concerned with what's returned to the API caller for now, but
since we're talking about the log messages, does it skip the upload only
if the checksums are different?

> 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]"

Ok, I get that we log it as an error on the server, but what about the
API caller? Is an exception thrown?

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

So it's a no-op, logs an error on the server, but what is returned to
the caller? Can the caller distinguish this case from the case where the
upload itself failed?

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

I'm confused what you mean by succeed. Above you mention that we log an
error if you try to associate a package with a repo if that association
already exists, but that's what's going on in this case ("same repo it
was uploaded to before") and you say it succeeds.

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

I'm guessing when you say it raises an error message on the server, you
mean logs an error and doesn't raise the exception to the caller, right?
I'm also guessing based on the rest of this e-mail that None is returned
to the caller.

In such a case, how will the second step ever succeed? The repo
add_package call takes the uploaded package ID as the parameter, but if
we return None how is the user supposed to get that in this case?

> Considering the above cases, we're not necessarily raising an exception,
> we're just returning back None/an error message 

I don't understand the distinction between "raising an exception" and
"returning back an error message". Are you saying that they may get back
a string describing the error instead of having an exception thrown? How
do they differentiate that from the upload ID that's normally returned?

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

Let's hold off on the server-side logging discussion until it's more
clear how the caller API functions. The server-side logging is secondary
compared to the user experience of using RHUI in these cases.

> ~ Prad
> 
> 
> 
> 
> 
> _______________________________________________
> Pulp-list mailing list
> Pulp-list at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-list


- -- 
Jay Dobies
RHCE# 805008743336126
Freenode: jdob @ #pulp
http://pulpproject.org | http://blog.pulpproject.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJN+kDGAAoJEOMmcTqOSQHCMF4H/0vRNGB1zylSN/3N1kkfw2Cq
lDZnQbX+3k7FXIqs3JrrVItyEo90WeLrVY7p433XzQnjMPjmPn2PKP8nDmv4F9nj
Y71oxSY7e1BtOWwHbKPRaM59qhgIB0p9HVYlkXt2Yzxuu5Km85DldNHHfKQTfHH0
0ZQR5DCPihpO7+kGvHX29skQ3XAxCj4Ca7oruRo6PKVBQTbZToSdaNESxY9tujuI
vyRCL4Eq97vK8EwbejoSELNY8tG7wdI/xpdDF4edJjfNzvyvMaiDL0bAoKRskhJB
1xXNuHa6WzBe/OvEtJ8ErEcu1vthWz3mmdiHNhm/57Ks8+czGJNtg9JxSz7J/go=
=CmlR
-----END PGP SIGNATURE-----