Bug 801464 - manageRootDir=false is inconsistent when bundle contains a sub-directory or uses a sub-directory which already exists in the destination
manageRootDir=false is inconsistent when bundle contains a sub-directory or u...
Status: CLOSED CURRENTRELEASE
Product: JBoss Operations Network
Classification: JBoss
Component: Provisioning (Show other bugs)
JON 3.0.0
All All
high Severity high
: ER01
: JON 3.2.0
Assigned To: RHQ Project Maintainer
Mike Foley
:
Depends On: 801926 802537 807411 824577
Blocks: 1061500
  Show dependency treegraph
 
Reported: 2012-03-08 10:35 EST by Tom Fonteyne
Modified: 2014-02-04 19:25 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-01-02 15:37:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
contains 2 zip bundles to deploy (5.04 KB, application/zip)
2012-03-08 10:35 EST, Tom Fonteyne
no flags Details
simple-bundle for testing (simple-bundle-1.0.zip (913 bytes, application/zip)
2012-03-09 20:20 EST, Larry O'Leary
no flags Details

  None (edit)
Description Tom Fonteyne 2012-03-08 10:35:39 EST
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:
Comment 1 Larry O'Leary 2012-03-09 11:02:47 EST
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.
Comment 2 Larry O'Leary 2012-03-09 20:13:19 EST
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.
Comment 3 Larry O'Leary 2012-03-09 20:17:04 EST
Sorry, previous comment should have read 

...
Depending on the result of Bug 801926 and its determination on whether what was...
Comment 4 Larry O'Leary 2012-03-09 20:20:11 EST
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
Comment 5 Mike Foley 2012-03-19 12:18:52 EDT
per BZ triage (asantos, ccrouch, loleary, mfoley)
Comment 6 Charles Crouch 2012-05-30 16:40:01 EDT
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
Comment 8 Charles Crouch 2012-08-29 12:13:01 EDT
As per 8/20 triage pushing to JON312
Comment 11 Lukas Krejci 2013-08-15 07:36:09 EDT
This is in master, see BZ 801926 for the chosen implementation strategy.
Comment 12 Libor Zoubek 2013-11-05 10:51:17 EST
verified on JON 3.2.0.ER4

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