Open Stack

On 9 May 2016, at 11:14, 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

This is exactly the direction Swift is exploring--replacing a part of the whole that is already it's own daemon and/or network service.

--John




>
>> ________________________________________
>> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160509/6f4bf536/attachment.pgp>