/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 [robe...@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-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
