Bug 1188751 - Deploying Versioned WAR package from repository to JBOSS EAP 6 deployment resource fails
Summary: Deploying Versioned WAR package from repository to JBOSS EAP 6 deployment res...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: JBoss Operations Network
Classification: JBoss
Component: Content
Version: JON 3.3.0
Hardware: All
OS: All
high
high
Target Milestone: post-GA
: One-off release
Assignee: Thomas Heute
QA Contact: Mike Foley
URL:
Whiteboard:
Depends On:
Blocks: 1181217
TreeView+ depends on / blocked
 
Reported: 2015-02-03 15:59 UTC by dsteigne
Modified: 2019-03-22 07:36 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2016-01-28 13:29:09 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
server.log (125.26 KB, text/plain)
2015-04-14 20:32 UTC, Armine Hovsepyan
no flags Details
video (12.66 MB, application/ogg)
2015-04-15 05:38 UTC, Armine Hovsepyan
no flags Details
content_deployment (193.83 KB, image/png)
2015-06-17 14:20 UTC, Armine Hovsepyan
no flags Details
eap.log_fragment (2.12 KB, text/plain)
2015-06-17 14:21 UTC, Armine Hovsepyan
no flags Details
server.log_fragment (5.75 KB, text/plain)
2015-06-17 14:21 UTC, Armine Hovsepyan
no flags Details
server.log_fragment2 (104.11 KB, text/plain)
2015-06-17 14:32 UTC, Armine Hovsepyan
no flags Details
versioned_nonversioned_deployment (167.18 KB, image/png)
2015-06-17 14:43 UTC, Armine Hovsepyan
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1188743 0 high CLOSED Packages in a repository, that have an identical name to the deployment it's subscribed to, disappear in the Content->Ne... 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1232836 0 high CLOSED NoResultException in server.log when deploying from resource content for war type != File (Deployment:AS7) 2021-02-22 00:41:40 UTC
Red Hat Knowledge Base (Solution) 1324743 0 None None None Never

Internal Links: 1188743 1232836

Description dsteigne 2015-02-03 15:59:32 UTC
Description of problem:
Deploying Versioned WAR package from repository to JBOSS EAP 6 deployment resource fails

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

How reproducible:
Always

Steps to Reproduce:
1) I create a new Repository in JON.  For my test, I uploaded four WAR packages into the repository:
web_policy-1.0.0.war
web_policy-1.0.1.war
web_policy-1.0.2.war
web_policy-1.0.3.war

JON 3.3 was supposed to strip those version numbers off, starting with the '-', and I would be able to deploy them to a web_policy.war resource.

2) I then subscribe the deployment resource to the repository. 

3) When in the resource content window, I click on the New tab.  I see the list of WAR files I uploaded into the repository I created.  Everything looks fine.  I select one of the WAR files and click the "Deploy Selected" button

4) I click "Continue" on the Review Packages screen.

5) it displays that my deployment is in progress in the Currently Executing Requests table.  Clicking on the History tab then updates it saying that there was a failure in the deploy.  

6) Clicking on the Details in the failure entry prints out the following error: 

"Rolled Back: JBAS014807: Management resource '[("deployment" => "web_policy-1.0.0.war")]' not found, rolled-back=true"


Actual results:
Failed with error:
"Rolled Back: JBAS014807: Management resource '[("deployment" => "web_policy-1.0.0.war")]' not found, rolled-back=true"

Expected results:
The Versioned Deployment will work as per documentation - https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Operations_Network/3.3/html/Users_Guide/eap6-deploy.html#versioned-deployments
and drop the version number from the war, so web_policy-1.0.0.war would update the currently deployed web_policy.war 

Additional info:

Comment 1 Libor Zoubek 2015-03-30 14:01:35 UTC
Versioned deployments were never supposed to work like you expect. This feature was introduced (according to documented TCMS test cases) to handle situations, when deployments are updated outside JON and JON is only monitoring them - then if, version scheme is followed, if you deploy web_policy_1.0.1.war, JON won't show web_policy_1.0.0.war as missing and create new resrouce, it "kind of" merges those 2 into 1 resource.

That said, it makes a sense to update plugin code, to support this versioned deployments.

Versioned Deployment = web_runtime-1.0.0.war which is discovered as resource web_runtime.war having version 1.0.0

Changes that I am going to do (patch almost ready):

When given resource is versioned deployment and user wants to update it's content with new package

1. if the updated "Package Name" *is* same or different version of the original deployment (in our case it must match web_runtime-(version).war), we undeploy original deployment from server and deploy new Package. Discovery code in place will handle this, so there won't be a new resource. We also perserve deployment's state (enabled/disabled) and runtime-name - only if it differs from deployment name - this means it was explicitly set at original deployment deploy time.

2. if updated "Package Name" does not match versioning scheme, it will fail. We won't allow to deploy unversioned package to versioned resource - that would result in new discovered resource.

3. if updated "Package Name" is versioned, but does not match original deployment (ie, if you attempt to update content of web_runtime-1.0.0.war with package named hello-1.0.0.war), it is going to fail.

