如何向Openstack社区提交一个新项目

    前几天有个朋友问我：本身有一个idea不错的项目，也把基本的框架写好了，想贡献到Openstack社区，殊不知道应该怎么作。正好以前我有过相似的经历，那么来分享一下我是如何向Openstack社区提交一个新项目。

    Openstack的整套系统就是一个开源项目的“大杂烩”，社区把全部项目划分为两类：核心和孵化。除非出身特别牛逼或者从其余核心项目独立出来的项目会在设计之初就被列为核心项目（例如Nuetron,Ironic等）；其余项目通常划分到孵化类，在经过一个或多个大版本的发展后，若是变得成熟知足预期并被社区接受，就会转正成为核心项目（例如Savana,Designate等)。若是你想查看当前有哪些核心和孵化项目，能够前去github上查看，它们分别托管在github的openstack和stackforge两大项目下：每一个核心项目几乎都是来自工业界IT巨头们的贡献，例如Swift项目来自于Rackspace,Nova项目来自于NASA，Horizon项目来自于HP…

 

    简单介绍一下我提交的新项目的来历：因为咱们的IaaS服务跨越多个Region，而且有较为复杂的DNS解析需求，所以咱们很早就使用了当时仍在孵化中的designate项目(DNSaaS)，用于管理UnitedStack内部的DNS服务。我发现社区并无提供用于管理Designate服务的puppet module，因而就写了一个puppet-designate，随着代码的日益完善，已经能够知足内部designate服务的管理，然而社区却一直没有开发puppet-designate module的计划。公司文化一直支持开源，我也一直活跃在社区中，但以往都是提交某个项目的bugfix或者blueprint，我心想何不尝试提交一个新项目到社区？

 

 

前期准备工做

    那么在试图说服社区接受本身的项目前，第一步得先规范本身的代码。

      不一样于我的项目，社区对于代码的规范要求很高。我列出如下几个注意点：

• 完善的代码文档：例如README，参数说明，每一个自定义资源类型或者类的使用举例，复杂逻辑的解释，将来须要重构的加上todo标注等等；
• 规范的代码格式：首先不能有语法错误，其次是代码风格要和社区一致，这些都有工具来检查，主要问题是在代码风格上，空2格仍是空4格，双引仍是单引，不是为所欲为的；
• 合理的代码结构：主类中该放哪些部署逻辑，各服务的组件的部署逻辑该怎么划分，数据库初始化逻辑又该放在哪，都是有要求的；
• 完善的测试代码：社区项目都是以测试驱动的，有的项目甚至先有的是测试代码，若是你妄图向社区提交一段没有附带测试的代码，其后果就是：红色粗体不解释的-1。

 

沟通和反馈

      大约花了一个周末的时间，终于把上述工做作完了，那接下来要作的就是说服社区：接受puppet-designate项目。 我分析了一下Openstack社区的一个新项目大体能够分为两类：全新和已有项目。例如，Heat,Ceilometer就属于全新项目，先在ML上开个头，开始讨论架构，API的设计等等诸多细节，而后众人分领开发工做，接着开始编码最终实现。而Swfit,Nova就属于旧有项目，从其余公司贡献出来的时候，已经比较成熟或者已经有比较完整的架构了。puppet-designate就属于后者，Openstack社区全部相关的puppet项目归属于puppet-manager-core 组管理，当时的PTL是Puppetlabs的Dan Bode。

第一步，我须要发送一封邮件到社区的邮件列表中来告知参与这个项目的全部成员：我准备提交一个puppet-designate项目来管理designate服务。

这里有一点很重要，就是了解在这个邮件列表中，谁说了算:)。

简单解释一下，每一个项目都有一个PTL以及相关的core members，他们是项目的主要贡献者。那么如何查询到具体有哪些人呢？能够在https://review.openstack.org的Groups分类中找到。

因而，我把邮件发送到社区的ML同时抄送给了PTL和其余几位很是活跃的core members。邮件里我说清楚地说明了puppet-designate的目的和完成度，以及附带一个github代码地址，以便review。

鉴于国内和国外的时差，邮件次日获得了回复，获得了PTL和几位core member的确定，不出所料的是，个人代码被指出了一堆问题，接下来须要进一步地改进。

因为时差的关系，我与社区的协做效率是不高的，在通过大约一周时间的邮件沟通和屡次修改后，代码终于经过了这帮有强迫症的工程师的review。

 

提交到openstack-intra/config

虽然代码经过了社区的批准，但这并不意味着puppet-designate项目就能立马出如今stackforge中了。接着，我开始阅读社区的CI文档，了解到社区CI系统的管理工做是经过config项目来完成的，Openstack的整套CI系统以及咱们所看到的Openstack主站以及其余相关站点都是经过puppet来管理的，该项目就包含了用于管理和配置的modules和manifests，属于openstack-intra组负责。Openstack-intra组的主要工做是负责Openstack站点和CI系统的开发和维护。

所以，我须要向config项目提交一个新patch来添加puppet-designate项目，这个PatchSet看起来是这样的：

 

首先，修改modules/gerritbot/files/gerritbot_channel_config.yaml文件，这个配置文件用于管理各项目的gerritbot，当发生指定的事件后，IRC上的gerritbot会发送通知：

 

接着须要修改modules/openstack_project/files/jenkins_job_builder/config/projects.yaml，告知Jenkins在处理来自gerrit的puppet-designate patchset时，须要执行哪些job：

 

而后还须要修改modules/openstack_project/files/zuul/layout.yaml，告知zuul在作check和gate工做的时候要执行哪些job。:

 

最后修改modules/openstack_project/templates/review.projects.yaml.erb文件，告知gerrit 新建一个stackforge/puppet-designate的项目，而且去github上拉去初始的puppet-designate代码。

 

等待Approve

      在提交了这个patchset后，我在IRC上去通知PTL和其余成员帮我+1，最后还要获得openstack-intra组core member的approve才行，因而我又去#openstack-intra频道里找人，终于找到一位哥们来帮我Approve。好事多磨，结果最后Gerrit在作merge操做时，Zuul所运行得gate测试报了一些莫名的错误，始终不让这个patchset merge。那哥们说：没事，明天前我会解决的。终于，在HK的Havana Summit前，puppet-designate项目出如今了Openstack社区的孵化项目里：https://github.com/stackforge/puppet-designate。

 

小结

虽然参与Openstack的社区开发已经近三年，但这是我第一次向社区提交一个新项目，经过此次经历，我有如下几点感触：

      1. 对于社区的CI系统有了更进一步的了解，由于过去当我输入git review时，整套CI是对我来讲是透明的，我根本不知道底层的CI系统各服务之间是如何交互的；

      2. 其次是学会和社区沟通，如何清晰地代表本身的观点，如何说服他人，如何找到能拍板的人，若能作好这三点有事半功倍的做用；

      3. 最后一点，对于代码的质量要求和规范上有了更深入的理解，有时候个人同事会不理解我在作code review时为何会对格式要求那么苛刻，其实我是水瓶座，只是这些习惯是在作社区开发的时候被逼出来的 :)