Nova提交BP的最新流程

背景

經過社區討論,從juno版本開始,nova提交BP的流程發生了很大的變化,與提交代碼類似,增加了使用gerrit進行BP的review過程 。nova有一個專門的團隊負責BP的review工作,就是nova-drivers,,他們由nova的PTL領導.爲了方便nova-drivers的成員review BP,需要BP的提交人像提交代碼一樣向nova-specs裏提交BP的規格文檔。

提交BP的流程

• 註冊BP

像以前的版本一樣，在launchpad裏註冊自己的BP.  https://blueprints.launchpad.net/nova/+addspec

• 撰寫BP的設計規格文檔

按照社區模板要求 http://git.openstack.org/cgit/openstack/nova-specs/tree/specs/template.rst ,撰寫BP設計規格文檔。

..
 This work is licensed under a Creative Commons Attribution 3.0 Unported
 License.

 http://creativecommons.org/licenses/by/3.0/legalcode

..

==========================================
Example Spec - The title of your blueprint
==========================================

Include the URL of your launchpad blueprint:

https://blueprints.launchpad.net/nova/+spec/example

Introduction paragraph -- why are we doing anything? A single paragraph of
prose that operators can understand.


Problem description
===================

關於問題的詳細描述,包括：

1.如果是個新特性，你需要詳細描述這個新特性的使用場景,以及每個場景下最終用戶和部署者的角色。
2.如果是一個已經存在的功能，你需要描述當前功能實現機制或代碼的問題，


Proposed change
===============

這裏是詳細描述你將在哪裏做出改變，怎樣實現你的BP以解決上節所提出的問題。

如果這個BP是從一個很大的BP中拆分出來的，那麼你先詳細描述這個BP的所能解決問題的範圍。


Alternatives
------------

是否還有其他的解決方法？爲什麼不選擇這些方法？

這裏重點是要說明問什麼你的解決方案是更好的。

Data model impact
-----------------

對數據模型的影響


REST API impact
---------------
對nova暴露出的API的影響

Security Impact
---------------

對nova安全方面的影響

Notifications impact
--------------------
對已經存在通知機制和信息的影響

Other End user impact
---------------------

對最終用戶的影響

Performance Impact
------------------

性能的影響

Deployer impact
---------------

對部署openstack的影響

Developer impact
----------------

對其他nova開發人員的影響

Implementation
==============

Assignee(s)
-----------

由誰來實現這個BP，如果是多個人參與實現的話，誰是主要貢獻者，其他貢獻的人事誰？

Primary assignee:
  <launchpad-id or None>

Other contributors:
  <launchpad-id or None>

Work Items
----------

整個工作可以劃分爲那些內容和階段？


Dependencies
============

BP的實現有那些依賴，這些依賴可能來源於其他BP，或其他組件的改動？


Testing
=======

怎樣測試代碼？


Documentation Impact
====================

對文檔內容的影響

References
==========

BP設計文檔中所涉及的應用

1. 將寫好的BP設計規格文檔命名爲與launchpad上註冊的BP同名的文件，例如BP的註冊內容鏈是https://blueprints.launchpad.net/nova/+spec/awesome-thing ，那麼文件的名字就應該是awesome-thing.rst。
2. BP設計規格文檔的語法應該是符合ReSTructured 風格的，這種文檔語法的詳細描述見 http://sphinx-doc.org/rest.html。如果你想檢查一下自己所寫的設計文檔是否符合要求，可以使用一個在線網站 http://rst.ninjs.org/ 
3. 請大家特別注意英語的準確性和規範性。建議使用word的英語糾錯功能，檢查英文的拼寫和格式。

• 提交社區review

這裏先引用wiki上gerrit的運作流程圖，說明一下提交代碼的流程

按照社區提交代碼的流程，向nova-specs提交上第一步所寫的BP設計規格說明，我假設是第一次提交,具體步驟如下：

1.註冊賬戶https://www.openstack.org/join/register/ 

2.簽署ICLAhttps://review.openstack.org/#/settings/agreements

3.上傳自己的ssh key，https://review.openstack.org/#/settings/ssh-keys

用於通過SSH向gerrit push代碼，方法參見：https://help.github.com/articles/generating-ssh-keys

4.安裝git並配置

git config --global user.name "XXX"
git config --global user.email "[email protected]"

注意跟gerrit賬戶一致,可以到這裏 https://review.openstack.org/#/settings/

5.安裝git-review，參見：http://www.mediawiki.org/wiki/Gerrit/git-review

6.下載nova-specs

git clone git://git.openstack.org/openstack/nova-specs

7.配置工程感知gerrit

	cd nova-specs/
	git review -s

首先會確保能使用你的ssh key登錄gerrit，默認使用當前git環境變量配置的用戶，否則，會提示輸入gerrit用戶名。成功後，會在nova目錄下生成一個.gitreview目錄，根據提示還需要配置gerritusername的參數。

8.新建分支，分支名是“bp/BP-NAME”，其中的BP-NAME是在launchpad上bp的名稱。

	git branch bp/BP-NAME
	git checkout bp/BP-NAME

9.提交代碼，將bp設計文檔添加到"specs/<release>" 目錄下，然後提交

	git add .
	git commit 
	git review

10.確認，提交成功後，可以到這裏確認：https://review.openstack.org/#/q/nova-specs,n,z 檢查是否一致

• 更新BP註冊頁面的內容

提交BP設計規格後，更新launchpad註冊的blueprint頁面，設置blueprint的URL爲bp的設計規格文檔的URL，並且更新完成bp的時間點

提交後，修改BP的流程

1.獲取自己之前提交的BP

git clone git://git.openstack.org/openstack/nova-specs
git-review -d 87323 #review_number

2.修改自己的BP設計文檔

3.提交更新

git commit --amend
git review

參考資料

• http://blog.csdn.net/lynn_kong/article/details/9405567