Bug 1294907 - after a few successful appliance connections to VMDB, subsequent attempts to add additional appliances timeout
Summary: after a few successful appliance connections to VMDB, subsequent attempts to ...
Keywords:
Status: CLOSED DUPLICATE of bug 1296335
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Appliance
Version: 5.5.0
Hardware: All
OS: Linux
unspecified
high
Target Milestone: GA
: 5.6.0
Assignee: Gregg Tanzillo
QA Contact: Alex Newman
URL:
Whiteboard:
: 1294909 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-12-30 22:03 UTC by Thomas Hennessy
Modified: 2016-09-21 14:18 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-03-08 20:02:02 UTC
Category: ---
Cloudforms Team: ---
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
tgz file contains two other tgz files for each of the two appliances described under 'Additional info' (11.59 MB, application/x-gzip)
2015-12-30 22:03 UTC, Thomas Hennessy
no flags Details

Description Thomas Hennessy 2015-12-30 22:03:39 UTC
Created attachment 1110642 [details]
tgz file contains two other tgz files for each of the two appliances described under 'Additional info'

Description of problem: long running sequence of sql queries initiated when a new appliance tries to insert itself into the VMDB timesout and the appliance is not associated with VMDB.


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


How reproducible: UNCERTAIN


Steps to Reproduce:
1.
2.
3.

Actual results: multiple attempts to add a fourth appliance into an existing VMDB complex all fail with timeouts trying to add the new appliance into the VMDB.


Expected results: new appliance should be added into existing complex


Additional info:
a long running set of queries about various tables and relations are running longer than 5 minutes and evoke a timeout from the evm.log file.  Customer modified to sql configuration file to capture all sql queries which are included in the attached set of logs. 

A few items of note:
- Region # = 80.  References to record ids that follow will assume that key prefix.
- first appliance is added with a key of '1'
- second appliance is added with a key of '2'
- third appliance added days after initial migration of database is added with a key of '634'
- the above gap in keys suggest that there is some kind of updating of the sequence field associated with the miq_servers table that may shed some light on what is happening.

- two key log sets from two appliances are provided: one from database owing appliance including postgresql.log referenced above and one from the appliance attempting to insert itself into the VMDB and timeout out.

- a copy of the database has been requested.

Comment 2 Dave Johnson 2016-02-09 16:44:10 UTC
*** Bug 1294909 has been marked as a duplicate of this bug. ***

Comment 3 Nick Carboni 2016-02-29 14:06:08 UTC
This BZ seems to be tracking the same issue as https://bugzilla.redhat.com/show_bug.cgi?id=1296335 do we want to consider these duplicates?

Comment 4 Keenan Brock 2016-03-08 19:57:28 UTC
Yes, these are the same issue.

We perform many transactions. If the latency is above a local machine, then this can become painfully long.

Comment 5 Keenan Brock 2016-03-08 20:02:02 UTC
Marking as a duplicate.

This is stemmed around the sheer quantity of sql queries performed at boot. probably associated with db seed process.

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


Note You need to log in before you can comment on or make changes to this bug.