Rename manageRootDir property in bundles

Jay Shaughnessy jshaughn at redhat.com
Fri Jul 26 15:03:22 UTC 2013


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/rhq-devel/attachments/20130726/20fecb79/attachment-0001.html>


More information about the rhq-devel mailing list