【51CTO.com快译】一直以来OpenStack都只是用Python编写的，别的语言不是没用只是用到的很少，核心部分几乎都是Python，现有人提议让Go语言也用在API服务方面。

在新版本Newton出炉的周期中，技术评估委员会接到了一份把Go语言作为OpenStack官方开发语言的提议。随后进行了许多讨论，这里不过多赘述过程，只是谈谈几点讨论的结果。

决议是暂时拒绝让Go作为官方开发语言，但表示未来可以接着讨论，我觉得Go被拒绝可能有以下几方面的原因：

1.技术委员会成员担心增加新的语言会对社区造成的影响。会不会对社区带来分裂，会不会形成一个孤岛，会不会给新入门的人带来额外的门槛？
2.技术委员会的一些成员认为如今对社区中的一些方面缺乏信息，研究和工作。 Go代码如何在整个社区*享？ 认证怎么做？ 消息层怎么弄？ 如何产出版本？ 如何维持分支的稳定？
3.提议Go语言的团队除了自己的项目以外根本就没做过跨项目的任务，这不由得引起了怀疑，使得许多技术委员会的质疑是否能够顺利完成。

接受一门新的语言需要哪些条件呢？

我先声明，我所说的不代表技术委员会而仅代表我个人意见，从而方便交流，好会让整个社区的人发表意见，无论是同意或者反对我的想法。

讨论期间我最关心的是第一部分，主要是因为我觉得向“Big Tent”的迁移还没完成。我也不知道怎么才会让我觉得这迁移已经完成了，我能肯定的是我们在解决大的变化发生前需要解决的问题。

言归正传，我越来越喜欢给许多东西设定期望，尤其是一些能带来改变的请求。把预期列出来之后，就能让相关的人了解到他们正在向哪一个方向行进，并且找到改变可能会面临的问题。

我对第二个问题远没有第一个问题那么担心。它会对参与讨论这一变化的团队表现出很强的承诺，因为这涉及到未来对社区所有成员使用和参考的基础知识库。我以为第二部分的工作可能有些超纲，但并不是这样。通过研究怎么共享代码，怎么测试代码，怎么输出代码，怎么做认证库等，我们在设定未来实际工作中需要用到的基础的东西。

无论如何，我上面提到的“基础的东西”是什么呢？我将在下面不太详尽的列表中简单谈一下：

为新语言定义分享代码和库的方式

Oslo Team负责维护整个OpenStack社区需要经常用到的库。这些库包括消息库（oslo.messaging）,i18n库（oslo.i18n），数据库层库（oslo.db）等关键库。

这些库本身并不能让Oslo组的人忙起来，它们是为了收集以前在社区中存在于许多项目中的重复性的公共代码。这个代码现在由Oslo移除，稳定和发布。

我觉得作为一个社区，这是无可避免的。一旦越来越多的项目使用相同的语言就会出现共享代码的需求。 因此，我觉得我们需要更好地定义一个编程语言的代码怎么在社区共享，这个挺重要的，哪怕是在编程语言被接受之前就很重要。

我觉得提前做一些事情不意味着将来没事可做，我们都知道会有许多为预料到的事情和发生变化的事情，我觉得这些工作能涉及到大部分初始化的工作。

关于OpenStack基本服务的基本库

这可能看起来像一个相当高的目标。虽然想搞清楚代码如何共享是一个很困难的需求，但我认为这离OpenStack服务的最低要求还差很远。

集成在生态系统中的OpenStack服务至少需要以下任意一个库：

•keystoneauth / keystone-client
•oslo.config
•oslo.db
•oslo.messaging

如果在使用数据库或者消息队列抽象库的时候没有任何消耗的话，很可能提供的抽象层是错的，从而导致糟糕的API。从另一个方面说，认证层是几乎所有OpenStack服务都会用到的部分，应该可以很方便使用才对，但这不是说这件事本身很简单。

通过处理这些库中的任何一个，都可以进行CI（自动测试系统）作业，通过这些作业来确保新项目的基础设置是正确。

定义可交付项如何分布

OpenStack的发布过程几乎完全是自动化的，发布过程中涉及到的所有可交付项都是由社区自动产出并由发布团队来管理的。最后，将每个交付项生成压缩包。

目前使用Python编程语言（以及其他几门编程语言）的时候 ，这些压缩包因为只包含这些源代码所以还很简单。对于像Go这样的编译型语言，我们就得考虑压缩包里要压缩什么了，压缩编译过的二进制代码吗？是不是应该加入源代码呢？如果要包含二进制代码，是不是也应该考虑两种不同的压缩包呢？一个是二进制代码，一个是源代码。

维护稳定分支部分的工作怎么办？

稳定的分支在社区经常被遗忘，维护这些稳定分支的团队得到的感谢比较少。然而稳定分支的代码运行在许多OpenStack云环境下，它们对于向后兼容的后端迁移修复非常关键。

每一门语言都有自己发布库的方式，管理兼容性的方式。当为社区加入新的编程语言，与原有的其他团队之间的合作是至关重要的。

为新的语言设置CI管道

还有就是与基础设施组讨论设置CI（自动测试系统）管道。

这个任务可能是许多工作的基础。为了解决之前的许多任务，有必要设置CI（自动测试系统）作业，这涉及与基础架构团队协调。后者是至关重要的。 基础设施团队的参与对于添加任何新语言都至关重要，他们的反馈将在许多决策中发挥重要作用。

回顾一下为Python语言做的一些基础工作，其实是大多数项目都需要做的事情。我希望致力于加入新语言的团队可以做一些通用性的事情，为以后跨多个项目的时候使用。

比如会有以下几方面的通用性工作：

•Lint checkers
•Doc builders
•Release Pipelines

要做的似乎还有很多

把上面提到的方方面面都做到的话的确需要许多人力和时间。不幸的是，涉及到的许多团队真的腾不出手来做别的事情了，所以我觉得大部分工作将会由各组里多语言感兴趣的人来贡献出来的。无论如何，这些工作势必耽误每个团队的工作时间，即使是大部分的研究，文档和补丁都是由有兴趣的团队来自愿完成的。

整个社区花了多年时间让Python处于目前的状态。我不指望一个团队工作一个礼拜来把新的语言代码加入到已经用了六年的Python体系中。然而，机制已经建立，团队也已经存在，在一起协作下，上述的问题可能会在合理的时间点得到解决。

我希望这是个循序渐进的过程，这就是我为什么强调需要经过以上几个步骤的原因。人有流动性，即使是做过承诺有时候也不管用，我认为做这是最重要的是先做，然后在渐渐接受这门语言。

最后，即使存在一个形式良好的添加新语言的过程，我仍然推荐优先使用Python而不是其他语言。这与语言偏好无关，只是与我们社区中现有的知识的传播有关，我相信这种知识是无价的，将这些知识变成一种新的语言需要几年时间，相比之下优化则是一个更容易的任务

创新对很多项目都很重要。我们也相信不可能永远保持原样，语言的变化，项目的兴起，项目的消亡等等。加入新语言这回事儿也是社区变化 的一部分，我也希望OpenStack社区尽可能以最好的方式拥抱变革。但我希望是以一种相对保守的方式。我相信本文中提到的这些任务将会帮助大家未来以更快、更安全的方式来增加新的语言。

当然，以上都是我的个人观点，我现在越来越痴迷于明确预期。因此，我会起草并提交一份正式文档到技术委员会。

本文作者：朱朋博

来源：51CTO