Bug 801461 - manageRootDir counter-intuitive
Summary: manageRootDir counter-intuitive
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: RHQ Project
Classification: Other
Component: Provisioning
Version: 4.2
Hardware: All
OS: All
unspecified
high
Target Milestone: ---
: ---
Assignee: RHQ Project Maintainer
QA Contact: Mike Foley
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-03-08 15:30 UTC by Tom Fonteyne
Modified: 2012-03-10 01:15 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2012-03-10 00:49:09 UTC
Embargoed:


Attachments (Terms of Use)
contains 2 zip bundles to deploy (5.04 KB, application/zip)
2012-03-08 15:30 UTC, Tom Fonteyne
no flags Details

Description Tom Fonteyne 2012-03-08 15:30:50 UTC
Created attachment 568668 [details]
contains 2 zip bundles to deploy

Description of problem:

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:

Comment 1 David van Balen 2012-03-08 17:03:41 UTC
Also, note 2 issues above and beyond the basic issue of manageRootDir only applying to the root directory, and not subdirectories:

1) The first time the bundle is deployed, the entire contents of the props directory is preserved. It's only deleted on a subsequent deployment of the same bundle, with different values for the input properties

2) If a new version of the bundle is uploaded, which no longer deploys a file to the props directory, the content of that directory is still deleted, while the content of other directories is preserved.

Comment 2 Larry O'Leary 2012-03-10 00:49:09 UTC
Closing this as NOT A BUG as the behavior described here is essentially the correct one. The cause for the confusion is a use case that was not implemented in the original design of provisioning bundle support and the introduction of the new manageRootDir property. In other words, prior to the introduction of this property, everything would be replaced on update/redeploy that was not in the ignore list in the recipe file.

The bug that currently exists is that on the initial deploy, the undesired behavior described in the update/redeploy scenarios should have also occurred. However, such a bug may not exist if we can decide what the correct behavior should be.

Bug 801926 has been captured to more specifically target the crux of this issue and the enhancement/feature consideration to alleviate the confusion and the inconsistent behavior.


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