Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. Re: Kea python hook? (David Hankins)
2. Re: Kea python hook? (David Hankins)
3. Re: Kea python hook? (Dave Cole)
----------------------------------------------------------------------
Message: 1
Date: Mon, 22 Jan 2018 09:56:30 -0800
From: David Hankins <[email protected]>
To: Christian Kratzer <[email protected]>
Cc: [email protected], [email protected]
Subject: Re: [kea-dev] Kea python hook?
Message-ID:
<cadl7grma9ja_+wswz2fq3lhqgrnkhs-wgvansasfoeg1sej...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Sat, Jan 20, 2018 at 2:13 AM, Christian Kratzer <[email protected]> wrote:
> Hi,
>
> On Fri, 19 Jan 2018, David Hankins wrote:
>
>> I'm looking at implementing this quarter a competing implementation of;
>>
>> https://lists.isc.org/pipermail/kea-dev/2017-December/000840.html
>>
>> ?Basically I'm after the same thing;? I want ISC Kea to perform DHCPv4 and
>> DHCPv6 protocol implementations, and I just want to provide an interface
>> to
>> internal backend systems curating configuration intent in Python runtime.
>>
>> ?I was about to send an email to kea-dev announcing my intentions, but I
>> see there's already been some work in this area.
>>
>> Where's it at, what's the current status, and how can we best move forward
>> together??
>>
>
> instead of putting effort into implementing yet another binding for a
> language
> why not implement the hooks as configurable rest calls and then have
> something
> like python/flask to connect to or whatever else you prefer.
>
>
?This is an excellent question that deserves some discussion; I think such
a hook would have merit in some deployment environments. I could see a
REST interface having traction in high-latency-tolerant and low-traffic
deployments, but I would prefer myself to use a gRPC or Thrift interface
with integrated service discovery (something like BNS or ZooKeeper).
?There is always a "strange attractor" that software engineers analyze when
asking and answering the question, "in our micro-service architecture,
should we draw the box around these functions, or these other functions?"
Integrating a function inside one instance of a multi-service architecture
versus breaking it out into a separate micro service.
The tradeoffs are increased dependencies and potentially latency versus
service simplicity.
In this case, I think there are use cases for a native hook for which the
added dependency and latency aren't worthwhile tradeoffs. For example,
where all elements of configuration for a given host can be arrived at
algorithmically (mathematically) from packet contents alone. I think there
are also cases where host configuration is itself a seriously complicated
question, involving additional backend queries, and a micro-service
approach is appropriate.?
> I was planning on on doing that to the previously announced hook library.
> Priorities
> are on other projects atm but that would be my way of proceding once I
> migrate
> my customer from classic isc dhcp to kea.
>
> Greetings
> Christian
>
> --
> Christian Kratzer CK Software GmbH
> Email: [email protected] Wildberger Weg 24/2
> Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden
> Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart
> Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer
> Web: http://www.cksoft.de/
--
Infrastructure Management Services
Twitter, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/kea-dev/attachments/20180122/5a3c8c9e/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 22 Jan 2018 10:26:14 -0800
From: David Hankins <[email protected]>
To: Francis Dupont <[email protected]>
Cc: Dave Cole <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [kea-dev] Kea python hook?
Message-ID:
<CADL7GRP7htweX=JjeFoeYGTs=azj+b7ipghzcvh75oo82y3...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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 <[email protected]> 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 <[email protected]>
>
> 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-0001.html>
------------------------------
Message: 3
Date: Mon, 22 Jan 2018 22:32:28 +0000
From: Dave Cole <[email protected]>
To: Francis Dupont <[email protected]>
Cc: David Hankins <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [kea-dev] Kea python hook?
Message-ID:
<syxpr01mb1727af153ce8bfd25b52a05ff2...@syxpr01mb1727.ausprd01.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"
Sorry about the quoting style - I am forced to use LookOut here...
> 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
My first attempt at embedding an interpreter here was with Lua.
I gave up on that when I realised the poor quality of the 3rd
party modules we had to use to implement our requirements
> ?- 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.
I implement my hook with a Kea loaded DSO. This does as little
as possible due to the RTLD_LOCAL limitation. It just
initialises the Python interpreter then loads the kea extension
module via Python import. Inside the Python module is a Capsule
containing endpoints for bootstrapping the Kea/Python binding.
The advantage to this is I can move all of the Kea code into a
kea module which you can then load from the Python command line.
>From that point you are free to use plain Python code for things
like unit tests. I am working towards a public release of the
code as my boss is actively seeking permission to release it.
I want to get to the point where I can use pcap files for
regression tests of my complex hook. It is getting close. For
example:
- - 8< - - - - - - - - - - - - - - - - - - - - - - - - - - -
from kea import *
trans_id = 0x50ea1f55
p = Pkt4(DHCPDISCOVER, trans_id)
p.setGiaddr('11.0.0.1')
p.setHWAddr('02:42:ac:14:00:05')
p.addOption(Option(DHO_DHCP_PARAMETER_REQUEST_LIST)
.setString(chr(DHO_SUBNET_MASK)
+ chr(DHO_BROADCAST_ADDRESS)
+ chr(DHO_ROUTERS)
+ chr(DHO_DOMAIN_NAME)
+ chr(DHO_DOMAIN_NAME_SERVERS)))
o = Option(DHO_DHCP_AGENT_OPTIONS)
o.addOption(Option(1).setString('Relay Agent Option 1'))
o.addOption(Option(2).setString('Another Option'))
p.addOption(o)
p.pack()
raw = p.getBuffer()
r = Pkt4(raw)
r.unpack()
assert r.getType() == DHCPDISCOVER
assert r.getTransid() == trans_id
assert r.getGiaddr() == '11.0.0.1'
assert r.getHWAddr() == '02:42:ac:14:00:05'
assert r.getOption(DHO_DHCP_PARAMETER_REQUEST_LIST) \
.getString() == (chr(DHO_SUBNET_MASK)
+ chr(DHO_BROADCAST_ADDRESS)
+ chr(DHO_ROUTERS)
+ chr(DHO_DOMAIN_NAME)
+ chr(DHO_DOMAIN_NAME_SERVERS))
o = r.getOption(DHO_DHCP_AGENT_OPTIONS).getOptions()
assert o[1].getString() == 'Relay Agent Option 1'
assert o[2].getString() == 'Another Option'
- - 8< - - - - - - - - - - - - - - - - - - - - - - - - - - -
> > 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.
I found that out the hard way :-).
------------------------------
Subject: Digest Footer
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
------------------------------
End of kea-dev Digest, Vol 46, Issue 3
**************************************
