On 04/20/2012 09:44 AM, Simo Sorce wrote:
On Thu, 2012-04-19 at 20:05 -0400, Stephen Gallagher wrote:
> On Thu, 2012-04-19 at 19:48 -0400, Dmitri Pal wrote:
>
>> The question is about the ALLOW and DETECT options. As a result of the
>> merge operation using those options one can end up with more than one
>> section with the same name or more than one key with the same name
>> inside the same section. The result will be a merged config with
>> potential duplicates but in case of ALLOW there will be no errors while
>> in case of DETECT there will be some merge errors (not implemented yet)
>> that can be printed later to provide the information about what is wrong
>> with the config.
>>
>> The ALLOW mode does not make much sense for SSSD but in general case it
>> might be useful. However current interface that deals with querying the
>> configuration and fetching configuration data does not have a way to
>> deal with the values that can have more then one value. Duplicate values
>> would not cause any trouble they are just not accessible via existing
>> interface. The interface that is available is open for changes anyways
>> so there is not problem to extend it to support access to the dup keys
>> (if needed), however it is extra work and it is not clear whether it is
>> actually needed or not.
>>
>> I think we need to finish the DETECT mode. It has a lot of value.
>> It is ALLOW mode that I am on the fence about.
>>
> To the best of my knowledge, there are no INI parsers out there that
> allow for multi-valued keys.
I have such a need right now for gss-proxy :-)
> In the event that two keys have the same
> value, different parsers offer one of three solutions:
> 1) Throw a parse error
> 2) First one listed in the file wins
> 3) Last one listed in the file wins (most common).
4) return list of strings :)
> So I really don't think there's much value to implementing either the
> ALLOW or DETECT options. We don't want ini_config to be writing files
> that other parsers may be unable to read (or in the common case will be
> functionally identical to OVERWRITE, since last one usually wins). It's
> best if our output always guarantees single-valued keys.
Yes this is an important concern, in general you do not want to create
multi-valued attributes because of a merge, during merges usually one
file overrides the other.
>> So the question is what to do in this situation.
>>
>> I see several options:
>> 1) Decide that allowing duplicates is a bad idea and we will not going
>> to support it so wipe out ALLOW option
> I'm in favor of scrapping the ALLOW and DETECT options.
yeah for merging probably it is better.
Simo.
Let me explain. DETECT mode is definitely needed. It is for the dry run
case. Run through the merge and record all errors instead of erring out
of the first merge error as in the ERROR mode.
Here is a use case:
1) I dropped in a new config file that needs to be merged with the
default one
2) Let us say SSSD uses logic to error on any merge conflict (or can be
run in such mode)
3) I restart SSSD it errors out on an config file merge error
4) I run ini-check-merge utility (something that would be useful to
provide from ding-libs package) that would parse the two configs and
would give me a full set of merge errors in one run.
5) I fix them and restart SSSD
6) Everything works
So DETECT is needed for troubleshooting and I do not think it is the
right thing to discard it (at least I do not plan to).
The ALLOW is the problem though and I suspect that there might be cases
when it makes sense to have lists like the one Simo mentioned. I do not
want to implement it now though I see potential need in future.
So this brings me to the option 4 that I proposed.
I do not see a better choice so I will proceed with it.
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IPA project,
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/