Bug 767393

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.

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.

Some negative test 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.

master branch commits:

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

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

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

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

4) Verify that after Step 4 the new application has RHQ-Sha256 attribute in the
manifest.

Manifest contains above attribute, but that SHA contains newline which does not seem to be correct 

cat hello.war/META-INF/MANIFEST.MF 
Manifest-Version: 1.0
RHQ-Sha256: 8040b1deff4a70aa4e6821c9bbff2bc96b3bd44f6c12c95bdddb5729a9
 8a1128

Not sure whether that SHA value is ever read from manifest, because otherwise it works.

Stefan, is the wrong SHA an issue?

The Manifest class distributed with Java does enforce 72 characters per line limit. This manifest implementation can read back correctly text split across multiple lines. So, the SHA256 value is correctly written to the manifest using default Java implementation and it will be read back correctly.

As far as usage goes, the SHA256 value is used every time the discovery process runs. That value is written in the manifest to avoid repeated resource intensive SHA calculations every time the discovery process runs.

A way to check if the SHA is correctly read: navigate to Content tab -> History subtab for the resource under test. There should be only SHA256 values that are 64 characters long. If the value is not read correctly you would see SHA256 values with different lengths. In particular you would notice SHA values that are 58 and 64 characters. You could also check directly the database by looking the rhq_installed_package table (SHA256 field) and make sure the SHA256 value is always 64 characters long.

Tested it on exploded war without manifest, need to test on unexploded deployment and on deployment having manifest.

moving back ON_QA, I was verifying this on 3.0.1 branch not master

Bulk closing of items that are on_qa and in old RHQ releases, which are out for a long time and where the issue has not been re-opened since.