Bug 790148 - JON 3.01 RC4, CLI Documentation addition/changes around updateBackingContent has new overloaded method
JON 3.01 RC4, CLI Documentation addition/changes around updateBackingContent ...
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: Documentation (Show other bugs)
3.0.1
Unspecified Unspecified
high Severity high (vote)
: ---
: JON 3.0.1
Assigned To: Deon Ballard
Mike Foley
:
Depends On: 771418 789014
Blocks: 788629
  Show dependency treegraph
 
Reported: 2012-02-13 13:51 EST by Mike Foley
Modified: 2012-06-21 19:13 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 789014
Environment:
Last Closed: 2012-06-21 19:13:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Mike Foley 2012-02-13 13:51:49 EST
+++ This bug was initially created as a clone of Bug #789014 +++
The documentation (API doc, examples) should reflect that the CLI api changes ... and that the updateBackingContent() method has a new method in JON 3.01 RC4






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

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.

--- Additional comment from mfoley@redhat.com on 2012-01-23 15:26:13 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@redhat.com on 2012-01-23 15:32:42 EST ---

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.

--- Additional comment from snegrea@redhat.com on 2012-02-09 10:38:22 EST ---

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.

--- Additional comment from snegrea@redhat.com on 2012-02-09 10:44:39 EST ---

release/jon3.0.x branch commits:

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

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

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

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

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

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

--- Additional comment from spinder@redhat.com on 2012-02-10 17:44:54 EST ---

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

--- Additional comment from mfoley@redhat.com on 2012-02-13 13:48:19 EST ---

I was able to execute this command ... which sets the version



rhqadmin@localhost:7080$ applicationResource.updateBackingContent("GuessANumber4.war", 7)


I will attach an image to document the verification that the UI reflects this.

--- Additional comment from mfoley@redhat.com on 2012-02-13 13:49:34 EST ---

Created attachment 561638 [details]
image documenting i was able to specify a version from the CLI
Comment 2 Deon Ballard 2012-06-21 19:13:36 EDT
Closing.

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