Rename manageRootDir property in bundles

Lukas Krejci lkrejci at redhat.com
Thu Aug 1 22:47:39 UTC 2013


I'm going to go with the following names:

manageRootDir=true -> compliance="full"
manageRootDir=false -> compliance="filesAndDirectories"
overlay=false & overlayRootDir=false -> compliance="full"
overlay=false & overlayRootDir=true -> compliance="filesAndDirectories"
overlay=true & overlayRootDir=false -> compliance="rootDirectoryAndFiles"
overlay="true & overlayRootDir=true -> compliance="files"

* "full" means that deploy dir is made completely the same as the contents of the bundle, no other files or directories are allowed (this should be equivalent to manageRootDir=true).
* "filesAndDirectories" means that all files and directories present in the bundle will appear the same in the deploy dir. I.e. files will be replaced by those in bundle and directories will be wiped prior to being copied from the bundle (this should be equivalent to what manageRootDir=false does).
* "rootDirectoryAndFiles" means that the root directory of the deployment will only contain files and directories from the bundle. The content of the directories is not required to be compliant with the bundle - i.e. the directories and files "under" some directory, that already existed in the deployment, are kept. I still can't think of a usecase for this behavior and I also find it quite difficult to describe (maybe it's because of that fact).
* "files" means that all files from a bundle is copied into the deployment (preserving directory structure) (i.e. such files are compliant with the bundle). All other contents of the deployment directory is kept intact (i.e. this is the RPM-like behavior).

Shout if you're opposed to these names. I have all the tests passing (which took me days to achieve) and want to finish this up.

----- Original Message ----- 

> From: "Jay Shaughnessy" <jshaughn at redhat.com>
> To: rhq-devel at lists.fedorahosted.org
> Sent: Friday, July 26, 2013 5:03:22 PM
> Subject: Re: Rename manageRootDir property in bundles

> Lukas, from IRC, not sure if you saw this (also, I tweaked the values
> slightly from IRC):

> 9:27:55 AM) jshaughn: lkrejci: mazz, OK, I'm OK with 'wipe'. Although, one
> other option I can think of would be a word that maybe more reflects what
> we're doing with a bundle deployment. It basically has the same settings as
> wipe, although I changed the values a little:
> (9:28:04 AM) jshaughn: One new attribute called "compliance" with the below
> semantics:
> (9:28:04 AM) jshaughn: manageRootDir=true : compliance="full"
> (9:28:04 AM) jshaughn: manageRootDir=false : compliance="onlySubdirectories"
> (9:28:04 AM) jshaughn: overlay=false & overlayRootDir=false :
> compliance="full"
> (9:28:04 AM) jshaughn: overlay=false & overlayRootDir=true :
> compliance="onlySubdirectories"
> (9:28:04 AM) jshaughn: overlay=true & overlayRootDir=false :
> compliance="onlyRootDir"
> (9:28:04 AM) jshaughn: overlay=true & overlayRootDir=true : compliance="none"

> When in compliance the file structure will comply to the bundle structure.
> When not in compliance the bundle files will overlay existing files and
> directories of the same name. Some edge cases we need to cover and some
> possible approaches:
> - A non-directory bundle entry will replace a file-system directory of the
> same name
> - A directory bundle entry will replace a file-system file of the same name
> - Complying directories will remove (and backup, I assume) all files prior to
> the bundle files being layed down, including existing subdirectories.

> These edge cases are relevant to whatever attribute choice you make, I think.

> On 7/25/2013 10:09 PM, Larry O'Leary wrote:

> > Ah. That makes sense. Thanks for the clarification.
> 

> > -----Original Message-----
> 
> > From: Jay Shaughnessy [ jshaughn at redhat.com ]
> 
> > Received: Thursday, 25 Jul 2013, 8:15pm
> 
> > To: rhq-devel at lists.fedorahosted.org Subject: Re: Rename manageRootDir
> > property in bundles
> 

> > Larry, those were two different solution options.  The first was adding
> 
> > 'overlay' and overlayRoot', the second was consolidating those two
> 
> > options with just a single 'wipe' attribute.
> 

> > On 7/25/2013 5:36 PM, Larry O'Leary wrote:
> 

