Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 235385

Summary: Remove extra entries in rhnServerDmi and in rhnRam
Product: Red Hat Network Reporter: John Sanda <jsanda>
Component: RHN/Web SiteAssignee: John Sanda <jsanda>
Status: CLOSED DUPLICATE QA Contact: Red Hat Satellite QA List <satellite-qa-list>
Severity: medium Docs Contact:
Priority: medium    
Version: rhn500CC: jeckersb, rhn-bugs
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-12-14 19:22:02 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description John Sanda 2007-04-05 14:56:06 UTC
Description of problem:
This bug is really an extension of bug 235108. With that bug we found that there
was an incorrect association mapping between the Server and CPU classes. Further
investigation revealed for the association mappings in Server with Ram and Dmi.
The issue manifests itself in the HQL query, Server.findByIdAndOrgId which is
defined in Server_legacyUser.hbm.xml.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Find a server with multiple entries in the table rhnRam.
1.a. Find a server multiple entries in the table rhnServerDmi.
2. Run the HQL query Server.findByIdAndOrgId.
3.
  
Actual results:
See Comment 2 in bug 235108. It provides a stack trace.

Expected results:
No exceptions should be thrown.

Additional info:

Comment 1 John Sanda 2007-04-09 15:22:58 UTC
There are a very small number of servers that have multiple rows in rhnRam and
or rhnServerDmi. It has been concluded that servers should not have multiple
rows in either of these tables. For those servers that do have multiple rows, it
should be treated as an error. Two things probably need to be done. 1) Remove
bad data from the database. 2) Make our Hibernate error handling more robust.
Currently, we almost always propagate a HibernateException up the call stack and
the user winds up seeing an ISE. We need to recover from errors when possible
and report/log more intelligible error messages when and where possible. Both of
these items are probably beyond the scope of 501.

Comment 2 Bret McMillan 2007-04-12 15:43:28 UTC
Has this hit webdev yet?

Comment 3 John Sanda 2007-04-12 15:59:38 UTC
The hibernate mappings for rhnServerDmi and rhnRam are in fact correct. We have
concluded that the few servers that have multiple rows in these tables have
erroneous data. These extra rows need to be purged from the database.

Bret, in our last conversation about this, you mentioned that we could do this
at any time. Can we move this off of 501h-must since it is not a high priority
issue? 

Comment 5 Bret McMillan 2007-05-11 15:46:17 UTC
John, we'll align this to rhn502; once the script is done and you're happy with
it, we can fast-track it through the various env's.

Comment 6 Grant Gainey 2007-06-12 13:55:27 UTC
There are currently 15 servers with >1 DMI entry, 88 with >1 CPU, and 90 with >1
RAM entry.  It looks like the extras are duplicates of each other.  A script
that deleted all but one of the dups, however we did that, would likely be
sufficient.

Currently, any/all of the systems affected by this will throw an ISE if you
attempt to visit their SDC pages. 

As an example - 
...
Caused by: com.redhat.rhn.common.hibernate.HibernateRuntimeException: Executing
query Server.findByIdandOrgId with params {orgId=779013, sid=1000122758} failed
...
Caused by: org.hibernate.HibernateException: More than one row with the given
identifier was found: 1000122758, for class: com.redhat.rhn.domain.server.Ram

So - right now, we need to fix up the data, regardless of whatever other work we
do, it looks like.

Comment 7 Bret McMillan 2007-06-19 00:33:44 UTC
moving these to rhn505-triage until we can re-examine for rhn503+

Comment 8 Grant Gainey 2007-12-14 19:22:02 UTC
I'm using 237898 as the master BZ for tracking this problem - closing this one
as adup

*** This bug has been marked as a duplicate of 237898 ***

Comment 9 Stephen Herr 2010-07-21 20:01:41 UTC
*** Bug 579491 has been marked as a duplicate of this bug. ***