Bug 1031152 - Deployment of EAP 6.1.0 cartridge takes ~3 minutes and validation times out
Deployment of EAP 6.1.0 cartridge takes ~3 minutes and validation times out
Status: CLOSED NOTABUG
Product: OpenShift Container Platform
Classification: Red Hat
Component: Image (Show other bugs)
2.0.0
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jason DeTiberus
libra bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-15 13:02 EST by Jesse Sightler
Modified: 2017-03-08 12 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-21 15:06:23 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jesse Sightler 2013-11-15 13:02:14 EST
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 16:51:20 EST
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 15:06:23 EST
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.

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