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