Bug 500505

Summary: Return type mismatch for packages.findByNvrea
Product: Red Hat Satellite 5 Reporter: Sayli Karmarkar <skarmark>
Component: APIAssignee: Brad Buckingham <bbuckingham>
Status: CLOSED CURRENTRELEASE QA Contact: Sayli Karmarkar <skarmark>
Severity: medium Docs Contact:
Priority: low    
Version: 530CC: cperry, ssalevan
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: sat530 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-09-10 19:55:38 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 456996    

Description Sayli Karmarkar 2009-05-12 22:47:52 UTC
Description of problem:
packages.findByNvrea is returning list of packages but the docs say it returns one package (struct and not List of structs).

Comment 1 Clifford Perry 2009-05-13 14:01:03 UTC
Sounds like a possible bug. Can you give a specific example of input you did for the call and then the output. A package Name-Version-Release-Epoch-Arch *should* be unique for Satellite, unless you flip the 'enable_nvrea=0' within rhn.conf to 1 (which is default in Spacewalk). 

So, for Spacewalk - this API returning multiple packages sounds correct, in Satellite it should be a single package by default. 

Either way - I agree with bug report, sounds like that the API call is doing the right thing, we just need to update the doc associated with the call. 

Cliff

Comment 3 Sayli Karmarkar 2009-05-13 15:36:10 UTC
(In reply to comment #1)
> Sounds like a possible bug. Can you give a specific example of input you did
> for the call and then the output. 

>>> server.packages.findByNvrea(key, "zip", "2.31", "1.2.2", "", "i386")

[{'arch_label': 'i386', 'epoch': '', 'version': '2.31', 'last_modified': <DateTime u'20070308T00:00:00' at -48359294>, 'provider': 'Unknown', 'release': '1.2.2', 'path': 'redhat/NULL/640/zip/2.31-1.2.2/i386/640d994ad438d014e828c07c4426d138/zip-2.31-1.2.2.i386.rpm', 'id': 584, 'name': 'zip'}]

So, basically for satellite it IS returning unique package but as a list of one package instead of struct of details of that unique package.  

> A package Name-Version-Release-Epoch-Arch
> *should* be unique for Satellite, unless you flip the 'enable_nvrea=0' within
> rhn.conf to 1 (which is default in Spacewalk). 
> 
> So, for Spacewalk - this API returning multiple packages sounds correct, in
> Satellite it should be a single package by default. 
> 
> Either way - I agree with bug report, sounds like that the API call is doing
> the right thing, we just need to update the doc associated with the call. 
> 
> Cliff  


Yup. If api is doing the right thing of returning list of one package, then return values in the doc should be updated. Also description of the api should be changed from "Lookup the details for the package with the given name, version, release, architecture label, and (optionally) epoch" to something like "List the details for packages with given name, version, release, architecture label, and (optionally) epoch". 

~SayliK

Comment 4 Brad Buckingham 2009-05-13 15:57:45 UTC
The return should be a list, so an update to the doc is necessary.  Possibly someone updated the API to handle the Spacewalk case, but forgot to update the docs.

Comment 5 Brad Buckingham 2009-06-05 16:19:53 UTC
master git commit: c1b011443463f9ae3f4f9a2ce386005b1b49f27e
vader git commit: 34bbc2fb586e92a87effb661ce47a0881cd501f1

Comment 6 Sayli Karmarkar 2009-06-12 18:04:03 UTC
verified.

Comment 7 Steve Salevan 2009-08-26 19:14:27 UTC
RELEASE_PENDING from latest Stage build...  docs appropriately updated to reflect list instead of struct.

Comment 8 Brandon Perkins 2009-09-10 19:55:38 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-1434.html