[kea-dev] Kea python hook?

[David Hankins]

It sounds like we should move forward with Francis' implementation as a
baseline?  I'll take a stab at using it.  What would it take to convince
ISC to merge it into master?

It would be simplest in our deployment environment to configure Kea to find
and use a python module we provide than to build a custom hook.

On Mon, Jan 22, 2018 at 1:09 AM, Francis Dupont <fdupont at isc.org> wrote:

> Dave Cole writes:
> > I did not know that code existed!
>
> => it had 2 purposes:
>  - show it is possible to write a hook in a script language vs requiring
> C++
>   with examples in Python, Lua, OCaml and v8
>
>  - detail technical points so someone who wants to do the same thing
>   can win a lot of time
>
> > On big difference in approach is that the code you have created
> > will not work with current Kea if the Python code imports a
> > module with native code - unless you statically link your code
> > with Kea.  Kea loads hooks with RTLD_LOCAL which prevents symbols
> > in the hook being visible in subsequent dynamic linking.  The
> > hook I created here connects to a database and publishes to Kafka
> > - we need to load native modules.
>
> => currently hooks are dynamic shared objects which don't load
> other DSOs and have no dependency between hooks, so RTLD_LOCAL
> is enough. As it works for almost all cases and is simpler / faster
> I believe it will stay the default but you can open a ticket asking
> for a configure option to change it for RTLD_GLOBAL. If you provide
> a pair of DSOs, one behaving as a hook and loading the second, for
> unit tests, or pull a request on github, it will help because as
> you know we have limited man power.
>
> > Another thing I am confused about in your code is that you do not
> > appear to do any exception handling.  If Python code calls Kea
> > and an exception is raised, then the Python interpreter will get
> > corrupted.
>
> => I mention exceptions in the doc as one of the things which should
> be implemented. Of course it is simpler if the C++ code called
> from the external language does not raise exceptions (*) so
> you don't have to add a handler to stop stack unwinding.
>
> Thanks
>
> Francis Dupont <fdupont at isc.org>
>
> PS (*): C++ specs changed about possible exceptions declarations but
> if you remove fatal errors like bad_alloc which can't be recovered
> usually C++ code does not raise exceptions and this is a static
> property (so the compiler can check it).
> Kea code is supposed to have a doxygen documentation for all exported
> methods or functions with parameters, result (if exists) and
> possible exceptions. If you find a bug in that please signal it as
> it will really be considered as a bug.
> PPS: about C++11 noexcept: as we moved to C++11 we can use noexcept
> in the code. I don't think there is already a policy, even for new code,
> and I am sure that as even the question of adding or not noexcept is
> clearly time consuming we do not plan to consider noexcept in short term.
>



-- 
Infrastructure Management Services
Twitter, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-dev/attachments/20180122/0bef1e2e/attachment.html>