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 > ________________________________________ > 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