[SSSD] [INI] Ding-libs, controversial points in the design to allow merging configuration snippets

Dmitri Pal dpal at redhat.com
Tue Apr 8 13:54:40 UTC 2014


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.

>
> 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.
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.

>
>> Additional rules about <xxx>.over.conf:
>> - Snippets of this kind will be applied only on top of the core config
>> file and only if the application is running in the mode that allows such
>> overwrite.
> Control from app is important
> +1
>
>> - The overwrite will be done on the section by section basis, i.e. no
>> merging of the values between the two sections (though merge logic
>> supports this too)
>> - If there is more than one section in the file then each section will
>> be processed according to these rules
>>
>> If we go with something like this we can avoid .merge files and rely on
>> the naming convention. Is this acceptable? I though not, this is why I
>> invented .merge files but if we think this way is better I am fine with it.
> It looks fine by me.
>
>> Next week I am traveling, I will have some time to do prototyping while
>> I am flying so I want to get to consensus before the end of the week.
> I'd like other comments from sssd developers or bystanders that may have
> use cases or preferences too.
>
> Simo.
>

I think we are in agreement on the rest.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.




More information about the sssd-devel mailing list