> > > It isn't clear to me why three attributes in introduced in total when
> > 
> 
> > > all work is done. Couldn't you just get away with wipe on its own or
> > 
> 
> > > overlay and overlayRootDir without the need for wipe?
> > 
> 

> > > On Thu, 2013-07-25 at 16:28 +0200, Lukas Krejci wrote:
> > 
> 

> > > > Based on the feedback gathered in this email thread and in the comments
> > > > of
> > > > the
> > > 
> > 
> 
> > > > BZs https://bugzilla.redhat.com/show_bug.cgi?id=801464 and
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=801926 , I think the path
> > > > forward
> > > 
> > 
> 
> > > > is quite clear.
> > > 
> > 
> 

> > > > 1) We need to deprecate manageRootDir, but still understand it for
> > > > backwards
> > > 
> > 
> 
> > > > compatibility.
> > > 
> > 
> 
> > > > 2) New bundles will be required to have a new attribute (with NO
> > > > default,
> > > > so
> > > 
> > 
> 
> > > > that we force people to be explicit about the choice) that will express
> > > > the
> > > 
> > 
> 
> > > > "cleaning" behavior of the bundle deployment. Or they can specify the
> > > 
> > 
> 
> > > > deprecated manageRootDir.
> > > 
> > 
> 
> > > > 3) We should not introduce any new type of bundle destination handling
> > > > before
> > > 
> > 
> 
> > > > the new provisioning (to reduce the complexity of impl. and amount of
> > > > bugs
> > > 
> > 
> 
> > > > we'd introduce in RHQ 4.9.0).
> > > 
> > 
> 
> > > > 4) The new attribute(s) must lay the groundwork for future addition of
> > > > more
> > > 
> > 
> 
> > > > types of destination dir management (namely the RPM-like behavior)
> > > 
> > 
> 
> > > > 5) The behavior of manageRootDir must be expressable using the new
> > > > attibute(s)
> > > 
> > 
> 
> > > > and the implementation should initially support ONLY the values that
> > > 
> > 
> 
> > > > correspond to manageRootDir.
> > > 
> > 
> 

> > > > We've had a couple of ideas for the new attribute(s) (that express the
> > > 
> > 
> 
> > > > complete set of possible destination cleaning behaviors):
> > > 
> > 
> 

> > > > 1) Based on https://bugzilla.redhat.com/show_bug.cgi?id=801926#c15 Two
> > > > new
> > > > attributes called "overlay" and "overlayRootDir" with the below
> > > 
> > 
> 
> > > > specified semantics:
> > > 
> > 
> 
> > > > If only manageRootDir is in the recipe:
> > > 
> > 
> 

> > > > manageRootDir | Action
> > > 
> > 
> 
> > > > ------------------------------------------------------------------------------
> > > 
> > 
> 
> > > > false       | same as overlay=false + overlayRootDir=true
> > > 
> > 
> 
> > > > true        | same as overlay=false + overlayRootDir=false
> > > 
> > 
> 

> > > > Otherwise:
> > > 
> > 
> 

> > > > overlay | overlayRootDir |  Action
> > > 
> > 
> 
> > > > ------------------------------------------------------------------------------
> > > 
> > 
> 
> > > > unspec |     unspec     | ERROR, we want to be explicit, CHANGED FROM
> > > > THE
> > > > BZ
> > > 
> > 
> 
> > > > unspec |     false      | Strict bundle structure
> > > 
> > 
> 
> > > > unspec |     true       | Like legacy manageRootDir=false
> > > 
> > 
> 
> > > > false  |     unspec     | Strict bundle structure
> > > 
> > 
> 
> > > > false  |     false      | Strict bundle structure
> > > 
> > 
> 
> > > > false  |     true       | Like legacy manageRootDir=false
> > > 
> > 
> 
> > > > true   |     unspec     | Overlay existing files, no deletions (new!)
> > > 
> > 
> 
> > > > true   |     false      | Strict bundle root dir, overlay subdir files
> > > 
> > 
> 
> > > > (new!)
> > > 
> > 
> 
> > > > true   |     true       | Overlay existing files, no deletions (new!)
> > > 
> > 
> 

> > > > Initially only the following combinations of overlay and overlayRootDir
> > > > would
> > > 
> > 
> 
> > > > be supported:
> > > 
> > 
> 