4. Unversioned deployments must not be affected.

Comment 2 Libor Zoubek 2015-03-30 14:34:37 UTC
Opened https://github.com/rhq-project/rhq/pull/163 (on master) to get review & QE automation run

Comment 3 Libor Zoubek 2015-04-01 17:19:19 UTC
Pull request merged to master

branch:  master
link:    https://github.com/rhq-project/rhq/commit/2b77882f3
time:    2015-04-01 14:06:21 +0200
commit:  2b77882f348095bebffc63e5a5461831d78d3bcb
author:  Libor Zoubek - lzoubek
message: Bug 1188751 - Deploying Versioned WAR package from repository to JBOSS
         EAP 6 deployment resource fails

         Support for updating package content for versioned deployments.
         This is performed by removing the original deployment and
         deploying the new one - using just redeploy wouln't work. In
         case of versioned DomainDeployment we unassign it to all
         server-groups, replace content and then assign back to the same
         server-groups.

         This commit also extracts code for setting deployment metadata
         on AS7 into Deployer class.


There are several test cases to be performed by QE.

a) Verify versioned EAR package gets updated on standalone server

1. have EAP6 standalone in inventory
2. create content repo, upload attached ear files (set package type to JBossAS7:Deployment)
3. deploy ear-1.0.0.ear to EAP6
assert resource is called ear.ear, with version 1.0.0
assert resource subdeployments do not have versions in resource names
4. subscribe ear.ear resource to your content repo
5. go to 'Content' tab, 'New' subtab, and deploy ear-2.0.0.ear
assert success
assert ear.ear is available and it's resource version get's updated to 2.0.0 (you can check info message in agent.log)
assert ear.ear's subdeployments have changed versions as well

b) Verify invalid update attempt of deployment on standalone server

1. have EAP6 standalone in inventory
2. copy ear-2.0.0.ear to ear.ear
3. create content repo, upload ear.ear
4. deploy ear-1.0.0.ear to EAP6
5. subscribe ear.ear resource to your content repo
6. go to 'Content' tab, 'New' subtab, and deploy ear.ear
assert failure - attept to update versioned resource's content with non-versioned package is invalid

c) Verify invalid update attempt of deployment on standalone server

Same as case b), but in step 2. rename file to foo-2.0.0.ear
assert failure

d) Verify versioned EAR package gets updated on Domain server
1. have EAP6 domain in inventory
2. create content repo, upload attached ear files (set package type to JBossAS7:DomainDeployment)
3. deploy ear-1.0.0.ear to EAP6 (create DomainDeployment child)
assert resource is called ear.ear, with version 1.0.0
assert resource does not have subdeployments (as it is not yet deployed anywhere)
4. go to ear.ear Configuration tab and assign it to several server groups (try to set various combinations of assignment enabled/disabled, runtimeName=something/empty)
5. wait a bit until ManagedDeployment resources appear on running Managed Servers
assert ManagedDeployment resource name is ear.ear with version 1.0.0
assert ManagedDeployment resource has subdeployments - versions not in resource name
6. subscribe DomainDeployment ear.ear to your content repo
7. go to 'Content' tab, 'New' subtab, and deploy ear-2.0.0.ear
assert success
assert ear.ear is available and it's resource version get's updated to 2.0.0 (you can check info message in agent.log)
assert ManagedDeployment resources are available (might go down for a short while) and their versions are 2.0.0
assert ManagedDeployment subdeployments have updated versions as well
assert runtimeName and enabled/disabled states are perserved after update - you can check this in DomainDeployment configuration tab and on ManagedDeployment's configuration and availability (DOWN=disabled)

d) Verify beavior of non-versioned deployments is not affected

 - execute content workflow on unversioned deployments

Comment 4 Libor Zoubek 2015-04-01 22:01:10 UTC
branch:  master
link:    https://github.com/rhq-project/rhq/commit/48e5671bb
time:    2015-04-01 19:18:16 +0200
commit:  48e5671bb20dc1a337291f335a66da5634226e50
author:  Libor Zoubek - lzoubek
message: Merge pull request #163 from lzoubek/bugs/1188751

         Bug 1188751 - Deploying Versioned WAR package from repository
         to JBOSS EAP 6  deployment resource fails

Comment 5 Michael Burman 2015-04-02 11:50:23 UTC
Cherry-picked to jon3.3.x:

commit aa78e35bfecaeacec006413d25b292bfecd84723
Author: Libor Zoubek <lzoubek>
Date:   Mon Mar 30 16:29:28 2015 +0200

    Bug 1188751 - Deploying Versioned WAR package from repository to JBOSS EAP 6
    deployment resource fails
    
    Support for updating package content for versioned deployments. This is
    performed by removing the original deployment and deploying the new one -
    using just redeploy wouln't work. In case of versioned DomainDeployment we
    unassign it to all server-groups, replace content and then assign back to
    the same server-groups.
    
    This commit also extracts code for setting deployment metadata on AS7 into
    Deployer class.
    
    (cherry picked from commit 2b77882f348095bebffc63e5a5461831d78d3bcb)

