[SSSD] Embedding Lua into SSSD

Lukas Slebodnik lslebodn at redhat.com
Tue Aug 25 15:59:07 UTC 2015


On (25/08/15 15:57), Nikolai Kondrashov wrote:
>Hi Simo,
>
>On 08/21/2015 09:37 PM, Simo Sorce wrote:
>>On Fri, 2015-08-21 at 20:01 +0300, Nikolai Kondrashov wrote:
>>>I might be in a strange and careless mood today, but here is something I
>>>wanted to suggest since the time I saw the amount of logic that goes into SSSD
>>>and is implemented in C.
>>>
>>>What if we implement some of the complicated logic inside SSSD in Lua [1]?
>>
>>can you provide an example of a piece of SSSD youd replace with Lua ?
>>I am not asking for an implementation but a high level view of what a
>>function looks like to day and what it would look like if we were going
>>to use Lua (ideally with a list of primitives we'd still need to
>>provide, to understand how much code Lua replaces for real.
>
>I don't have enough knowledge of SSSD to provide really meaningful examples.
>I have to know developer pain points to really suggest an interesting
>solution, and I have to really know the code to show good examples.
>
SSSD is written in asynchronous way and tightly coupled with tevent[1] and talloc.
This is not use case for using scripting language. The ideal use case for scripting
languages is to write higly optimized library in C + bindings. The scipting language
would be used for replacing boilerplate code in C.


However there are still few ways.
You can write simple example of using lua scripts with tevent[1].
Then we can evaluate pros and cons of using Lua.

The another way would be to replace tevent[1] with lua implementation of event loop.
In another words, rewrite sssd from scratch.

>Still, judging from the code distribution and overall architecture, I would
>say the first candidates will be providers. They are very complicated and have
>a relatively well defined interface to SSSD core. Most of them talk over
>network and any slowdown from Lua will likely be swamped by network latency.
>
Providers are very complicated due to compicated servers (LDAP, IPA, AD)
We will not be able to replace high level iplementation with scripting language
in short time (Lua -> C) . In short time, there still will need to be two way
comunication between C and Lua (Lua <-> C). Which would not be simplify code as
the first way.

>I would make a (partial?) adaptor from the current interface to Lua, allowing
>implementing a (limited?) provider in Lua, plus low-level communication
>libraries underneath. This will allow testing the feasibility without
>disrupting the existing providers.
>
Will it be asynchronous?
In theory, you could use threads from scripting language but
we there could be synchronisation related issues. So the ideal would be to use
Erlang and message passing instead of shared variables.

>If the idea proves useful, existing providers can be re-implemented in Lua,
>perhaps section-by-section, and starting from the smallest. If all the
>providers are converted, the adaptor can be removed and the core will talk
>directly to high-level Lua provider code. One side-effect of such work will
>be refactoring and simplifying of the provider interface, which will have a
>positive effect on the overall architecture.
>
There is a missing step between a POC and re-implementing existing providers.
We need to write functional test to assure we will not create a regressions.
As I already wrote servers are complicated (LDAP, IPA, AD); So code coverage
will need to be very high. 

>I expect main savings to come from
> exception support,
scripting language might help

> automatic memory management,
talloc helps a lot even in C.

> simpler data massaging,
What do you mean here?

> and brevity of a scripting language (e.g. implicit, dynamic typing).
>
This can be pros and cons in the same time.

Summary:
This is an interesting idea; but currently I cannot see many benefits
for using any scripting language in SSSD. Moreover sssd is a security
service. Such step could cause problems with security certifications.

LS

[1] https://tevent.samba.org/



More information about the sssd-devel mailing list