Red Hat Bugzilla – Bug 771418
CLI Method updateBackingContent Does Not Allow User to Set Version
Last modified: 2013-09-01 06:17:29 EDT
Description of problem: The CLI method updateBackingContent does not allow users to set the version of the deploy package. The version is automatically incremented based on the version already installed. This creates problems because the incrementing algorithm does not always produce optimal results. Also, it limits users ability to keep the versioning scheme consistent between UI and CLI. How reproducible: Every time. Steps to Reproduce: 1. Use CLI to locate a webapp resource on a JBoss or Tomcat server. 2. Use updateBackingContent on the resource. Actual results: updateBackingContent method allows users to only specify the file name. Expected results: updateBackingContent should allow users to specify the file name and version of the file uploaded. Additional info: By allowing users to provide the version, the CLI interface will be consistent with the UI. The version provided by the user should be used as display version, the actual version of the package should still be SHA256.
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 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 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.updateBackingContent("/resources/new/newcontent.war", "1.2") 5) 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 in Step 2, the CLI allows the user to enter a version. 3) 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.
Some negative test cases for the first test case (comment 1): 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=3bfbb166f8d9a5b821869a0462acc677c0b879b2 http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=cdd378b2cf0b8819f70960a704fd66e14d5e00a1 http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=b1f4739b249968d01c1ade6ca0f6bc7ee930f61c http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=04a56516c22a106620aad8fa9ca3349b50bd6810 http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=6d15c4f3ee59ee0922410cd488b5eda32fd1b5cc http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=9ce3f7f9ee5dae9e68e5413d146082fb1aeeb92d
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.