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

Dmitri Pal dpal at redhat.com
Mon Apr 14 21:30:58 UTC 2014


On 04/14/2014 06:18 AM, Jakub Hrozek wrote:
> On Tue, Apr 08, 2014 at 10:32:25AM -0400, Simo Sorce wrote:
>> 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'm sorry to jump so late into the thread.
>
> About omiting the list of domains and services -- in general I agree
> with the idea. It was also requested by Stef earlier and would be nice
> to have for the desktop integration down the road.
>
> If the list, is present, on the other hand, we should treat it as
> authoritative and only take domains/services that are in the list into
> account and conversely error out on domains/services that are referenced
> from the list but not defined.
I think this is a problem because it would require migration of the 
config files.
I would rather ignore/deprecate the list value.
Alternatively the list will indicate the required elements and when we 
add config file validation we will check that all required sections are 
present and fallback to the dummy read-only files if we find errors like 
this.


>
> With ordering, I think lexicographic is the only option. Init scripts
> have used the same schema (also proposed by Lukas in the other mail) for
> ages and it's something admins are used to.
OK


> But I also wanted to check about ordering in a single file. If I define
> two section in the INI file, would the parser process them in the same
> order they are defined in the file? I think this is also something the
> admins expect.

Sections are processed in order they are listed in the file.
I will publish the new design page later today.

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


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.




More information about the sssd-devel mailing list