Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 950917

Summary: [RFE] [rhevm] - Remote Setup RHEVM - Webadmin Stuck in loading when Remote DB Server is unavailable
Product: Red Hat Enterprise Virtualization Manager Reporter: David Botzer <dbotzer>
Component: ovirt-engine-webadmin-portalAssignee: Eli Mesika <emesika>
Status: CLOSED NOTABUG QA Contact: Barak Dagan <bdagan>
Severity: high Docs Contact:
Priority: unspecified    
Version: 3.2.0CC: acathrow, bazulay, bdagan, dbotzer, ecohen, emesika, iheim, jkt, pstehlik, Rhev-m-bugs
Target Milestone: ---Keywords: FutureFeature, Triaged
Target Release: 3.4.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: infra
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-12-15 15:17:29 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Infra RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description David Botzer 2013-04-11 08:04:32 UTC
Description of problem:
In Remote Setup RHEVM, where Engine DB is on remote Server, The Webadmin is Stuck in loading process when Remote DB Server is unavailable

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

How reproducible:
always

Steps to Reproduce:
1.Install RHEVM in remote setup
2.Configure entities
3.Shutdown the Remote Server
  
Actual results:
Webadmin stops working, or working incorrect,
When restarting Webadmin its displaying the loading progress bar

Expected results:
Webadmin should recover using any available solution
1. Allow a Read Only snapshot of engine db, just to keep on working, until remote server is up
2. Remember "last known configuration"
3. Error message " Service is unavailable, DB server unreachable"

Additional info:

Comment 3 Barak 2013-07-07 13:45:59 UTC
This issue is much wider than the description above:

1 - the handling of remote DB and local DB should be the same.
2 - The UI part should move the user to an appropriate error message page (both 
    UP and webadmin).
3 - engine side (assuming #2 handled)  - not clear what can be done, it looks 
    like each connection in the pool will throw an exception. need to 
    investigate our behaviour here.

Anyway this is not a 3.3 bug - but can evolve into some major infrastructure 
changes.

Moving to 3.4

Comment 4 Eli Mesika 2013-11-18 23:58:13 UTC
Not clear from the description if

1) The server hosting the remote DB is shutdown

2) The DB service is shut down

Comment 6 Barak Dagan 2013-12-11 11:15:05 UTC
It happens when postgres servive is down:
service postgresql stop

However, I get the same behaviour shutting down the service on local DB.

so, IMO, the BZ should be change to "use TO when DB is not accessible", 
it can be applied to service is down, port is blocked / misconfigured, etc.

Comment 7 Eli Mesika 2013-12-15 15:10:52 UTC
(In reply to Barak Dagan from comment #6)
> It happens when postgres servive is down:
> service postgresql stop
> 
> However, I get the same behaviour shutting down the service on local DB.
> 
> so, IMO, the BZ should be change to "use TO when DB is not accessible", 
> it can be applied to service is down, port is blocked / misconfigured, etc.

I had reproduced and got the following in log

Query SearchQuery failed. Exception message is Could not get JDBC Connection; nested exception is java.sql.SQLException: javax.resource.ResourceException: IJ000453: Unable to get managed connection for java:/ENGINEDataSource : org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get JDBC Connection; nested exception is java.sql.SQLException: javax.resource.ResourceException: IJ000453: Unable to get managed connection for java:/ENGINEDataSource: org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get JDBC Connection; nested exception is java.sql.SQLException: javax.resource.ResourceException: IJ000453: Unable to get managed connection for java:/ENGINEDataSource


So, IMHO, log reports the problem correctly and its enough to track the problem origin.

1) & 2) from Bug Description Expected results so not make sense 
3) is already implementaed by writing the exact problem to the log

I suggest closing as NOTABUG

Comment 8 Eli Mesika 2013-12-15 15:17:29 UTC
(In reply to Eli Mesika from comment #7)
> I suggest closing as NOTABUG

This was agreed by QA contact (Barak D) that it should be closed as NOTABUG