Created attachment 568669 [details] contains 2 zip bundles to deploy Description of problem: Copied from : https://bugzilla.redhat.com/show_bug.cgi?id=801461 Customer is trying to deploy two files: root deployment directory == mydir file1 -> mydir/ file2 -> mydir/mysubdir/ The file deploy.xml defines manageRootDir=false First deploy is just fine, and the 2 files are there ok, and other files are not touched. Later, an upgraded deploy is needed and the whole bundle is redeployed. The end result is now: mydir/ is all fine, with file1 and all other files and subdirs unaffected. /mydir/mysubdir/ now contains the modified file2... BUT all other files in mysubdir have been deleted. Referring to https://bugzilla.redhat.com/show_bug.cgi?id=761212#c3 It is stated that "manageRootDir" *only* applies to the "root" dir. While taken literally this is indeed not a bug but nevertheless very counter-intuitive. Of course we realise the solution would be to create two bundles and deploy one to /mydir and the other to /mysubdir but we don't agree with the need. Example: we want to make a change to "login-conf.xml" in the "conf" directory of JBoss EAP, and deploy a new user/password xml file to "conf/props" It is illogical to do this in two bundles. Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1) Log onto JON server 2) Click on bundles tab 3) Click "New" 4) Choose "Uploade" and upload eap-config-bundle-1.0.zip (attached) 5) Click on the newly imported bundle 6) Click deploy 7) Type a name 8) Create a resource group, and choose as destination 9) Choose "Profile Directory" as base location 10) Type "conf" as the deployment directory, then click "Next" 11) Leave the default "Latest Version [1.0]" and click "Next" 12) Change the default values for properties to whatever you want and click "Next" 13) Leave all values as they are and click "Next" 14) Click "Finish" and verify that files login-conf.xml and jmx-console-users.properties were deployed and contain values you specified for properties 15) Expand "Destinations" under the bundle and click on the one the bundle was just deployed to 16) Click "Deploy" button 17) Leave the default "Latest Version [1.0]" selection and click "Next" 18) Change the properties to something different (this is, presumably the reason for re-deploying the same version of the bundle) and click "Next" 19) Leave everything as-is and click "Next" 20) Click "Finish" 21) Notice that this time, although the files were deployed as expected with new property values, all files under conf/props other than the jmx-console-users.properties file have been deleted. I wouldn't expect this to happen, based on the behaviour that resulted from the first deployment. Furthermore, say I don't like that behaviour and decide to remove the jmx-console-users.properties file from this bundle in order to manage it separately: 22) Copy the missing conf/props file from the original "default" profile and replace the ones that were deleted in test1 and test2 23) Go to the Bundles tab and click "New" 24) Click "Upload" and choose eap-config-bundle-2.0.zip then click "Next" 25) Click "Next" again 26) Click "Finish" 27) Expand the bundle, expand Destinations and click on the destination that was previously deployed to 28) Click "Deploy" 29) keep "Latest Version [2.0]" and click "Next" 30) Change property values and click "Next" 31) Leave all values as they are and click "Next" 32) Click "Finish" 33) Notice that login-conf.xml was successfully deployed, but all files in conf/props were deleted, even though this version of the package contains no reference to the props directory. Actual results: files in sub directories get deleted which is illogical Expected results: manageRootDir should really be "manageDir" and apply to root + subdirs Additional info:
I will need to dig into this issue a bit more. There seems to be some confusion in how this works and how this is working. Basically, if the update bundle does not contain the same files as the original bundle and those original files aren't explicitly named to be ignored, they will be deleted. On the other hand, if the original bundle didn't touch a sub-directory in the deploy directory and manageRootDir is false and the new version doesn't touch a sub-directory, the sub-directory should be left intact.
After further testing and consideration, the upstream Bug 801461 has been closed as 'not a bug'. Instead, Bug 801926 has been logged to identify the use-case that is identified here and the further investigate what should be happening. The steps to reproduce listed in the description (Comment 0) do not work as they stand and require specifics that are not related to the actual issue. Here are the updated steps: 1. Install JON server and agent 2. Start JON server and agent 3. Import platform and agent into inventory 4. Create a Dynagroup named `All Platforms` with the following *Expression*: resource.type.category = PLATFORM groupby resource.name 5. Create a new bundle using simple-bundle-1.0.zip 6. Setup deployment destination/root by creating some existing content # Make sure the old stuff is gone if it exists rm -r "${TESTENV_DIR}/deploy-dest" # Our destination directory mkdir -p "${TESTENV_DIR}/deploy-dest" # Some file in the root of the destination echo "File 1 in root" >"${TESTENV_DIR}/deploy-dest/file1" echo "File 2 in root" >"${TESTENV_DIR}/deploy-dest/file2" # A sub-directory in the root of the destination mkdir -p "${TESTENV_DIR}/deploy-dest/dir1" echo "File 1 in Dir 1" >"${TESTENV_DIR}/deploy-dest/dir1/file1" echo "File 2 in Dir 1" >"${TESTENV_DIR}/deploy-dest/dir1/file2" # Another sub-directory in the root of the destination mkdir -p "${TESTENV_DIR}/deploy-dest/dir2" echo "File 1 in Dir 2" >"${TESTENV_DIR}/deploy-dest/dir2/file1" echo "File 2 in Dir 2" >"${TESTENV_DIR}/deploy-dest/dir2/file2" Prior to deploying the bundle to a destination, the destination will look like: . |-- dir1 | |-- file1 | `-- file2 |-- dir2 | |-- file1 | `-- file2 |-- file1 `-- file2 7. Deploy the bundle to the destination created previously * *Destination Name:* `Test 001` * *Resource Group:* `DynaGroup - All Platforms ( loleary )` * *Deployment Directory:* *${TESTENV_DIR}/deploy-dest* * *Latest Version [1.0]* * *user.input.1* `User Value One` At this point, the deploy-dest should contain changes to file1 and dir1/file2. . |-- dir1 | |-- file1 | `-- file2 (Replaced by bundle) |-- dir2 | |-- file1 | `-- file2 |-- file1 (Replaced by bundle) `-- file2 8. Redeploy the bundle to this same destination 1. Expand and select *Simple Bundle / Destinations / Test 001 2. Click the *Deploy* button * *Latest Version [1.0]* * *user.input.1* `User Value Two` Now the deploy-dest contains file1 and dir1/file2 with the updated user.input.1 value but dir1/file1 is now gone. This was unexpected seeing that dir1/file1 is not and was not in the original deployed bundle. . |-- dir1 | |-- file1 (!! File got deleted !!) | `-- file2 (Replaced by bundle) |-- dir2 (Left alone due to manageRootDir=false) | |-- file1 (Left alone due to manageRootDir=false) | `-- file2 (Left alone due to manageRootDir=false) |-- file1 (Replaced by bundle) `-- file2 (!! File got deleted !!) Depending on the result of Bug 801461 and its determination on whether what was seen after step 7 is correct or what was seen after step 8 is correct, the expectation is that post step 7 and post step 8 should be consistent. From a user perspective and package management perspective, what is seen after step 7 is what is correct due to the manageRootDir=false. It does not make sense that only some of the contents of the deployment directory won't be blown away while other stuff, not inside the bundle, end up being deleted.
Sorry, previous comment should have read ... Depending on the result of Bug 801926 and its determination on whether what was...
Created attachment 569026 [details] simple-bundle for testing (simple-bundle-1.0.zip Bundle with the structure: . |-- deploy.xml |-- file1 `-- file2 Which contains a deploy.xml with manageRootDir=false and will result in a deploy structure like: . |-- dir1 | `-- file2 `-- file1
per BZ triage (asantos, ccrouch, loleary, mfoley)
Having discussed this with Larry, we believe it makes sense to move the discussion around an alternative name for the manageRootDir property that had been going over in the comments of bug 801926 over to bug 801464. This is because the fundamental issue behind 801464 is misinterpreting what the manageRootDir property does, where as 801926 is more around whether manageRootDir is doing the right thing or not. The general plan is to investigate what can be done to mitigate the confusion around manageRootDir in the near team, hence 801464 will be targeted at JON3.1.1. 801926 will be closed as working as expected, since there have been no bugs identified in the current execution of the bundle subsystem with respect to the managedRootDir propert. Instead an RFE will be raised to extend the bundle subsystem to support a more generalized set of provisioning use cases, one sort Larry advocates for here: https://bugzilla.redhat.com/show_bug.cgi?id=801926#c11
As per 8/20 triage pushing to JON312
This is in master, see BZ 801926 for the chosen implementation strategy.
verified on JON 3.2.0.ER4