> > > > overlay | overlayRootDir
> > > 
> > 
> 
> > > > ------------------------
> > > 
> > 
> 
> > > > unspec  | false
> > > 
> > 
> 
> > > > unspec  | true
> > > 
> > 
> 
> > > > false   | false
> > > 
> > 
> 
> > > > false   | true
> > > 
> > 
> 

> > > > 2) Based on https://bugzilla.redhat.com/show_bug.cgi?id=801926#c16 One
> > > > new
> > > > attribute called "wipe" with the below semantics:
> > > 
> > 
> 
> > > > manageRootDir=true                   : wipe="everything"
> > > 
> > 
> 
> > > > manageRootDir=false                  : wipe="subdirectories"
> > > 
> > 
> 
> > > > overlay=false & overlayRootDir=false : wipe="everything"
> > > 
> > 
> 
> > > > overlay=false & overlayRootDir=true  : wipe="subdirectories"
> > > 
> > 
> 
> > > > overlay=true  & overlayRootDir=false : wipe="onlyRoot"
> > > 
> > 
> 
> > > > overlay=true  & overlayRootDir=true  : wipe="nothing"
> > > 
> > 
> 

> > > > Initially, we'd only support the "everything" and "subdirectories"
> > > > values
> > > > for
> > > 
> > 
> 
> > > > wipe (i.e. the ones corresponding to manageRootDir) and would require
> > > > that
> > > 
> > 
> 
> > > > exactly one of manageRootDir or wipe attributes be present on the
> > > > deployment
> > > 
> > 
> 
> > > > unit.
> > > 
> > 
> 

> > > > 3) A simple renaming of 2) to be less "cheeky" and maybe even slightly
> > > > more
> > > 
> > 
> 
> > > > clear:
> > > 
> > 
> 
> > > > wipe = destinationCleaning with values: "everything",
> > > > "commonSubirectories",
> > > 
> > 
> 
> > > > "onlyRootDirectory", "nothing"
> > > 
> > 
> 

> > > > On Tuesday, July 23, 2013 09:29:21 Lukas Krejci wrote:
> > > 
> > 
> 

> > > > > Hi all,
> > > > 
> > > 
> > 
> 

> > > > > In BZ 801464 (and 801926)
> > > > 
> > > 
> > 
> 
> > > > > ( https://bugzilla.redhat.com/show_bug.cgi?id=801464 ), we're
> > > > > discussing
> > > > > the
> > > > 
> > > 
> > 
> 
> > > > > problems of manageRootDir property on the deployment units in
> > > > > bundles.
> > > > 
> > > 
> > 
> 

> > > > > We have decided to take 2 actions on it:
> > > > 
> > > 
> > 
> 
> > > > > 1) A short term remedy to prevent people from shooting themselves in
> > > > > the
> > > > 
> > > 
> > 
> 
> > > > > foot 2) A long term overhaul of how bundles work to make them more
> > > > > similar
> > > > 
> > > 
> > 
> 
> > > > > to RPM/APT so that people are less surprised by the behavior.
> > > > 
> > > 
> > 
> 

> > > > > I won't discuss 2) here because there will be plenty of opportunities
> > > > > to
> > > > > do
> > > > 
> > > 
> > 
> 
> > > > > that later when we start concentrating on it, but I'd like to discuss
> > > > > 1)
> > > > 
> > > 
> > 
> 
> > > > > with you.
> > > > 
> > > 
> > 
> 

> > > > > As the subject suggests, one of the things we intend to do is to
> > > > > rename
> > > > > the
> > > > 
> > > 
> > 
> 
> > > > > manageRootDir property to something that more clearly expresses the
> > > > > true
> > > > 
> > > 
> > 
> 
> > > > > meaning of the setting. The other thing that we want to do is to make
> > > > > the
> > > > 
> > > 
> > 
> 
> > > > > parameter mandatory so that people are forced to think about the
> > > > > value
> > > > > to
> > > > 
> > > 
> > 
> 
> > > > > put in there when creating a new bundle (this will only affect the
> > > > > upload
> > > > 
> > > 
> > 
> 
> > > > > of new bundles. The system will be able to revert to bundle versions
> > > > > that
> > > > 
> > > 
> > 
> 
> > > > > are already uploaded).
> > > > 
> > > 
> > 
> 

