Bug 1118394 - deployment of new war from repo content fails (always)
Summary: deployment of new war from repo content fails (always)
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Operations Network
Classification: JBoss
Component: Content
Version: JON 3.2.2
Hardware: Unspecified
OS: Unspecified
unspecified
urgent
Target Milestone: DR01
: JON 3.3.0
Assignee: RHQ Project Maintainer
QA Contact: Mike Foley
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-10 15:13 UTC by Armine Hovsepyan
Modified: 2015-09-03 00:03 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-12-11 14:03:28 UTC
Type: Bug


Attachments (Terms of Use)
deployment_failed (177.21 KB, image/png)
2014-07-10 15:13 UTC, Armine Hovsepyan
no flags Details
helloworld.war (5.71 MB, application/x-webarchive)
2014-07-24 13:52 UTC, Armine Hovsepyan
no flags Details
ClusterWebApp.war (4.36 KB, application/x-webarchive)
2014-07-24 13:53 UTC, Armine Hovsepyan
no flags Details
content_update (209.90 KB, image/png)
2014-08-01 13:48 UTC, Armine Hovsepyan
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1081592 None None None Never

Internal Links: 1081592

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@redhat.com>
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@redhat.com>
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


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