Bug 1030546

Summary: system.schedulePackageInstall called with empty package list results in a failed event
Product: Red Hat Satellite 5 Reporter: palmej3
Component: APIAssignee: Tomas Lestach <tlestach>
Status: CLOSED CURRENTRELEASE QA Contact: Lukas Pramuk <lpramuk>
Severity: low Docs Contact:
Priority: unspecified    
Version: 550CC: cperry, lpramuk, pstudeni
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-01-13 10:19:12 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:
Bug Depends On:    
Bug Blocks: 1113221    

Description palmej3 2013-11-14 16:33:27 UTC 
Description of problem:

I have a custom application that uses the Satellite API. One of my unit tests calls system.schedulePackageInstall with an empty list of package IDs. This results in a pending event for the server. When that event gets processed, it becomes a failed event.

Steps to reproduce:

1. Call system.schedulePackageInstall with an empty list of package IDs.
2. Run 'sudo rhn_check' on the system in question.
3. View the system's event history in Satellite.

Actual results:

A new failed event in the system's event history

Expected results:

Either one of the following:

  No new event at all (since it is really a null event)
  A new successful event

No new event at all would be consistent with how system.scheduleApplyErrata handles an empty errata list, so I would prefer that result.
Comment 1 Tomas Lestach 2013-11-18 14:43:04 UTC 
Please, open a Support case with Red Hat Support regarding this issue.
Comment 2 Tomas Lestach 2013-11-18 15:25:38 UTC 
spacewalk.git: ee22d9c7e84a089e3782db5e32b1ab20a690e6dc
Comment 3 palmej3 2013-11-18 16:45:04 UTC 
So you're going to throw an exception in this case? The API really should be consistent with respect to empty lists. After your change, here are how a few API calls respond to empty lists:

 - system.schedulePackageInstall: exception thrown
 - system.scheduleApplyErrata: API call returns success and nothing happens
 - system.schedulePackageRemove: API call returns success, and later there will be a failed event
 - system.removeEntitlements: API call returns success and nothing happens
 - system.deleteCustomValues: API call returns success and nothing happens

I didn't look everywhere, but it seems so far that returning success and doing nothing is the more popular choice here. Maybe that could be your standard?

Whatever you decide, I'll be happy as long as it's consistent.
Comment 4 Tomas Lestach 2013-11-19 10:43:15 UTC 
If there're no packages specified, it makes no sense to create an action for rhn_check. Throwing an exception in this case is a good way how to prevent creating an empty action that would fail, when being picked up by the client.

Yes, I agree the approach shall be consistent ...

spacewalk.git:
 186e2f80ce54c1cade945f89c27ff106c3bfae2c for system.schedulePackageRemove API
 f05837f6187b733e80b919c16b5c9cb8ee1753cc for system.scheduleApplyErrata APIs


system.removeEntitlements and system.deleteCustomValues use a different approach - they do not create separate actions for rhn_check, those actions are processed immediately on the server, so this is OK.
Comment 6 Lukas Pramuk 2014-10-15 18:33:24 UTC 
VERIFIED. spacewalk-java-2.3.8-28.el6sat.noarch

REPRO:
>>> client.system.schedulePackageInstall(key,1000010000,[],datetime.now())
4
>>> client.system.schedulePackageRemove(key,1000010000,[],datetime.now())
5

vs.

FIX:
>>> client.system.schedulePackageInstall(key,1000010000,[],datetime.now())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1199, in __call__
    return self.__send(self.__name, args)
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1489, in __request
    verbose=self.__verbose
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1253, in request
    return self._parse_response(h.getfile(), sock)
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1392, in _parse_response
    return u.close()
  File "/usr/lib64/python2.6/xmlrpclib.py", line 838, in close
    raise Fault(**self._stack[0])
xmlrpclib.Fault: <Fault 1213: 'redstone.xmlrpc.XmlRpcFault: No packages to install.'>
>>> client.system.schedulePackageRemove(key,1000010000,[],datetime.now())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1199, in __call__
    return self.__send(self.__name, args)
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1489, in __request
    verbose=self.__verbose
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1253, in request
    return self._parse_response(h.getfile(), sock)
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1392, in _parse_response
    return u.close()
  File "/usr/lib64/python2.6/xmlrpclib.py", line 838, in close
    raise Fault(**self._stack[0])
xmlrpclib.Fault: <Fault 1213: 'redstone.xmlrpc.XmlRpcFault: No packages to remove.'>

### no more actions that would fail are scheduled ###


REPRO:
>>> client.system.scheduleApplyErrata(key,1000010000,[],datetime.now())
[]
>>> client.system.scheduleApplyErrata(key,1000010000,[])
[]
>>> client.system.scheduleApplyErrata(key,[],[],datetime.now())
[]
>>> client.system.scheduleApplyErrata(key,[],[])
[]

vs. 

FIX:
>>> client.system.scheduleApplyErrata(key,1000010000,[])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1199, in __call__
    return self.__send(self.__name, args)
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1489, in __request
    verbose=self.__verbose
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1253, in request
    return self._parse_response(h.getfile(), sock)
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1392, in _parse_response
    return u.close()
  File "/usr/lib64/python2.6/xmlrpclib.py", line 838, in close
    raise Fault(**self._stack[0])
xmlrpclib.Fault: <Fault 1213: 'redstone.xmlrpc.XmlRpcFault: No errata to apply.'>
>>> client.system.scheduleApplyErrata(key,[],[])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1199, in __call__
    return self.__send(self.__name, args)
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1489, in __request
    verbose=self.__verbose
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1253, in request
    return self._parse_response(h.getfile(), sock)
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1392, in _parse_response
    return u.close()
  File "/usr/lib64/python2.6/xmlrpclib.py", line 838, in close
    raise Fault(**self._stack[0])
xmlrpclib.Fault: <Fault 1213: 'redstone.xmlrpc.XmlRpcFault: No systems specified.'>

### though failing actions were not scheduled, now we throw an error to make it consistent ###
Comment 7 Pavel Studeník 2015-01-08 13:48:07 UTC 
re-verify with spacewalk-java-2.3.8-96.el6sat.noarch

steps by comment 6
Comment 8 Clifford Perry 2015-01-13 10:19:12 UTC 
With the release of Red Hat Satellite 5.7 on January 12th 2015 this bug is
being moved to a Closed Current Release state. 

The Satellite 5.7 GA Errata:
 - https://rhn.redhat.com/errata/RHSA-2015-0033.html 

Satellite 5.7 Release Notes:
 -
https://access.redhat.com/documentation/en-US/Red_Hat_Satellite/5.7/html-single/Release_Notes/index.html

Satellite Customer Portal Blog announcement for release:
 - https://access.redhat.com/blogs/1169563/posts/1315743 

Cliff