Bug 788733

Summary: Recreated (deleted then created) package backed resources maintain old backing package assignment
Product: [Other] RHQ Project Reporter: Stefan Negrea <snegrea>
Component: No ComponentAssignee: Stefan Negrea <snegrea>
Status: CLOSED CURRENTRELEASE QA Contact: Mike Foley <mfoley>
Severity: high Docs Contact:
Priority: high    
Version: 4.3CC: cwelton, hrupp, jshaughn, lzoubek, snegrea
Target Milestone: ---   
Target Release: JON 3.0.1   
Hardware: All   
OS: All   
URL: http://jira.rhq-project.org/browse/RHQ-2387
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: RHQ-2387 Environment:
Last Closed: 2013-09-03 11:04:19 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On: 535720    
Bug Blocks: 788629    

Description Stefan Negrea 2012-02-08 17:06:55 EST
+++ This bug was initially created as a clone of Bug #535720 +++

Create New a package backed resource, like a Tomcat WAR

Update the package, say, deploy a new version of the webapp.

Delete the WAR

  - note, this delete only marks the resource as DELETED, it maintains all the relationships, like history etc, *installed package*, etc

Recreate the WAR (same app name) with a different version of the app than was last deployed (for example, the original version)

Although the deploy works and the desired bits are being run for Tomcat, the InstalledPackage is the same as it was when we deleted the resource. So, retrieving backing package info is incorrect.  Also, the installed package history looks weird in the GUI since the wrong info is displayed.

This scenario is probably limited outside of testing but the result can be pretty bad if you do in fact run into this.

--- Additional comment from ccrouch@redhat.com on 2009-08-27 13:00:46 EDT ---

Marking for 1.3, for triage purposes

(10:47:31 AM) ccrouch: jshaughn: this is presumably how it worked in 2.2 too?
(10:47:52 AM) jshaughn: I believe so, I marked it 1.3pre
(10:48:30 AM) jshaughn: I think it's an unlikely scenario
(10:48:43 AM) ccrouch: right
(10:49:28 AM) ccrouch: also we dont end up deploying the wrong thing
(10:49:38 AM) jshaughn: that's correct
(10:49:42 AM) ccrouch: so i dont think its huge
(10:51:28 AM) jshaughn: It's bad in that the Deployed version info (current and history) in the GUI is wrong and that if you get the backing package via, say, a script, it's the wrong bits.

--- Additional comment from bugzilla@redhat.com on 2009-11-10 16:03:24 EST ---

This bug was previously known as http://jira.rhq-project.org/browse/RHQ-2387

--- Additional comment from snegrea@redhat.com on 2012-01-16 10:45:20 EST ---

The reported problem should now be fixed due to the content system changes. The unit tests need to be updated to add back code affected by the reported problem.

--- Additional comment from mfoley@redhat.com on 2012-01-23 15:26:56 EST ---

Verification steps for QE

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

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 snegrea@redhat.com on 2012-02-08 12:16:57 EST ---

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.
Comment 1 Stefan Negrea 2012-02-08 17:11:33 EST
release/jon3.0.x branch commit:

Comment 2 Simeon Pinder 2012-02-10 17:44:51 EST
Moving to ON_QA as new RC 4 available to test in:
Comment 3 Libor Zoubek 2012-02-24 06:43:43 EST
Passed above verification steps. And .. I've also deleted the resource with war and created it once again, uploaded same war with different version. History of given resource did not disappear, I was able to see all CLI deployment requests with correct SHAs and versions.

deployed sha X, version 1
deployed sha Y, version 2
deleted resource
deployed sha X, version 3

and then in history: version 1 was replaced with version 3.
Comment 4 Heiko W. Rupp 2013-09-03 11:04:19 EDT
Bulk closing of old issues in VERIFIED state.