On 08/25/2015 06:59 PM, Lukas Slebodnik wrote:
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.
Now we're talking specifics, awesome! Alright, perhaps I'll do that. Care to
give a use case I should try to implement?
The another way would be to replace tevent[1] with lua implementation
of event loop.
In another words, rewrite sssd from scratch.
Whoa, no way :)
> 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.
Sure. It's complicated. That's why a higher level language might be
beneficial. If we can cut off some parts of a provider cleanly (which is a
good idea for refactoring anyway), we can reimplement them in Lua with
relatively low overhead. Thus, going by pieces we can reduce the disruption.
> 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.
Well, we can try it? I assume a lot of people did such things already.
There is a bunch of multithreading libraries for Lua, and then there are
always the built-in coroutines.
So the ideal would be to use Erlang and message passing instead of
shared
variables.
Sadly, I don't know Erlang yet, can't say anything about that. I bet it's
awesome. However, I expect it is harder to interface with as well.
> 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.
Yeah, this bothers me too, it is dangerous, I agree. Perhaps if we do it
slowly, piece-by-piece, it will be safer and easier to manage, i.e. write
tests for, or test manually?
> I expect main savings to come from
> exception support,
scripting language might help
> automatic memory management,
talloc helps a lot even in C.
I agree. Still, it's explicit and needs taking care of, constantly.
> simpler data massaging,
What do you mean here?
The messy stuff. Parsing and gluing strings together, maintaining complicated
data structures, converting from one representation to another, etc.
> and brevity of a scripting language (e.g. implicit, dynamic
typing).
>
This can be pros and cons in the same time.
Implicit, dynamic typing - yes. Brevity - not likely. You can always make it
more verbose, after all, but it is hard the other way around.
Summary:
This is an interesting idea; but currently I cannot see many benefits
for using any scripting language in SSSD.
I'm careful about this as well. Yet, it is exciting :)
Moreover sssd is a security service. Such step could cause problems
with
security certifications.
Well, I know little of certification, and I'm worried about security too,
however, would C be safer, really?
Do you anticipate any specific security problems?
Thanks!
Nick