如何向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時爲何會對格式要求那麼苛刻，其實我是水瓶座，只是這些習慣是在作社區開發的時候被逼出來的 :)