Hide Forgot
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.
Please, open a Support case with Red Hat Support regarding this issue.
spacewalk.git: ee22d9c7e84a089e3782db5e32b1ab20a690e6dc
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.
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.
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 ###
re-verify with spacewalk-java-2.3.8-96.el6sat.noarch steps by comment 6
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