Bug 801464

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