+++ This bug was initially created as a clone of Bug #784124 +++ Deploy a bundle without manageRootDir or manageRootDir=true (which is the defualt). See that it works. Today, me and jay are seeing it broken. --- Additional comment from ccrouch on 2012-01-24 09:38:07 EST --- We need to determine which versions this impacts --- Additional comment from mazz on 2012-01-24 13:25:26 EST --- looks like our unit tests in this area didn't cover this scenario. We do have covered the scenario where, upon initial deployment, the manageRootDir=false: org.rhq.plugins.ant.AntBundlePluginComponentTest.testAntBundleNoManageRootDir() but not the inverse. I just added: org.rhq.plugins.ant.AntBundlePluginComponentTest.testAntBundleManageRootDir() and it does indeed fail. What does this mean? It means if you have a destination directory (call it /dir/foo) and it isn't empty (i.e. it already has files in it), upon initial bundle deployment, those files will not be removed - they will remain even after the full bundle has been completely deployed. It is possible that upon bundle upgrade, those files will be removed. I'll add some tests to confirm. --- Additional comment from mazz on 2012-01-26 16:46:34 EST --- fyi: There are several other unit test classes covering the deployment stuff in core/util module. --- Additional comment from mazz on 2012-01-26 17:07:38 EST --- The problem here is that when you do an INITIAL bundle deployment, and you asked that RHQ manage the destination directory, any files that happened to already exist in the deployment's destination directory were not touched. This should not have been. The dest dir should have started empty because we are being told that we should manage the full destination directory content - which means if there are files in here that are NOT part of the bundle should be removed. This happened correctly during a bundle UPDATE but not when we did the initial deployment for the first time. Now, when we do the initial deployment AND we are to manage the destination directory, we will backup whatever files we find in the metadata directory's backup location, then we remove the files to get them out of the way. This ensures we start with a clean, empty destination directory. The main change was done in org.rhq.core.util.updater.Deployer.performInitialDeployment --- Additional comment from mazz on 2012-01-26 17:20:36 EST --- git commit to master: 9946f3e2b2b4b0a86ebe001594818f016a4c4130 --- Additional comment from mazz on 2012-01-27 10:03:37 EST --- forgot to fix a unit test... commited this to master: d8bd668 --- Additional comment from mfoley on 2012-01-31 13:32:23 EST --- Bundles: https://tcms.engineering.redhat.com/run/33098/ ---COMPLETE
Fix needs to brought back from master and committed to the JON 3.0.1 branch (release/jon3.0.x), checked by engineering and then pushed to MODIFIED state, then finally ON_QA when its available in a build for QE
release/jon3.0.x commit: 9eebf13
Moving to ON_QA for testing with JON 3.0.1.GA RC5 or better: https://brewweb.devel.redhat.com//buildinfo?buildID=199114
Verified on JON 3.0.1.GA RC5 (Build Number: dd8a001:fbca611) Deployed a bundle without manageRootDir and other with manageRootDir=true Verified that the initial deployment creates a backup for the existing files in the destination directory and the files are removed from destination directory. Below is the audit trail for initial deployment: DEPLOYMENT DETAILS: Added Files: 1 bundle-file.txt Deleted Files: 2 helloworld.war test.txt Changed Files: 0 Backed Up Files: 2 helloworld.war -> /install/test/.rhqdeployments/10011/backup/helloworld.war test.txt -> /install/test/.rhqdeployments/10011/backup/test.txt Restored Files: 0 Ignored Files: 0 Realized Files: 0 Was Cleaned?: false Errors: 0 Also verified that the manageRootDir=true creates a backup during upgrade. Below is the deployment audit trail: DEPLOYMENT DETAILS: Added Files: 0 Deleted Files: 1 testfile.txt Changed Files: 1 bundle-file.txt Backed Up Files: 1 testfile.txt -> /install/test/.rhqdeployments/10012/backup/testfile.txt Restored Files: 0 Ignored Files: 0 Realized Files: 0 Was Cleaned?: false Errors: 0
Bulk closing of old issues in VERIFIED state.