On Tue, 2014-04-08 at 09:54 -0400, Dmitri Pal wrote:
On 04/07/2014 10:13 PM, Simo Sorce wrote:
> On Mon, 2014-04-07 at 19:20 -0400, Dmitri Pal wrote:
>> Hello,
>>
>> This is the continuation of the discussion of the following design page:
>>
https://fedorahosted.org/sssd/wiki/DesignDocs/ding-libs/INIConfigMerge
>>
>> I see three controversial items in this design based on the previous
>> discussion:
>>
>> a) Merging values
>> This horse has been beaten in the other thread.
>> The answer is simple. If we can make SSSD to make a change to not use
>> lists or domains or providers as Simo suggest we can remove this
>> consideration from the merge design. If we can't then we need to make it
>> optionally available in the merge logic. To make a final decision here
>> we need Jakub's input on how hard it is to implement Simo's idea.
>>
>> c) Snippets in a directory vs. snippets in a subdirectory per application.
>> The design is built around the fact that it is better to put snippets
>> into different subdirectories per source/application that updated them
>> so that we can make sure that different sources of config info do not
>> step on each other. We also can jail the config files with SELinux and
>> allow different access to different subdirectories.
> Keep in mind that selinux labels can be applied to single files, they do
> not need to be in subdirectories.
>
>> This is a deviation
>> from the current approaches where all snippets are supposed to go into a
>> single directory.
>> IMO this is quite limiting and I see an opportunity to change it for
>> better. However if people agree with Simo that this is too over
>> engineered and complicated I can understand. It is in fact more complex.
>> So chime in. If you think single directory is good enough so be it.
>>
>> d) .merge files
>> I do not like them either.
>> If we:
>> a) Can avoid value merges
>> b) Will require each snippet to have a section header ( the problem is
>> really the fact that INI automatically generates one called "default"
if
>> there is none so it is hard to say whether the parse filled the blank or
>> the snippet section really is called "[default]"). I think I can work
>> around it but it would require a change that I wanted to avoid with the
>> design.
>> c) Do not allow overwrites
>> we can drop the .merge files.
>>
>> They are needed to support any of the three use cases above.
>> I am mostly concerned about the last one because allowing overwrites on
>> per section basis was something was requested in one of the RFEs.
>> However here is how we can work around this because IMO it is a corner case.
>>
>> - The merge code will read snippets from a single directory.
>> - It will inspect the name. If the name is <xxx>.over.conf then it will
>> treat this file as the snippet that the author of the snippet wants to
>> use to overwrite sections in the original config file. If the name of
>> the file is <yyyy>.conf it will user it to do additive merge. If file
>> has any other extension it will be ignored.
> This is not a bad idea, I need to think about it.
Sure. I am open to alternatives.
I do not like naming conventions that much but if we have to do it here
so be it.
The other option is to add a directive within the file.
Like the first key must be merge = yes or override = yes without
section ?
> Another option I can see is that he application tells you (via
library
> call) what sections are overridable, but that is quite limiting and may
> not satisfy the original requester.
>
>> Common rules about snippets:
>> - Snippets must have a section defined - absence will cause an error and
>> snippet will be ignored
> +1
>
>> - Snippets can't have the same section defined in more than one .conf
>> file. If same name is detected it will be treated as a collision and all
>> snippets will be ignored
> I would rather say, only the first will be considered and all
> conflicting one after that ignored.
Which one is the first?
It becomes implementation specific and depends on either dates or
lexical order of the file names.
A lot of programs depend on ordering, so we need to explicitly know how
INI will order snippets.
It is conventional to do it in lexicographic order.
SSSD also scans domains in order in the list (when more than one domain
is configured to not use fully qualified names, that is important), so
we need to be able to tell admin what the order will be.
I think this is not predictable and would be hard for admins to
troubleshoot. I also think that just discarding the two colliding
snippets would be a mistake since there can be a third one that then
might go through because other two have been discarded.
IMO any collision should be treated as a violation of the rules and
abort the whole snippet stack.
We need an order (just decide on a rule that stay predictable over
multiple runs doesn't really matter which) and then discard anything but
the first instance where the section appears :)
Simo.
--
Simo Sorce * Red Hat, Inc * New York