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.ha...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
