[SSSD] INI validation design thoughts

Jeff Schroeder jeffschroed at gmail.com
Wed Apr 7 21:32:24 UTC 2010


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.

-- 
Jeff Schroeder

Don't drink and derive, alcohol and analysis don't mix.
http://www.digitalprognosis.com



More information about the sssd-devel mailing list