We have tested (or attempted to test) bug like this when Spacewalk 2.6 was to be released. This is a clone of that bug to get it re-tested on Satellite 5.8.0. In some cases bug can be completely irrelevant (in such cases I suggest to close the bug as NOTABUG), in some cases it might be wise to take the bug as a note that something changed in a given area and we might want to sanity-test that area (and mark the bug as VERIFIED with "SanityOnly" keyword) and in some cases bug might be totally relevant to Satellite.



+++ This bug was initially created as a clone of Bug #1378879 +++

Description of problem:
API method system.upgradeEntitlement does not work.

Version-Release number of selected component (if applicable):
spacewalk-java-2.5.93-1.el6
spacewalk-java-2.6.31-1.el6

How reproducible:
100%

Steps to Reproduce:
1. We have got a satellite with registered systems
2. We choose one with base channel (no virtual guest) and try to setup "virtualization" entitlement by WebUI. It should pass it. 
3. Remove "virtualization" entitlement from this profile.
3. Now we can try it again for the same profile by API
> spacewalk-api --server=localhost --user=admin --password=xxx system.upgradeEntitlement "%session%" 1000010059 'virtualization_host'

Actual results:
Fault returned from XML RPC Server, fault code -1: redstone.xmlrpc.XmlRpcFault: unhandled internal exception: com.redhat.rhn.domain.entitlement.VirtualizationEntitlement cannot be cast to java.lang.String

Expected results:
$result = '1';

Additional info:
Maybe there are some relation with bz1378873.

--- Additional comment from Jiří Dostál on 2016-09-27 09:49:10 EDT ---

spacewalk.git d4680f87655e139fe4d3cecb5319a8ed3ed65dbd

--- Additional comment from Lukáš Hellebrandt on 2016-11-11 06:43:14 EST ---

Verified with SW nightly from 2016-11-10.

Used reporoducer from OP:


# spacewalk-api --server=localhost --user=admin --password=nimda system.upgradeEntitlement "%session%" 1000010000 'virtualization_host'

$result = '1';