前几天有个朋友问我：自己有一个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时为什么会对格式要求那么苛刻，其实我是水瓶座，只是这些习惯是在做社区开发的时候被逼出来的 :)