Bug 833213 - Scalable jbossas-7 fails to deploy after initial creation
Scalable jbossas-7 fails to deploy after initial creation
Status: CLOSED CURRENTRELEASE
Product: OpenShift Origin
Classification: Red Hat
Component: Containers (Show other bugs)
2.x
Unspecified Unspecified
medium Severity medium
: ---
: ---
Assigned To: Dan Mace
libra bugs
: Triaged
: 833313 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-18 17:47 EDT by Dan Mace
Modified: 2015-05-14 18:55 EDT (History)
2 users (show)

See Also:
Fixed In Version: cartridge-jbossas-7-0.94.7-1+
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-25 14:27:20 EDT
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 Dan Mace 2012-06-18 17:47:07 EDT
Description of problem:

When creating a new scalable jbossas-7 application, the contents of the jboss deployments
directory is not synchronized across gears.

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


How reproducible:

Create a new jbossas-7 application with scaling enabled.

Steps to Reproduce:
1. rhc-create-app -a jbscale -t jbossas-7 -s -l dmace50@example.com -p none
  
Actual results:

JBoss instance is created generally correctly, but nothing is present in the jbossas-7/standalone/deployments directory.

Expected results:

A ROOT.war file to be present in jbossas-7/standalone/deployments.

Additional info:

This is happening because the sync_gears.sh script is still coded to assume that the JBoss deployments are relative
to app-root/repo/deployments rather than jbossas-7/standalone/deployments (a change introduced with hot deployment
support).
Comment 1 Mrunal Patel 2012-06-19 10:59:33 EDT
*** Bug 833313 has been marked as a duplicate of this bug. ***
Comment 2 Dan Mace 2012-06-19 13:01:03 EDT
Some background: Early in the implementation of hot deployment, we had to decide whether to continue letting JBoss deploy from the symlinked app-root/deployments directory (and build in a staging area rather than in-place), or un-linking app-root/deployments and making JBoss deploy from app/jbossas-7/standalone/deployments (as a physical directory) and building in app-root/deployments. We decided it was safe to implement the latter solution.

The problem is that the sync_gears.sh script expects uniformity amongst the gears being synced, and acts upon paths relative to app-root. With a symlinked app-root/deployments directory, there is a uniform relative path for syncing between gears. The hot deployment implementation for jbossas-7 introduces a gear specific subdirectory into the syncing mechanism. For example, the code now tries to sync /app-domain/app/jbossas-7/standalone/deployments with /gear_uid-domain/gear_uid/jbossas-7/standalone/deployments.

A possible solution is to go back to a symlink solution for deployments for jboss so we can reference directories relative to app-root. Otherwise, I will need some discussion on how to deal with gear specific paths during the sync.
Comment 3 Dan Mace 2012-06-19 16:58:08 EDT
I've identified the root cause. When creating a scalable jboss application, the following sequence of events occurs:

* The configure script for jbossas-7 executes to create the "embeddable" jboss app in the primary gear directory
* A new jboss gear is created based on the embeddable version
* The deploy.sh script is executed for the new jboss gear

The configure script for the jbossas-7 cart only installs the initial ROOT.war into $gear/$app/jbossas-7/standalone/deployments. The deploy.sh script does an rsync of $gear/app-root/repo/deployments => $gear/$app/jbossas-7/standalone/deployments. So, while the new jboss gear does contain ROOT.war when the gear is created (in the standalone/deployments directory), the rsync deletes the war because it is NOT present in app-repo/repo/deployments.

The jbossas-7 configure script is at fault in this case. When installing the default ROOT.war, it should do so in a manner consistent with the way a user would push code, which would result in the deployable artifacts being copied to app-root/repo/deployments (and then synced to standalone/deployments). This will cause deploy.sh to behave in the expected manner.
Comment 5 Rony Gong 2012-06-20 04:37:53 EDT
verified on devenv_1859, could create jbossas application success and could access the app URL.

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