Hi everyone,
The discussion on the addition of golang focuses on estimating community
costs vs. technical benefits, so that the TC can make the right call for
"OpenStack". From that discussion, we established that the costs for
cross-project teams (Infra...) seem to be workable. There is still
significant community fragmentation effects as we add another language,
creating language-expert silos, duplicating efforts, and losing some
productivity as some needlessly rewrite things in golang. But we seem
generally ready to accept that cost because we are missing a tool in our
toolbelt: a language that lets us do such native optimization.
We have a number of projects in OpenStack that are more low-level than
others and which require such optimization, and for those projects (or
subprojects) our current mix of language is not satisfactory. The Swift
team in particular has spent a lot of time trying to get the I/O
behavior they require with hard disk access using Python, and they
certainly did not jump on the golang bandwagon lightly.
I believe the programming languages you need in OpenStack official
projects are a function of the scope you define for OpenStack official
projects. We wouldn't need to have JavaScript in the mix if we
considered that web interfaces that purely consume OpenStack APIs are
projects that consume OpenStack, rather than part of OpenStack itself.
In the same vein, if we consider lower-level projects (which often
require such native optimization) as part of "OpenStack", rather than as
external open source projects that should be integrated by "OpenStack",
then we need a language like golang in our toolbelt. There is basically
no point in saying no to golang in OpenStack if we need lower-level
native optimization in OpenStack: we'll have to accept the community
cost that comes with such a community scope.
So the real question we need to answer is... where does OpenStack stop,
and where does the wider open source community start ? If OpenStack is
purely an "integration engine", glue code for other lower-level
technologies like hypervisors, databases, or distributed block storage,
then the scope is limited, Python should be plenty enough, and we don't
need to fragment our community. If OpenStack is "whatever it takes to
reach our mission", then yes we need to add one language to cover
lower-level/native optimization, because we'll need that... and we need
to accept the community cost as a consequence of that scope choice.
Those are the only two options on the table.
I'm actually not sure what is the best answer. But I'm convinced we, as
a community, need to have a clear answer to that. We've been avoiding
that clear answer until now, creating tension between the advocates of
an ASF-like collection of tools and the advocates of a
tighter-integrated "openstack" product. We have created silos and
specialized areas as we got into the business of developing time-series
databases or SDNs. As a result, it's not "one community" anymore. Should
we further encourage that, or should we focus on what the core of our
mission is, what we have in common, this integration engine that binds
all those other open source projects into one programmable
infrastructure solution ?
--
Thierry Carrez (ttx)
__________________________________________________________________________
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
