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 "XXX@XXXXXX.com"

注意跟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