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.
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.
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.
--
Simo Sorce * Red Hat, Inc * New York