[SSSD] INI validation design thoughts

Dmitri Pal dpal at redhat.com
Wed Apr 7 21:48:24 UTC 2010


Jeff Schroeder wrote:
> On Wed, Apr 7, 2010 at 1:58 PM, Dmitri Pal <dpal at redhat.com> wrote:
>   
>>>> No, we absolutely need to have the ability for third-party backends to
>>>> have their own completely self-sufficient configuration.
>>>>
>>>>
>>>>         
>>> Then we will just not have it at all for now.
>>> Sorry. I can't commit to doing something of this complexity
>>> in a reasonable time.
>>>
>>>
>>>       
>> After some more thinking and a bit of cooling.
>> We do not add the ability to handle the 3rd party back end day one.
>> Why? One of the reasons - it is a too big task to chew.
>> We have a plan how to get there. Slowly!
>> We tries several time though I asked for it to be thought through day one.
>> It was not and thus we had more things to change.
>>
>> Here we can think about it as a design goal and even spec it a bit
>> but delay the actual implementation.
>> Why we have to deliver the config validation complexity day one?
>> Why can't follow the same steps as with actual back ends?
>>
>> The whole packaging guidelines seems like a dark magic in this case.
>> Anyone can edit a config file: an admin manually, a puppet manifest
>> automatically, etc.
>>
>> I do not see how the schema file is different in this case and
>> why it can't be edited in the same way by different sources.
>> What you are saying really seems as an artificial requirement for v1.
>> Please example how shcema file is different from any config file that
>> anyone can edit?
>>     
>
> And what is wrong with a a .d directory like every other piece of 'nix
> software in existence? The sssd.api.d directory seems like the proper
> way whereas 1 big schema file is a step backwards. For 1 it would be
> breaking both Debian Policy and Fedora Packaging Guidelines.
> Additionally, it would make it for difficult for 3rd party backends to
> integrate.
>
>   
I am not arguing against it. I am arguing against it as a v1 requirement.
pam.conf, nsswitch.conf are the files that are touched by multiple
different components
and by admins. So how it is different?
Plus the back ends are not possible now and it will be for some time
and there will be some time after it till someone would actually start
doing
a back end.
So why this complexity should be supported day one?
I think it is right feature but does not need to be delivered now.
It can easily be delivered 9 months from now.
This is my only point.
You know "start small" sort of thing.
Do not try to boil an ocean :-)
The question of prioritization, that is all.

-- 
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/




More information about the sssd-devel mailing list