Bug 1118394

Summary: deployment of new war from repo content fails (always)
Product: [JBoss] JBoss Operations Network Reporter: Armine Hovsepyan <ahovsepy>
Component: ContentAssignee: RHQ Project Maintainer <rhq-maint>
Status: CLOSED CURRENTRELEASE QA Contact: Mike Foley <mfoley>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: JON 3.2.2CC: jshaughn, mfoley
Target Milestone: DR01   
Target Release: JON 3.3.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-12-11 14:03:28 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:
Attachments:
Description Flags
deployment_failed
none
helloworld.war
none
ClusterWebApp.war
none
content_update none

Description Armine Hovsepyan 2014-07-10 15:13:43 UTC
Created attachment 917138 [details]
deployment_failed

Description of problem:
deployment of new war from repo content fails (always)

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

How reproducible:
always

Steps to Reproduce:
1.  Start JBoss EAP 6.1 standalone server.
2.  Start JBoss ON 3.2 system.
3.  Import JBoss EAP server into inventory.
4.  Configure connection settings for newly imported resource.
5.  Deploy jboss-as-helloworld.war to JBoss EAP server.

6.  Create test repository from Administration > Content / Repositories:

    *   *Name*: `Test Repo`

7.  From Test Repo upload a new version of helloworld WAR:

    *   *Upload File*:  jboss-as-helloworld-1.0.1.war (any WAR will do)
    *   *Type*: *File [Deployment:JBossAS7]*

8.  Subscribe the imported JBoss EAP server to *Test Repo*:
    
    1.  Under *Resources Subscribed To This Repository* click *SUBSCRIBE...* button.
    2.  For search, enter `jboss-as-helloworld.war` and set type drop-down to *Service* and click search.
    3.  Check jboss-as-helloworld.war resource which was returned.
    4.  Click *SUBSCRIBE SELECTED*.
    
9.  Navigate to the content page of the jboss-as-helloworld.war resource.
10. Select the new tab.
11. Check one of the new versions of jboss-as-helloworld.war (jboss-as-helloworld-1.0.1.war).
12. Click *DEPLOY SELECTED*.

Actual results:
deployment fails

Expected results:
deployment succeeds 

Additional info:
screen-shots attached
this is not a regression

Comment 1 Armine Hovsepyan 2014-07-24 13:52:06 UTC
Created attachment 920543 [details]
helloworld.war

Comment 2 Armine Hovsepyan 2014-07-24 13:53:11 UTC
Created attachment 920544 [details]
ClusterWebApp.war

test app wars added

Comment 3 Jay Shaughnessy 2014-07-24 18:11:25 UTC
OK, I think this may actually behaving as expected.  The Content tab basically allows for a redeploy of the same deployment, basically an update of the bits, but for the same actual deployment.

In the reproduction steps you first deploy jboss-as-helloworld.war.  You then try to update to jboss-as-helloworld-1.0.1.war.  Since EAP is using the filename as the deployment name, it can't find jboss-as-helloworld-1.0.1.war.

So actually, the statement above, "(any WAR will do)", does not seem to be true.

Remember that packages can be assigned the same name, and the versions can differ. This is the expectation when performing this sort of update.  In other words, the versioned-deployment strategy we've been trying to accommodate recently, where version strings exist in the artifact name, does not translate well to the content/package strategy.  Content expects the version to be separate from the name.

The whole thing is made confusing by the complete lack of an error-message in the failure detail.  And also, nothing useful in the agent log.  The following commit fixes it so the failure message can be seen in both places, but the 

master commit 367145b3a9a714b02eff372019fb08bc41c3b5fb
Author: Jay Shaughnessy <jshaughn>
Date:   Thu Jul 24 14:05:58 2014 -0400

    This is not a fix for the reported issue, which actually seems to not be a
    bug.  This is a fix to ensure failed package installs persist the error
    messageto the history record in the DB. And to provide a more useful
    log message in the agent log.


release/jon3.3.x commit 562cd907ca79fc18f9bfdf9aa051bbe5e10f3fea
Author: Jay Shaughnessy <jshaughn>
Date:   Thu Jul 24 14:09:59 2014 -0400

    Cherry-pick master ec19fd70d8db8e100b3c83c75f8d29d6c5c797ff

Comment 4 Simeon Pinder 2014-07-31 15:49:42 UTC
Moving to ON_QA as available to test with brew build of DR01: https://brewweb.devel.redhat.com//buildinfo?buildID=373993

Comment 5 Armine Hovsepyan 2014-08-01 13:48:50 UTC
Created attachment 923325 [details]
content_update

Comment 6 Armine Hovsepyan 2014-08-04 13:31:53 UTC
closing issue as verified since no error is visible anymore
4 new BZs filed related to this bZ #1126460 , #1126387 , #1126044 , #1126053