> > > > > So the one thing I'm gathering input for is the new name for
> > > > > manageRootDir.
> > > > 
> > > 
> > 
> 

> > > > > But what manageRootDir (which defaults to true) really means? If it
> > > > > is
> > > > > true
> > > > 
> > > 
> > 
> 
> > > > > (the default), the bundle deployer will delete any and all files
> > > > 
> > > 
> > 
> 
> > > > > (recursively) in the destination directory before deploying the
> > > > > bundle
> > > > 
> > > 
> > 
> 
> > > > > files into it. This means that it is guaranteed that the bundle
> > > > > destination
> > > > 
> > > 
> > 
> 
> > > > > only contains the bundle files. When manageRootDir is false, it means
> > > > > that
> > > > 
> > > 
> > 
> 
> > > > > that the files and directories at directly under the destination
> > > > > directory
> > > > 
> > > 
> > 
> 
> > > > > are left intact - this means that the bundle deployer will only
> > > > > overwrite
> > > > 
> > > 
> > 
> 
> > > > > the files that are also part of the bundle and, also, will replace
> > > > > any
> > > > 
> > > 
> > 
> 
> > > > > directories that are present in the bundle with the contents from the
> > > > 
> > > 
> > 
> 
> > > > > bundle - this means that the sub-directories are always wiped to
> > > > > conform
> > > > > to
> > > > 
> > > 
> > 
> 
> > > > > the contents of the bundle - there is currently no way of overriding
> > > > > that
> > > > 
> > > 
> > 
> 
> > > > > (and we don't search for a mechanism to provide that in this email).
> > > > 
> > > 
> > 
> 

> > > > > There already have been some suggestions for the new name:
> > > > 
> > > 
> > 
> 

> > > > > manageRootDir=true
> > > > 
> > > 
> > 
> 

> > > > > could also be expressed like:
> > > > 
> > > 
> > 
> 

> > > > > manageDestDirFully=true
> > > > 
> > > 
> > 
> 
> > > > > doNotTouchTopLevelDirectoriesFoundInDestDirButNotFoundInBundle=false
> > > > 
> > > 
> > 
> 
> > > > > ignoreTopLevelDirectoriesInDestDirButNotFoundInBundle=false
> > > > 
> > > 
> > 
> 
> > > > > cleanTopLevelDirectoriesFoundInDestDirAndNotFoundInBundle=true
> > > > 
> > > 
> > 
> 
> > > > > bundleToManageAllTopLevelDirectoriesInDestDir=true
> > > > 
> > > 
> > 
> 
> > > > > manageAllTopLevelDirectoriesInDestDir=true
> > > > 
> > > 
> > 
> 

> > > > > I'll add a couple of suggestions, too:
> > > > 
> > > 
> > 
> 

> > > > > cleanDestinationFully=true
> > > > 
> > > 
> > 
> 
> > > > > wipeDestinationDir=true
> > > > 
> > > 
> > 
> 
> > > > > alsoWipeUnmanagedFilesAndDirectoriesInDestination=true
> > > > 
> > > 
> > 
> 

> > > > > Which of the above do you think expresses the best what manageRootDir
> > > > > does?
> > > > 
> > > 
> > 
> 
> > > > > Do you have some other suggestions for the name?
> > > > 
> > > 
> > 
> 

> > > > > Cheers,
> > > > 
> > > 
> > 
> 

> > > > > Lukas
> > > > 
> > > 
> > 
> 

> > > > > _______________________________________________
> > > > 
> > > 
> > 
> 
> > > > > rhq-devel mailing list rhq-devel at lists.fedorahosted.org
> > > > > https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> > > > 
> > > 
> > 
> 

> > > > _______________________________________________
> > > 
> > 
> 
> > > > rhq-devel mailing list rhq-devel at lists.fedorahosted.org
> > > > https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> > > 
> > 
> 

> > _______________________________________________
> 
> > rhq-devel mailing list rhq-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> 

> > _______________________________________________
> 
> > rhq-devel mailing list rhq-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> 

> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel


More information about the rhq-devel mailing list