Bug 802537

Summary: make initial deploy consistent with update/redeploy when using manageRootDir=false
Product: [Other] RHQ Project Reporter: John Mazzitelli <mazz>
Component: ProvisioningAssignee: RHQ Project Maintainer <rhq-maint>
Status: CLOSED CURRENTRELEASE QA Contact: Mike Foley <mfoley>
Severity: high Docs Contact:
Priority: medium    
Version: 4.3CC: dlackey, dvanbale, hrupp, loleary
Target Milestone: ---   
Target Release: RHQ 4.4.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 824577 (view as bug list) Environment:
Last Closed: 2013-09-01 10:06:26 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 801464, 824577    
Attachments:
Description Flags
no-manage-root-dir.zip none

Description John Mazzitelli 2012-03-12 19:04:38 UTC 
We need to make the initial deploy to a destination consistent
with the update/redeploy to the same destination.

Today, the behavior is inconsistent. When you deploy the bundle for the first time to
a destination and manageRootDir=false, we do not touch any of the files or
subdirectories in the destination directory even when the bundle has the same
subdirectory but on redeploy we do cleanup those files not in the bundle.

To illustrate:

bundle.zip:
   subdir/foo.txt


dest-dir:
   subdir/bar.txt


On initial deploy I end up with:

dest-dir:
   subdir/bar.txt
   subdir/foo.txt


But on update or redeploy I end up with:

dest-dir:
   subdir/foo.txt

Bug #801926 is related - that relates to what we want the behavior to actually be in this case.

But for this issue, we want to make the behavior consistent one way or the other. I will attempt to fix this so the "update" behavior is how the initial deploy should behave. In other words, after the initial deploy, we should have:

dest-dir:
   subdir/foo.txt

because this was the original intent with the bundle system. In other words, the bundle itself defines EVERYTHING under the deployment main directory (so whatever the bundle says should be in subdir should be in subdir - no less and NO MORE). The manageRootDir=false means "do not manage the ROOT directory (only)" but all subdirectories will be fully managed by the bundle (which is why update acts as it does and why I want the initial deploy to work like the update does).

See Bug #801926 in regards to whether this SHOULD be the way it works in the future - if not, we will need to keep in mind backwards compat issues, documentation issues and the amount of time it would take to change the behavior of manageRootDir=false. I suspect we will need to add something like "manageSubDirs=false" to do what it currently the initial deploy behavior (that is, leave any existing files alone in all subdirectories). But that's just a guess - again, bug #801926 will track that.
Comment 1 Charles Crouch 2012-03-13 14:01:22 UTC 
This is a BIG change in behaviour and needs to heavily emphasized in our docs and release notes.
Comment 2 John Mazzitelli 2012-03-13 21:40:25 UTC 
master commit: 53e63b7
Comment 3 John Mazzitelli 2012-03-14 15:43:05 UTC 
Created attachment 570020 [details]
no-manage-root-dir.zip

a bundle distribution file, no-manage-root-dir.zip, is attached to use to test this. here's how:

1) create a place on your file system to deploy this bundle (e.g. /tmp/testdir)
2) create some "extra" files in here so they are "in the way" of the bundle you will be deploying. These will represent files that would be already existing in an existing destination directory. Create these specific files in order to exercise the fix:
   /tmp/testdir/subdir/extra-file.txt
   /tmp/testdir/subdir2/extra-file2.txt
   /tmp/testdir/extradir/extra-file3.txt
   /tmp/testdir/extra-file4.txt
3) import a platform and put it into a test group to be used as the target where you will deploy the bundle.
4) upload no-manage-root-dir.zip via the bundle upload wizard
5) deploy the bundle to your test platform group created in step 3, with a bundle destination set to your test directory you created in step 1 (e.g. /tmp/testdir).

Now look at what is in your test directory (/tmp/testdir) and make sure

a) the subdir/extra-file.txt was removed (it will have been backed up in /tmp/testdir/.rhqdeployments/#####) - this was removed because the bundle declared it will be managing that subdirectory by virtue of the recipe's <rhq:file> whose destinationDir is "subdir"

b) the subdir2/extra-file2.txt was removed (it will also have been backed up) - this was removed because the bundle declared it will be managing that subdirectory by virtue of the fact that the recipe declared a <rhq:archive> which has "subdir2" inside of it.

c) the two other extra files (extradir/extra-file3.txt and extra-file4.txt) were not removed because the recipe declared manageRootDir=false and extradir and extra-file4.txt were in the root directory (and not otherwise specified by the bundle recipe - so they are to be left alone).
Comment 4 Charles Crouch 2012-05-23 18:56:42 UTC 
Set components correctly. I opened bug 824577 to track the documentation update for this.
Comment 5 Heiko W. Rupp 2013-09-01 10:06:26 UTC 
Bulk closing of items that are on_qa and in old RHQ releases, which are out for a long time and where the issue has not been re-opened since.