Bug 235385

Summary:	Remove extra entries in rhnServerDmi and in rhnRam
Product:	[Retired] Red Hat Network	Reporter:	John Sanda <jsanda>
Component:	RHN/Web Site	Assignee:	John Sanda <jsanda>
Status:	CLOSED DUPLICATE	QA Contact:	Red Hat Satellite QA List <satqe-list>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rhn500	CC:	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:	---	Target Upstream Version:
Embargoed:

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. ***