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

Lukas Slebodnik lslebodn at redhat.com
Sat Apr 12 16:53:02 UTC 2014


On (08/04/14 11:23), Dmitri Pal wrote:
>On 04/08/2014 10:32 AM, 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 ?
>
>Or better:
>
>mode = overwrite or mode = merge
>
>with
>
>mode = merge
>
>being default if not there.
>
>So it 80% of the cases there will be no extra keys but if you want
>overwrite then you specify mode = overwrite
>
>>
>>>>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.
+1

>It can be done this way. The question is this the right way?
>I am just not sure.
>I envision a use case:
>You have some application dropping a snippet with name X while there
>is another application dropping a snippet with name Y. They are not
>aware of each other so they can't pick the names to define the right
>order in advance. You do not want admin involvement too because this
>would introduce manual step. The result is a bit unpredictable.
>
>Not sure how it can avoided though.
No problem.
sssd.d/01.company_domain.conf
sssd.d/41.home_domain.conf

Each application can have recommendations about numbers.

Recommendations from another project (HTCondor)
. 00 – reserved for a default config, e.g. 00personal_condor.config
. 10-40 – user/admin configuration files
. 50-80 – packaged configuration files
. 99 – reserved for features requiring control of configuration

LS



More information about the sssd-devel mailing list