Open Stack

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
>
>>
>>> ________________________________________
>>> From: Hayes, Graham [graham.hayes at hpe.com]
>>> Sent: Monday, May 09, 2016 4:33 AM
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> Subject: Re: [openstack-dev] [tc] supporting Go
>>>
>>> On 08/05/2016 10:21, Thomas Goirand wrote:
>>>> On 05/04/2016 01:29 AM, Hayes, Graham wrote:
>>>>> On 03/05/2016 17:03, John Dickinson wrote:
>>>>>> TC,
>>>>>>
>>>>>> In reference to http://lists.openstack.org/pipermail/openstack-dev/2016-May/093680.html and Thierry's reply, I'm currently drafting a TC resolution to update http://governance.openstack.org/resolutions/20150901-programming-languages.html to include Go as a supported language in OpenStack projects.
>>>>>>
>>>>>> As a starting point, what would you like to see addressed in the document I'm drafting?
>>>>>>
>>>>>> --John
>>>>>>
>>>>>>
>>>>>>
>>>>> Great - I was about to write a thread like this :)
>>>>>
>>>>> Designate is looking to move a single component of ours to Go - and we
>>>>> were wondering what was the best way to do it.
>>>> We discussed about this during the summit. You told me that the issue
>>>> was a piece of code that needed optimization, to which I replied that
>>>> probably, a C++ .so extension in a Python module is probably what you
>>>> are looking for (with the advice of not using CFFI which is sometimes
>>>> breaking things in distros).
>>>>
>>>> Did you think about this other possibility, and did you discuss it with
>>>> your team?
>>> We had a brief discussion about it, and we going to try a new POC in
>>> C/C++ to validate it, but then this thread (and related TC policy) were
>>> proposed.
>>>
>>> If Golang is going to be a supported language, we would much rather
>>> stick with one of the official OpenStack languages that suits our
>>> use case instead of getting an exemption for another similar language.
>>>
>>> When we spoke at the summit, I was under the impression that the feature
>>> branch in swift was not going to be merged to master, and we would have
>>> to get an exemption from the TC anyway - which we could have used to get
>>> C / C++.
>>>
>>> The team also much preferred the idea of Golang - we do not have much
>>> C++ expertise in the Designate dev team, which would slow down the
>>> development cycle for us.
>>>
>>> -- Graham
>>>
>>>> At the Linux distribution level, the main issue that there is with Go,
>>>> is that it (still) doesn't support the concept of shared library. We see
>>>> this as a bug, rather than a feature. As a consequence, when a library
>>>> upgrades, the release team has to trigger rebuilds for each and every
>>>> reverse dependencies. As the number of Go stuff increases over time, it
>>>> becomes less and less manageable this way (and it may potentially be a
>>>> security patching disaster in Stable). I've heard that upstream for
>>>> Golang was working on implementing shared libs, but I have no idea what
>>>> the status is. Does anyone know?
>>>>
>>>> Cheers,
>>>>
>>>> Thomas Goirand (zigo)
>>>>
>>>>
>>>> __________________________________________________________________________
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>