Bug 788762

Summary:	JBoss AS4 Plugin - SHA256 For Exploded Deployments Not Used Correctly
Product:	[Other] RHQ Project	Reporter:	Stefan Negrea <snegrea>
Component:	Plugins	Assignee:	Stefan Negrea <snegrea>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Mike Foley <mfoley>
Severity:	high	Docs Contact:
Priority:	high
Version:	4.3	CC:	hrupp, lzoubek
Target Milestone:	---
Target Release:	JON 3.0.1
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	767247	Environment:
Last Closed:	2013-09-03 15:02:26 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	767247
Bug Blocks:	788629

Description Stefan Negrea 2012-02-08 23:31:07 UTC

+++ This bug was initially created as a clone of Bug #767247 +++

Description of problem:
For the JBoss AS4 plugin, the SHA256 is not returned correctly by the plugin during discovery. Also, the SHA256 is not saved properly if the deployment does not have a manifest file.

How reproducible:
Every time.

Steps to Reproduce:
1. Inventory an AS4 server.
2. Prepare a sample war file without a manifest file and folder.
2. Update an existing exploded webapp through the CLI using the sample war.
3. Browse and view the content of the manifest file for the deployed app (look into the server deployment folder).
4. Wait for the discovery process to take place and notice that the SHA256 is not returned correctly to the server.
  
Actual results:
There is no manifest file. The SHA256 returned to the server is null.

Expected results:
The manifest file is present and the RHQ-Sha256 attribute is present in the main section. The SHA256 returned to the server is the one computed during deployment.

Additional info:
There are several problems with saving the manifest file as well in the discovery process. This plugin should behave like the corrected and enhanced Tomcat plugin.

--- Additional comment from mfoley on 2012-01-23 15:24:09 EST ---

Verification Steps for QE

Setup:
1) RHQ server started, RHQ agent running, CLI connected to RHQ server
2) Inventoried Tomcat Server, JBoss AS4 or JBoss EAP5.1
3) Need the ID of a content backed resource, eg. an application resource. The ID can be retrieved from the UI http://localhost:7080/coregui/#Resource/14932, the last portion of the url is the ID of the resource.
4) A sample war application to be deployed to the application server
5) A folder to backup applications from the server

Stimulate:
1) Navigate in the UI to the selected application resource, content tab, history subtab.
2) From the CLI run the following commands:
3) applicationResource = ProxyFactory.getResource(14932)
4) applicationResource.retrieveBackingContent("/resources/backup/original.war")
5) applicationResource.updateBackingContent("/resources/new/newcontent.war", "1.2")
6) applicationResource.retrieveBackingContent("/resources/backup/updated.war")
7) Navigate in the UI to the resource that was just updated to the Content tab

Verification steps:
1) Verify that after Step 1, the Full Package Audit Trail table, version column has either a normal number (eg. 1.2.3) or sha256. The version field should not be empty.
2) Verify that the archive retrieved in Step 3 is the exact archive that was deployed on the server before running the test
3) Verify that after Step 4 the new application has been actually deployed on the application server. Check the file system where the application server deploys content.
4) Verify that after Step 4 the new application has RHQ-Sha256 attribute in the manifest.
5) Verify that after Step 5 the archive downloaded is the application deployed in Step 4
6) Verify the content tab, history subtab has the following:
  a) Full Package Audit Trail table has the correct package information marked as Discovered, including correct version.
  b) Completed Requests table has information regarding the request submitted from the CLI, including submitted version.

--- Additional comment from mfoley on 2012-01-23 15:30:12 EST ---

2nd verification step for QE



UI Test (applicable to BZ 761593, 767247, 767393, 769986)

Setup:
1) RHQ server started, RHQ agent running
2) Inventoried Tomcat Server, JBoss AS4 or JBoss EAP5.1
3) A sample war application to be deployed to the application server

Stimulate:
1) Navigate in the UI to the selected application resource, content tab, history subtab.
2) Navigate to the New subtab.
3) Upload a new war package for the resource. Follow the guided UI but do change the version field to something unique.
4) Navigate in the UI to the resource that was just updated to the Content tab

Verification steps:
1)  Verify that after Step 1, the Full Package Audit Trail table, version  column has either a normal number (eg. 1.2.3) or sha256. The version  field should not be empty.
2)  Verify after Step 4 the new application has been actually deployed  on the application server. Check the file system where the application  server deploys content.
3) Verify after Step 4 the new application has RHQ-Sha256 attribute in the manifest.
4) Verify after Step 4 the content tab, history subtab has the following:
  a) Full Package Audit Trail table has the correct package information marked as Discovered, including correct version.
  b) Completed Requests table has information regarding the request submitted from the CLI, including submitted version.

--- Additional comment from snegrea on 2012-02-08 17:54:26 EST ---

Some negative test cases for the first test case noted in this BZ:

1) Step 4, point to an existing file
2) Step 5, point to a non-existing file
3) Step 6, retrieve content twice in two separate files and then compare the
results
4) Step 5, repeat the step with a different version. Observe in the UI that
that version is from the last call and two entries in the deployment log.

Comment 1 Stefan Negrea 2012-02-08 23:48:47 UTC

release/jon3.0.x branch commits:

http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=3a4fd88f670392e36c346b940f16d034ebd4bc56

http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=9a7e8920d7990e3361ae19b3dd58c1fc7e436ff5

http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=c48f7706b5de9560678550b4bdaad5dec5d00513

http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=697319d2f28b8c1c139eb0825dfbaa3681b90a33

http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=18c248ecc7540319bd5ee4045ba6e51632c8647d

Comment 2 Simeon Pinder 2012-02-10 22:44:47 UTC

Moving to ON_QA as new RC 4 available to test in:
https://brewweb.devel.redhat.com//buildinfo?buildID=198384

