Bug 1031152

Summary: Deployment of EAP 6.1.0 cartridge takes ~3 minutes and validation times out
Product: OpenShift Container Platform Reporter: Jesse Sightler <jsightle>
Component: ImageStreamsAssignee: Jason DeTiberus <jdetiber>
Status: CLOSED NOTABUG QA Contact: libra bugs <libra-bugs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 2.0.0CC: bleanhar
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-21 20:06:23 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:

Description Jesse Sightler 2013-11-15 18:02:14 UTC 
Every deployment of a non-scaled EAP 6.1 gear takes ~3 minutes. I see these lines in the log that seems to indicate the cause:
November 14 14:29:03 INFO oo_spawn buffer(11/) Starting jbosseap cartridge
November 14 14:29:28 INFO oo_spawn buffer(11/) Found 127.1.244.1:8080 listening port
November 14 14:29:28 INFO oo_spawn buffer(11/) Found 127.1.244.1:9999 listening port
November 14 14:30:58 INFO oo_spawn buffer(11/) CLIENT_MESSAGE: Could not connect to JBoss management interface, skipping deployment verification

Using curl -v http://127.1.244.1:8080 and curl -v http://127.1.244.1:9990/ on the node itself provides the expected result. Setting selinux to permissive still results in the same errors, so I don't think that selinux is restricting the network calls from the node itself either.

Hitting the external url in the browser works as well.
Comment 2 Jesse Sightler 2013-11-20 21:51:20 UTC 
This is now looking like a firewall issue with my local node (specific to the iptables configuration in our environment). I'm still investigating, but I think this might be closable soon...
Comment 3 Jesse Sightler 2013-11-21 20:06:23 UTC 
This was due to a dns server taking a long time to respond in our environment. And that was due to an iptables restriction.

I do not believe that there is a bug here. Closing.