[Freeipa-devel] Q: dnsclient portability

[Martin Kosek]

On Fri, 2011-12-02 at 10:20 -0500, John Dennis wrote:
> On 12/02/2011 07:58 AM, Alexander Bokovoy wrote:
> > Hi,
> >
> > I'm working on ticket https://fedorahosted.org/freeipa/ticket/1837
> > which concerns portability of ipapython.dnsclient module.
> >
> > ipapython.dnsclient module uses acutil module to perform 'res_send(3)'
> > call provided by libresolv. acutil implements bindings to two system
> > calls (res_send() and getusershell()) and belongs to authconfig
> > package. The total size of acutil module source code is ~100 lines of
> > C code.
> >
> > Now, authconfig package is not available beyond Fedora/RHEL
> > distributions and, in particular, it is not available in
> > Ubuntu / GNU/Debian Linux. It means ipapython.dnsclient will fail on
> > those platforms and a way of getting around the issue needs to be
> > found.
> >
> > So far, there are two options:
> >
> > 1. Extract acutil module from authconfig and supply it with
> > freeipa-python in a manner similar to default_encoding module. This is
> > 'cheapest' solution in a sense we only interested in bindings to
> > res_send(3). FreeIPA client code then will be self-contained and would
> > not depend on authconfig availability (platform portability code
> > already allows to re-implement authconfig implementation).
> >
> > 2. Port ipapython.dnsclient to use dnspython module if acutil is not
> > available. This module, available from http://www.dnspython.org/, can
> > be found in Fedora, GNU/Debian Linux, Ubuntu and many other
> > distributions. It is python-only resolver providing a super-set of
> > ipapython.dnsclient features.
> >
> > The downside of the first approach is a need to distribute and
> > maintain another CPython extension. Though the code is straight
> > forward and simple enough, it is still a separate maintenance burden.
> >
> > The downside of the second approach is to write a bridge code between
> > ipapython.dnsclient API and dnspython API. They are different enough
> > so that remapping of fields in objects resulting from a query is
> > needed.
> >
> > I've started to implement the bridge code myself but it is quickly
> > getting to the level of effort original ipapython.dnsclient has
> > (due to API differences in attributes names) and that means it is
> > probably not worth it.
> 
> I think the second approach is better, here is my reasoning:
> 
> * If we rebuilt acutil it would make more sense to package it an actual 
> package, not just another IPA CPython module, this would be more 
> flexible and other could use it, but ...
> 
> * acutil seems incomplete and an odd mix of just 2 functions, probably 
> the minimum needed but not general (I don't know the API's so I might be 
> wrong on that score)
> 
> * We really don't want to maintain YAP (Yet Another Package)
> 
> * dnspython seems more complete, widely used, has other maintainers and 
> support we can leverage. (Should we have used it in the first place)
> 
> * Since dnspython is a superset and once we get ipapython.dnsclient 
> ported to it maybe we'll discover we can then easily user other features 
> dnspython provides.
> 
> Anyway, tough call, the right answer is not entirely obvious, just my 2 
> cents.
> 
> 

I like second approach more too. Although I think the best solution here
would be to discard ipapython.dnsclient as is and use dnspython directly
in our code. ipapython.dnsclient is not used on that many places in our
code anyway.

This way, we wouldn't have use our artificial dnsclient API in the
proposed bridge but rather use (more standard) dnspython API and have
access to all its native functionality.

Martin