Comment 3 Libor Zoubek 2012-02-20 15:06:34 UTC

--- Additional comment from mfoley on 2012-01-23 15:30:12 EST ---
UI Test - 2nd verification step for QE

3.0.1.GA dd8a001:fbca611

Verification Step 2) fails

application is no longer accessible on server (via HTTP)

This is what EAP 4.3.CP10 (default profile) outputs:

15:43:05,282 INFO  [TomcatDeployer] deploy, ctxPath=/hello,
warUrl=.../deploy/hello.war/
15:44:20,585 INFO  [TomcatDeployer] deploy, ctxPath=/hello,
warUrl=.../tmp/deploy/tmp2120379007588589648hello-exp.war/
15:44:20,946 INFO  [TomcatDeployer] undeploy, ctxPath=/hello,
warUrl=.../deploy/hello.war/

Original archive was deployed as exploded, after updating it using content system it is no longer exploded in server deploy dir.

according to server log, it looks like JON does not undeploy application prior
to deploying new version

Comment 4 Stefan Negrea 2012-02-21 16:04:00 UTC

The reported behaviour is not a regression with regards to the content system and deployments for existing applications. I recommend opening a new BZ focused solely on deployment issues discovered above.

Comment 5 Libor Zoubek 2012-02-21 16:40:21 UTC

Created https://bugzilla.redhat.com/show_bug.cgi?id=795851

<stefan_n> so for the tests I would suggest to use one of the existing apps
that is already exploded
<stefan_n> and deploy content to it ....
<stefan_n> it should be exploded
<stefan_n> does it make sense?
<lzoubek> like for instance jmx-console.war?
<stefan_n> yeap
<stefan_n> that is a good example

I am getting same results for jmx-console too. I am still unable to verify.

Comment 6 Stefan Negrea 2012-02-22 16:33:37 UTC

Updated cases due to bug 795851 . All deployments are archived and there is no way to redeploy an application exploded. The SHA256 should still be reported back to the JON server but no manifest file is created or updated.


Test Case 1 - CLI

Setup:
1) RHQ server started, RHQ agent running, CLI connected to RHQ server
2) Inventoried Tomcat Server, JBoss AS4 or JBoss EAP5.1
3) Need the ID of a content backed resource, eg. an application resource. The
ID can be retrieved from the UI http://localhost:7080/coregui/#Resource/14932,
the last portion of the url is the ID of the resource.
4) A sample war application to be deployed to the application server
5) A folder to backup applications from the server

Stimulate:
1) Navigate in the UI to the selected application resource, content tab,
history subtab.
2) From the CLI run the following commands:
3) applicationResource = ProxyFactory.getResource(14932)
4) applicationResource.retrieveBackingContent("/resources/backup/original.war")
5) applicationResource.updateBackingContent("/resources/new/newcontent.war",
"1.2")
6) applicationResource.retrieveBackingContent("/resources/backup/updated.war")
7) Navigate in the UI to the resource that was just updated to the Content tab

Verification steps:
1) Verify that after Step 1, the Full Package Audit Trail table, version column
has either a normal number (eg. 1.2.3) or sha256. The version field should not
be empty.
2) Verify that the archive retrieved in Step 3 is the exact archive that was
deployed on the server before running the test
3) Verify that after Step 4 the new application has been actually deployed on
the application server. Check the file system where the application server
deploys content.
5) Verify that after Step 4 the archive downloaded is the application deployed
in Step 4
6) Verify the content tab, history subtab has the following:
  a) Full Package Audit Trail table has the correct package information marked
as Discovered, including correct version.
  b) Completed Requests table has information regarding the request submitted
from the CLI, including submitted version.
7) Optional Step: check the database and verify that the package has the actual SHA256 of the archive in the SHA256 and version fields.

NOTE: because deployments are archived, there is no manifest file updated in the deployment. However, the SHA256 is still reported back to JON server.

Some negative tests cases:
1) Step 4, point to an existing file
2) Step 5, point to a non-existing file
3) Step 6, retrieve content twice in two separate files and then compare the
results
4) Step 5, repeat the step with a different version. Observe in the UI that
that version is from the last call and two entries in the deployment log.

Test Case 2 - UI
Setup:
1) RHQ server started, RHQ agent running
2) Inventoried Tomcat Server, JBoss AS4 or JBoss EAP5.1
3) A sample war application to be deployed to the application server

Stimulate:
1) Navigate in the UI to the selected application resource, content tab,
history subtab.
2) Navigate to the New subtab.
3) Upload a new war package for the resource. Follow the guided UI but do
change the version field to something unique.
4) Navigate in the UI to the resource that was just updated to the Content tab

Verification steps:
1)  Verify that after Step 1, the Full Package Audit Trail table, version 
column has either a normal number (eg. 1.2.3) or sha256. The version  field
should not be empty.
2)  Verify after Step 4 the new application has been actually deployed  on the
application server. Check the file system where the application  server deploys
content.
3) Verify after Step 4 the content tab, history subtab has the following:
  a) Full Package Audit Trail table has the correct package information marked
as Discovered, including correct version.
  b) Completed Requests table has information regarding the request submitted
from the CLI, including submitted version.
4) Optional Step: check the database and verify that the package has the actual SHA256 of the archive in the SHA256 and version fields.

NOTE: because deployments are archived, there is no manifest file updated in the deployment. However, the SHA256 is still reported back to JON server.

Comment 7 Libor Zoubek 2012-02-24 11:09:24 UTC

Thank you for new verification steps.

versions and SHAs of my WAR in rhq_resource_version table match uploaded and retrieved SHAs using both CLI and UI

Comment 8 Heiko W. Rupp 2013-09-03 15:02:26 UTC

Bulk closing of old issues in VERIFIED state.