Open Stack

On Mon, May 9, 2016, at 01:01 PM, Hayes, Graham wrote:
> On 09/05/2016 20:46, Adam Young wrote:
> > On 05/09/2016 02:14 PM, Hayes, Graham wrote:
> >> On 09/05/2016 19:09, Fox, Kevin M wrote:
> >>> I think you'll find that being able to embed a higher performance language inside python will be much easier to do for optimizing a function or two rather then deal with having a separate server have to be created, authentication be added between the two, and marshalling/unmarshalling the data to and from it to optimize one little piece. Last I heard, you couldn't just embed go in python. C/C++ is pretty easy to do. Maybe I'm wrong and its possible to embed go now. Someone, please chime in if you know of a good way.
> >>>
> >>> Thanks,
> >>> Kevin
> >> We won't be replacing any particular function, we will be replacing a
> >> whole service.
> >>
> >> There is no auth (or inter-service communications) from this component,
> >> all it does it query the DB and spit out DNS packets.
> >>
> >> I can't talk for what swift are doing, but we have a very targeted scope
> >> for our Go work.
> >>
> >> - Graham
> > I'm assuming you have a whole body of work discussing Bind and why it is
> > not viable for these cases.  Is there a concise version of the discussion?
> 
> Because we work with multiple DNS servers. This is a component that
> sits between Designate and the end user DNS servers (like Bind,
> PowerDNS, NSD and others, or service providers like Akamai or DynECT)
> 
> The best solution for use to push out DNS information to other DNS
> servers was to us the DNS protocol, so we have a small DNS server that
> knows how to get zones and recordsets from our DB, and send them as
> zone transfers to the end user facing servers.
> 
> The design discussion happened 2 years ago now - this blueprint as the 
> most detail [0].
> 
> Ironically the entire conversation was driven by a need to scale the
> Bind9 backend by supporting an async API.
> 
> 0 - https://blueprints.launchpad.net/designate/+spec/mdns-master

This is a bit of an aside but I am sure others are wondering the same
thing - Is there some info (specs/etherpad/ML thread/etc) that has more
details on the bottleneck you're running in to? Given that the only
clients of your service are the public facing DNS servers I am now even
more surprised that you're hitting a python-inherent bottleneck.


Cheers,
Greg