+++ This bug was initially created as a clone of Bug #758753 +++ Description of problem: CLI command updateBackingContent(fileName) for a resource does not persist correctly provided files. How reproducible: Every time Steps to Reproduce: 1. Create four versions of a WAR files to upload to a resource. 2. Use resource.updateBackingContent(fileName) consecutively to upload the versions of the file. Actual results: The WAR files are not replaced correctly with new content on the third and subsequent attempts. Expected results: The WAR file should be updated correctly each time updateBackingContent is invoked. Additional info: This problem is exclusive only to the CLI; the similar UI functionality works as expected. A code inspection uncovered signification implementation differences between UI and CLI. The solution is to update the CLI code to use the same APIs as the UI. Such update requires code changes in the CLI, server, and remote interfaces. --- Additional comment from snegrea on 2011-12-08 10:59:35 EST --- After further investigation this issue affects both the UI and CLI for deploying packages to content type resources. The CLI problem is more visible because the code relies on the existing version of a package to find the version for the current deployment. The UI has a less visible/obvious problem because the user is required to type the version of the package to be deployed and thus avoids retrieval of inconsistent data (see explanation below). The current deployment request life-cycle request is very complex; the big picture is this: 1) A package deployment is requested by the user. 2) The new packages are stored in the database. 3) Based on database information a request is generated for the agent 4) The agent receives the request and: a) copies the new packages to the correct location and sends the result of the deployment action back to the server. b) starts discovery processes for content, service and server; each of thse processes will then send their results back to the server. 5) The server receives the deployment response and does some database updates. 6) The server receives the discovery response and does some database updates. The root cause is missing/incorrect installed package information on the server. The server actions from 5 and 6 operate over the same data but they update slightly different content. The defect stems from the fact that steps 5 and 6 leave the server data inconsistent with the actual agent-side state. The issue is even more visible on Tomcat 6 because of unimplemented SHA computation functionality. Based on the current investigation code fixes are required only in the backend, agent, and plugins. This would resolve both the UI and CLI issues without explicit updates. --- Additional comment from mfoley on 2011-12-14 10:33:43 EST --- Notes on verification of this BZ and dependent BZs .... http://jbosson.etherpad.corp.redhat.com/59 --- Additional comment from snegrea on 2012-02-08 11:26:27 EST --- For verification please execute and refer to test cases for dependent bugs (in particular bug 761593, bug 767247, and bug 767393).
release/jon3.0.x branch commits: http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=49a2f346498403fdbea8f294f47f1aad56eb0d38 http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=c7c9adfb1dda4209dd645f09b47ce1de4fb687c0 http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=8e49dda1b0a81a1e14991bce421bb77c2bd01582 http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=28eb17664c8f687d34aac006df73570ff5ce6449 http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=cb0e9a2ffb9f274194014e70c17174a5ba2b08ef http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=f326faf2e95d0ce7f8fb642590bbea6905f0d2b2
Not verifiable in RC3. wait for RC4, or a build from jenkins 3.01 branch
From my testing I see that updateBackingContent works fine, but I was also checking what server returns and I doubt behaviour is correct. I have 5 versions of same war, version0.war is already deployed. I've deployed it as exploded. retrieveBackingContent - correct updateBackingContent(version1.war,"1.1") - server - OK - retrieveBackingContent - correctly returns version1.war - UI - correct updateBackingContent(version2.war,"1.2") - server - OK - retrieveBackingContent - correctly returns version2.war - UI - correct updateBackingContent(version3.war) (here I decided not to pass version) - server - returns content of version2 - INCORRECT - retrieveBackingContent - correctly returns version3.war - UI - correctly displays SHA instead of version updateBackingContent(version4.war,"1.4") - server - still returns content of version2 INCORRECT - retrieveBackingContent - correctly returns version4.war - UI - correct - detects sha missing, discovers version 1.4 - but in server deploy dir is version4.war My WARs differ only in content of index.jsp and that seems to be an issue. I've tried to repeat same scenario with "always passing version to updateBackingContent" and EAP server was always returning version0.war, this is the issue of jsp hot-deployment on server. Need to verify 761593,767247 and 767393 to make this BZ verified.
After exploring EAP server's log, server was not able to undeploy/redeploy content because of https://bugzilla.redhat.com/show_bug.cgi?id=790753
based on failures reported in comment #4, returning to ON_DEV
ok .. 790753 is non-blocking for JON 3.01
please retest with agent and AS5 using same user. returning to ON_QA
tested running agent and AS under same user, passed, need to verify 761593,767247 and 767393 to make this BZ verified
VERIFIED, passed for EAP4,5 and tomcat6, BZ id's in #c9 were wrong, corresponding BZs targeting 3.0.1 have been verified : 788762 788738 788773
Bulk closing of old issues in VERIFIED state.