OpenStack基金会：欢迎对我们的开放云进行测试！

OpenStack的发展已经迎来了全新阶段，今后各家供应商将首先对其进行统一化互操作性测试，而后新版本才会正式与广大用户见面。以上表达来自OpenStack基金会首席运营官Mark Collier，他认为这种对互操作性的证明工作对于各家技术厂商而言极为重要。

随着电信及银行等新的企业成员加入进来，OpenStack基金会开始面临更多对互操作性的需求压力，这也直接促使其全力调整OpenStack项目自身以满足此类要求。

OpenStack基金会指出，其下有30位组织机构成员至今从未对开源项目作出任何贡献，但却始终对该开源项目加以使用——这一数字较2014年20位有所增加。

为了保持OpenStack的代码库规模与自身声誉，基金会方面决定在互操作性测试方面采取引导举措。

就在本周三，十六家供应商借本届巴塞罗那OpenStack峰会之机展示了一款测试LAMP应用，其能够成功部署并运行在不同硬件以及OpenStack发行版之上。

而这款应用的根源，来自六个月之前由IBM公司在OpenStack的德克萨斯州奥斯汀峰会上发布的一项互操作性挑战目标。

“我始终坚信这样的事实，即着眼于未来，除非OpenStack能够运行全部相关产品，否则各企业成员将选择自行寻求可行的实现途径，”Collier在本次大规模互操作性展示之后的采访中指出。

“当初我们规划这项互操作性挑战时，我们本以为只会有五、六家企业参与进来。然而但发布这项消息后，来电不断且收件箱很快被塞满——这意味着大家实际上都非常关注并希望自己的产品能够被纳入这份互操作性兼容名单。”

基金会常务董事Jonathan Bryce表示，这项挑战展示出了互操作性的巨大价值。“我们希望鼓励人们牢记互操作性的重要意义：相较于坐等六个月以被动期待特定功能被纳入发行版当中，不如将其提交给上游社区并由我们执行相关工作，从而确保大家能够切实获得相关功能并保证其可与系统内的全部现有组件协同运作。”

要获得OpenStack基金会的认可，各家成员企业必须证明自身的现有方案能够与官方规范及API相兼容。本轮发布的新测试限定于特定应用，且主要面向工作负载。

这一测试应用属于OpenStack旗下一支工程团队的开发成果，该团队主要在编排与容器管理领域围绕Heat与Chief开展工作，并将Docker与网络功能虚拟化项目作为工作负载; 最终以说明文档及代码的形式将其纳入编排工具当中。OpenStack基金会计划进一步加大这方面工作的推进力度。

Collier认为不必强制设定具体工作量。“我相信所有发布产品的企业都会在自己的产品化流程当中纳入这一测试机制——它们会自觉设立互操作性标准并加以执行。我认为我们并不需要进行强制性要求。”

与此同时，OpenStack基金会还于今年8月批准了一项新的OpenStack规范，其将功能数量由125个增加至225个。

随着更多内容被添加到基础规范中来，成员们希望能够尽量减少由不受支持功能所带来的困扰与产品开发阻碍。

对于OpenStack项目来说，互操作性也因此成为一个愈发严重的难题。

所有开源项目的狂热参与者都乐于发布fork，而新成员对于开源领域的经验欠缺已经给OpenStack带来巨大压力——这意味着其迫切需要出台一项新策略，用于解决此类问题。

曾有某位基金会成员构建起了自己的一套DNS管理系统，而未等待OpenStack方面的官方解决方案。OpenStack DNS管理已经于六个月前完成开发，并被纳入Nova当中以供全部社区成员加以使用。这意味着此前开发的这套独立DNS管理系统在耗费了大量资源之后，将无任何发展前景可言。

“这意味着其严重缺乏成本效益。效益非常短暂，而投入的时间与资金成本则相当高昂，”Collier表示。

Bryce认为，新的OpenStack参与各方可能会以红帽Linux等操作系统的方式消费开源成果，但OpenStack则将成为其首个真正作出代码贡献的开源项目。

“第一波开源浪潮的胜利很像是从专有供应商处购买技术的消费模式，”Bryce解释称。“为了能够让开源成果进入企业，红帽公司独力前行并采取类似于微软的产品销售策略。”

“如今大家有了OpenNFV，且从传统角度讲并不直接参与知识产权开发工作的电信服务商，都已经加入到了项目构建的流程中来。”

“他们在看到源代码时会说：‘如果我能实现这项功能，那么为什么不能实现另一项功能？’而这正是促进其学习的动力所在。”