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