Comment 6 Libor Zoubek 2015-04-07 16:21:15 UTC
2 more related commits fixing tests


branch:  release/jon3.3.x
link:    https://github.com/rhq-project/rhq/commit/f68a54df5
time:    2015-04-07 18:20:27 +0200
commit:  f68a54df541a3f7c42e8be1297127e7202d48b7e
author:  Libor Zoubek - lzoubek
message: Bug 1188751 - Deploying Versioned WAR package from repository to JBOS

         Fix itests - removed test for creating deployment child to
         serverGroup resource (removed from code base prior 3.3)

         (cherry picked from commit
         cb3d26e9d014cdd3a8b91e5c0592fa9d1894d131) Signed-off-by: Libor
         Zoubek <lzoubek>
         


branch:  release/jon3.3.x
link:    https://github.com/rhq-project/rhq/commit/5f9baedcd
time:    2015-04-07 15:01:40 +0200
commit:  5f9baedcd78a7325bac562d372e5f39c117f0a33
author:  Michael Burman - miburman
message: [BZ 1208284] Override the default behavior of JMX plugin
         updateResourceConfiguration for the Storage Client methods

         (cherry picked from commit
         8f2d4783bd992c8cf0170815522edcd87bc32e76) Signed-off-by: Libor
         Zoubek <lzoubek>

Comment 7 Simeon Pinder 2015-04-13 04:14:37 UTC
Moving to ON_QA for testing with latest cumulative patch build:
https://brewweb.devel.redhat.com//buildinfo?buildID=429507

Note: Build maps to JON 3.3.2 ER01 build.

Comment 8 Armine Hovsepyan 2015-04-14 20:32:05 UTC
Created attachment 1014492 [details]
server.log

Comment 9 Armine Hovsepyan 2015-04-14 20:32:48 UTC
unable to deploy from repo -> see fragment from server.log attached

Comment 10 Libor Zoubek 2015-04-14 20:56:44 UTC
The error you get is not related to this BZ, fix for this BZ is entirely in AS7 plugin code. I am not sure what repro steps did you follow exactly, but according to server.log and code it looks like you are trying to Deploy package of a incompatible package type with AS7 Deployment. Or maybe you attempted to deploy from repo too quickly - it takes some time until package bits is detected

Could you provide more details or retry?

When uploading a package to repo, you must set it's type to File:Deployment or File:DomainDeployment

Comment 11 Armine Hovsepyan 2015-04-15 05:38:07 UTC
Created attachment 1014578 [details]
video

Comment 12 Armine Hovsepyan 2015-04-15 05:43:34 UTC
(In reply to Libor Zoubek from comment #10)
> The error you get is not related to this BZ, fix for this BZ is entirely in
> AS7 plugin code. I am not sure what repro steps did you follow exactly, but
> according to server.log and code it looks like you are trying to Deploy
> package of a incompatible package type with AS7 Deployment. Or maybe you
> attempted to deploy from repo too quickly - it takes some time until package
> bits is detected
> 
> Could you provide more details or retry?
> 
> When uploading a package to repo, you must set it's type to File:Deployment
> or File:DomainDeployment

I see your point. I'll file a separate ticket for non File types - there should not be error in logs and "nothing" on gui.

For file:Deployment it fails with no exception in logs.

Comment 17 Armine Hovsepyan 2015-06-17 14:20:37 UTC
Created attachment 1039973 [details]
content_deployment

Comment 18 Armine Hovsepyan 2015-06-17 14:21:00 UTC
Created attachment 1039974 [details]
eap.log_fragment

Comment 19 Armine Hovsepyan 2015-06-17 14:21:20 UTC
Created attachment 1039975 [details]
server.log_fragment

Comment 20 Armine Hovsepyan 2015-06-17 14:32:17 UTC
Created attachment 1039991 [details]
server.log_fragment2

Comment 21 Armine Hovsepyan 2015-06-17 14:43:24 UTC
Created attachment 1039993 [details]
versioned_nonversioned_deployment

Comment 22 Armine Hovsepyan 2015-06-17 14:44:19 UTC
verified with the following scenarios:

scenario 1

1. Install a war with version 1.0.0
2. create a repo and subscribe to installed war
3. install a new version from repo  -  e.g. 1.0.3

Actual results:
war is updated, current version is 1.0.3 (see attachments from comments 17-19)

Expected results:
war is updated, current version is 1.0.3

Note: If the type of the file != File (Deployment: AS7) - exception in server log is visible (see attachment from comment 20) 


scenario 2:


1. Install a war with version 1.2.0
2. create a repo and subscribe to installed war
3. install a new version from repo  which is not versioned (e.g. warname.war)

Actual results:
war is not updated, current version is 1.2.0 (see attachment from comments 21)

Expected results:
war is updated, current version is 1.2.0

Comment 23 Armine Hovsepyan 2015-06-17 15:27:16 UTC
marking as verified, see also 1232836


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