Bug 839960

Summary: system.listLatestUpgradablePackages suggests not newest only packages
Product: [Community] Spacewalk Reporter: Jan Hutař <jhutar>
Component: APIAssignee: Tomas Lestach <tlestach>
Status: CLOSED CURRENTRELEASE QA Contact: Red Hat Satellite QA List <satqe-list>
Severity: low Docs Contact:
Priority: unspecified    
Version: 1.8CC: franky, ldelhage, mmello, mmraka, prakash.velayutham
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: spacewalk-java-1.9.2-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 854139 (view as bug list) Environment:
Last Closed: 2013-03-06 18:35:27 UTC Type: Bug
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: 854139, 917805    

Description Jan Hutař 2012-07-13 10:00:44 UTC
Description of problem:
API call system.listLatestUpgradablePackages suggests not newest only packages. Both `yum list updates` and WebUI -> system -> Software -> Packages -> Upgrade shows only newest one.


Version-Release number of selected component (if applicable):
SWnightly as of yesterday
spacewalk-java-1.8.107-1.el5


How reproducible:
always


Steps to Reproduce:
1. wget 3 versions of some package, I had:
   drupal7-7.12-1.el5.noarch.rpm  drupal7-7.14-1.el5.noarch.rpm
   drupal7-7.14-2.el5.noarch.rpm
2. push them to some channel your system is subscribed to
3. Install oldest one (7.12-1.el5 in my case)
4. Confirm that `yum list updates | grep drupal7` and WebUI -> system -> Software -> Packages -> Upgrade only recommends newest (7.14-2.el5)
5. Check API call recommends two:
# python
Python 2.4.3 (#1, Dec 22 2011, 12:12:24) 
[GCC 4.1.2 20080704 (Red Hat 4.1.2-50)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import xmlrpclib, pprint
>>> client = xmlrpclib.Server('https://<fqdn>/rpc/api', verbose=0)
>>> key = client.auth.login('<user>', '<password>')
>>> pprint.pprint(client.system.listLatestUpgradablePackages(key, 1000010366))


Actual results:
[{'arch': 'noarch',
  'from_epoch': ' ',
  'from_release': '1.el5',
  'from_version': '7.12',
  'name': 'drupal7',
  'to_epoch': ' ',
  'to_package_id': 7761,
  'to_release': '2.el5',
  'to_version': '7.14'},
 {'arch': 'noarch',
  'from_epoch': ' ',
  'from_release': '1.el5',
  'from_version': '7.12',
  'name': 'drupal7',
  'to_epoch': ' ',
  'to_package_id': 7760,
  'to_release': '1.el5',
  'to_version': '7.14'}]


Expected results:
[{'arch': 'noarch',
  'from_epoch': ' ',
  'from_release': '1.el5',
  'from_version': '7.12',
  'name': 'drupal7',
  'to_epoch': ' ',
  'to_package_id': 7761,
  'to_release': '2.el5',
  'to_version': '7.14'}]


Additional info:
If this is expected, would it be possible to enhance documentation for the function so it warns about that?

Comment 1 Jan Hutař 2012-07-13 10:02:44 UTC
This was first reported by Prakash Velayutham in the mailing list:

https://www.redhat.com/archives/spacewalk-list/2012-July/msg00029.html

Comment 2 Prakash Velayutham 2012-07-31 10:00:09 UTC
Just wanted to know if there has been any status updates to this bug.

Thanks,
Prakash

Comment 3 Prakash Velayutham 2012-08-08 14:38:20 UTC
Hello,

Any updates please?

Thanks,
Prakash

Comment 4 Tomas Lestach 2012-09-03 12:30:08 UTC
spacewalk.git: 4823565b2e634bc73010d366ff82c432630bca85

Comment 5 Franky Van Liedekerke 2012-09-13 13:13:11 UTC
The same API call also shows packages with the same name from channels the system is not subscribed to. This is the case where people have e.g. redhat and centos packages in spacewalk, both using the same name+version (like the kernel package).
I don't think the system is allowed to install packages from another channel, but it is not very "pretty" ...
Is this also resolved with this new query? If not, I'll to open a new bug report for this.
Also, can this fix be backported somehow to 1.7? Since this caused me quite some troubles when first updating servers (where older kernel packages were installed after newer versions when feeding the resulting list from this API call to system.schedulePackageInstall() )

Comment 6 Franky Van Liedekerke 2012-09-14 15:21:10 UTC
To answer my own question: it still gives package id's from channels the system isn't subscribed to as well.

Comment 7 Jan Pazdziora 2012-10-30 19:23:59 UTC
Moving ON_QA. Packages that address this bugzilla should now be available in yum repos at http://yum.spacewalkproject.org/nightly/

Comment 8 Tomas Lestach 2012-10-31 15:56:10 UTC
make the query work on PG ...

spacewalk.git: 594781171402e28f85cdcb9fe7e838e35288a505


Moving back to MODIFIED ...

Comment 9 Tomas Lestach 2012-11-01 12:24:52 UTC
list upgradable packages from server channels only (fix for issue described in Comment#6) ...

spacewalk.git: 1168f61a9d16b42b533a21513c8538529862e745

Comment 10 Lars Delhage 2013-02-22 13:51:55 UTC
This problem is also in the API for RHN Satellite 5.5 (and probably earlier then). Should a separate bug be filed for that?

Comment 11 Tomas Lestach 2013-02-25 10:59:21 UTC
Yes, current Bug is filed against Spacewalk. If you want to track the issue against any other Product, please, create a separate BZ.

Comment 12 Stephen Herr 2013-03-01 17:07:51 UTC
Marking bug as ON_QA since tonight's build of Spacewalk nightly is a release candidate for Spacewalk 1.9.

Comment 13 Stephen Herr 2013-03-06 18:35:27 UTC
Spacewalk 1.9 has been released.

https://fedorahosted.org/spacewalk/wiki/ReleaseNotes19