Bug 833213

Summary:	Scalable jbossas-7 fails to deploy after initial creation
Product:	OKD	Reporter:	Dan Mace <dmace>
Component:	Containers	Assignee:	Dan Mace <dmace>
Status:	CLOSED CURRENTRELEASE	QA Contact:	libra bugs <libra-bugs>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	2.x	CC:	mpatel, qgong
Target Milestone:	---	Keywords:	Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
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 18:27:20 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:
Embargoed:

Description Dan Mace 2012-06-18 21:47:07 UTC

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 -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 14:59:33 UTC

*** Bug 833313 has been marked as a duplicate of this bug. ***

Comment 2 Dan Mace 2012-06-19 17:01:03 UTC

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 20:58:08 UTC

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 4 Dan Mace 2012-06-19 21:36:00 UTC

Fix merged to master: https://github.com/openshift/crankcase/commit/bd37ba3bbdce76056fca9711fa4351bee33afa90

Comment 5 Rony Gong 🔥 2012-06-20 08:37:53 UTC

verified on devenv_1859, could create jbossas application success and could access the app URL.