Open Stack

/me puts on his Operator hat.....

Operators do care about being able to debug issues with the stuff they have to deploy/manage.

One of our complains about Java (and probably Erlang.. Not sure about go): In addition to the standard C like issues you hit, file descriptor limits, etc, the language has its own issues that it carries in. Java stack sizes, max memory limits that default too low, unusual command line switches, etc.

So, yes, operators don't tend to care too much about language if they can help it, but often the language makes them care.

Also, as someone that has had to write at least one patch (or backport myself) against something, pretty much every OpenStack upgrade I've done, familiarity with the language has greatly helped. Too many languages makes that harder. Sure, in an ideal world, OpenStack shouldn't require that out of an Operator and so language won't count as much. But we're not there yet.

I'm not saying don't do it. If its the right tool for the job, its the right tool for the job. Just be very cognizant of what you asking Operators to deal with. The language list is quite long already.

Thanks,
Kevin
________________________________________
From: Robert Collins [robertc at robertcollins.net]
Sent: Wednesday, May 11, 2016 1:11 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc] supporting Go

I'm going to try arguing the pro case.

The big tent has us bringing any *team* that want to work the way we
do: in the open, collaboratively, in concert with other teams, into
OpenStacks community.

Why are we using implementation language as a gate here?

I assert that most deployers don't fundamentally care about language
of the thing they are deploying; they care about cost of operations,
which is influenced by a number of facets around the language
ecosystem: packaging, building, maturity, VM
behaviour-and-tuning-needs, as well as service specific issues such as
sharding, upgrades, support (from vendors/community), training (their
staff - free reference material, as well as courses) etc. Every
discussion we had with operators about adding new dependencies was
primarily focused on the operational aspects, not 'is it written in
C/$LANGUAGE'. Right now our stock dependency stack has C (Linux, libc,
libssl, Python itself etc, Erlang (rabbitmq), java (zookeeper).

End users emphatically do not care about the language API servers were
written in. They want stability, performance, features, not 'Written
in $LANGUAGE'.

As a community, we decided long ago to silo our code: Nova and Swift
could have been in one tree, with multiple different artifacts - think
of all the cross-code-base-friction we would not have had if we'd done
that! The cultural consequence though is that bringing up new things
is much less disruptive: add a new tree, get it configured in CI, move
on. We're a team-centric structure for governance, and the costs of
doing cross-team code-level initiatives are already prohibitive: we
have already delegated all those efforts to the teams that own the
repositories: requirements syncing, translations syncing, lint fixups,
security audits... Having folk routinely move cross project is
something we seem to be trying to optimise for, but we're not actually
achieving.

So, given that that is the model - why is language part of it? Yes,
there are minimum overheads to having a given language in CI - we need
to be able to do robust reliable builds [or accept periodic downtime
when the internet is not cooperating], and that sets a lower fixed
cost, varying per language. Right now we support Python, Java,
Javascript, Ruby in CI (as I understand it - infra focused folk please
jump in here :)).

A Big Tent approach would be this:
 - Document the required support for a new language - not just CI
 - Any team that wants to use $LANGUAGE just needs to ensure that that
support is present.
 - Make sure that any cross-service interactions are well defined in a
language neutral fashion. This is just good engineering basically:
define a contract, use it.

Here is a straw man list of requirements:
 - Reliable builds: the ability to build and test without talking to
the internet at all.
 - Packagable: the ability to take a source tree for a project, do
some arbitrary transform and end up with a folder structure that can
be placed on another machine, with any needed dependencies, and work.
[Note, this isn't the same as 'packagable in a way that makes Red Hat
and Canonical and Suse **happy**, but thats something we can be sure
that those orgs are working on with language providers already ]
 - FL/OSS
 - Compatible with ASL v2 source code. [e.g. any compiler doesn't
taint its output]
 - Can talk oslo.messaging's message format

That list is actually short, and those needs are quite tameable. So
lets do it - lets open up the tent still further, stop picking winners
and instead let the market sort it out.

-Rob

__________________________________________________________________________
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