Bug 1486190

Summary: same errata synced into two organizations break multiple errata queries
Product: Red Hat Satellite 5 Reporter: Tomáš Kašpárek <tkasparek>
Component: ServerAssignee: Tomáš Kašpárek <tkasparek>
Status: CLOSED ERRATA QA Contact: Radovan Drazny <rdrazny>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 580CC: jdobes, ktordeur, mdekan, rdrazny, tlestach
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: spacewalk-java-2.5.14-96-sat Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1500185 (view as bug list) Environment:
Last Closed: 2017-10-19 11:57:19 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: 1450111, 1500185    

Description Tomáš Kašpárek 2017-08-29 07:50:53 UTC 
Description of problem:
As result of work on BZ#1444519 column advisory is no longer sufficient as primary key, as now uniqueness is ensured by pair advisory, org_id.
Couple of errata queries which are looking up errata by its name are not adapted to this, which results in errors as we're expecting at most one row to be returned by the query.

Version-Release number of selected component (if applicable):
Spacewalk nightly, Spacewalk 2.7, Satellite 5.8, Satellite 5.7 with RHBA-2017:1771 applied (BZ#1451461)

How reproducible:
always

Steps to Reproduce:
1. create two organizations
2. sync some channels containing errata into them using spacewalk-repo-sync (spacewalk-repo-sync -c epelorgone -u https://dl.fedoraproject.org/pub/epel/7/x86_64/ spacewalk-repo-sync -c epelorgtwo -u https://dl.fedoraproject.org/pub/epel/7/x86_64/)
3. e.g. spacewalk-clone-by-date (customer's reproducer) one of these channels, or use following script which calls API call which c-b-d uses:

cat reproducer.py 
#!/usr/bin/python
import xmlrpclib

SATELLITE_URL = "http://localhost/rpc/api"
SATELLITE_LOGIN = "admin"
SATELLITE_PASSWORD = "nimda"

client = xmlrpclib.Server(SATELLITE_URL, verbose=0)
key = client.auth.login(SATELLITE_LOGIN, SATELLITE_PASSWORD)
client.errata.listPackages(key, 'FEDORA-EPEL-2014-2328')
client.auth.logout(key)



Actual results:

./reproducer.py 
Traceback (most recent call last):
  File "./reproducer.py", line 12, in <module>
    client.errata.listPackages(key, 'FEDORA-EPEL-2014-2328')
  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 -1: 'redstone.xmlrpc.XmlRpcFault: unhandled internal exception: query did not return a unique result: 2'>

this is caused by query used in java/code/src/com/redhat/rhn/domain/errata/impl/PublishedErrata.hbm.xml

    <query name="PublishedErrata.findByAdvisory">
        <![CDATA[from com.redhat.rhn.domain.errata.impl.PublishedErrata as e
                 where e.advisory = :advisory]]

additionally following query is also not checking for full unique pair:

    <query name="PublishedErrata.findByAdvisoryName">
        <![CDATA[from com.redhat.rhn.domain.errata.impl.PublishedErrata as e
                 where e.advisoryName = :advisory]]>

This is caused by following data in the database:

echo "select org_id, advisory, advisory_name from rhnErrata where advisory_name = 'FEDORA-EPEL-2014-2328';" | spacewalk-sql -i
 org_id |         advisory          |     advisory_name     
--------+---------------------------+-----------------------
      1 | FEDORA-EPEL-2014-2328-200 | FEDORA-EPEL-2014-2328
      2 | FEDORA-EPEL-2014-2328-200 | FEDORA-EPEL-2014-2328
(2 rows)


Expected results:
Lookup errata queries are returning at most one row as they're checking for full unique pair of advisory, org_id or advisory_name, org_id (both pairs should be unique within Satellite).

Additional info:
PublishedErrata.findByAdvisoryName and PublishedErrata.findByAdvisory might not be the only calls affected by this issue. We will have to investigate further to identify more possible places where we are looking errata just by advisory or its name.
Comment 3 Tomáš Kašpárek 2017-09-05 08:02:58 UTC 
spacewalk.git(master): 0556c1fef16a8ecc2666f2bbf409cb869f46dd58
Comment 8 Radovan Drazny 2017-09-22 13:50:24 UTC 
Reproduced on spacewalk-java-2.5.14-95.el6sat.noarch using the reproducer from the original report:

$ python reproducer.py
Traceback (most recent call last):
  File "reproducer.py", line 10, in <module>
    client.errata.listPackages(key, 'FEDORA-EPEL-2014-2328')
  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 -1: 'redstone.xmlrpc.XmlRpcFault: unhandled internal exception: query did not return a unique result: 2'>

Using clone-by-date:

$ spacewalk-clone-by-date -l epelorgtwo clone-epelorgtwo -d 2017-05-01 -u admin3 -p nimda
Reading repository information.
Using issue_date.

By continuing the following channels will be created:
clone-epelorgtwo

Continue with channel creation (y/n)?y

Cloning epelorgtwo to clone-epelorgtwo with original package set.
Copying repodata, please wait.
Solving Dependencies (2320):
________________________________________
######################################## - complete
Processing Dependencies:
________________________________________
########################################Traceback (most recent call last):
  File "/usr/bin/spacewalk-clone-by-date", line 429, in <module>
    sys.exit(abs(main() or 0))
  File "/usr/bin/spacewalk-clone-by-date", line 419, in main
    return cloneByDate.main(args)
  File "/usr/share/rhn/utils/cloneByDate.py", line 245, in main
    cloner.create_channels(options.skip_depsolve)
  File "/usr/share/rhn/utils/cloneByDate.py", line 393, in create_channels
    + [self.src_parent]))
  File "/usr/share/rhn/utils/cloneByDate.py", line 496, in dep_solve
    self.__dep_solve(nvrea_list)
  File "/usr/share/rhn/utils/cloneByDate.py", line 509, in __dep_solve
    self.process_deps(dep_results)
  File "/usr/share/rhn/utils/cloneByDate.py", line 547, in process_deps
    next_added = set(cloner.process_deps(needed))
  File "/usr/share/rhn/utils/cloneByDate.py", line 701, in process_deps
    e_pkgs = self.remote_api.get_erratum_packages(e)
  File "/usr/share/rhn/utils/cloneByDate.py", line 965, in get_erratum_packages
    return self.client.errata.listPackages(self.auth_token, advisory_name)
  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 -1: 'redstone.xmlrpc.XmlRpcFault: unhandled internal exception: query did not return a unique result: 2'>

After upgrade to spacewalk-java-2.5.14-97.el6sat.noarch, both reproducer script and clone by date proceeded without an issue, both on Oracle and Postgre.

VERIFIED
Comment 10 errata-xmlrpc 2017-10-19 11:57:19 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:2915