问题描述
当前我们云主机服务提供了很多功能，包括比较大的功能和很多琐碎的功能，这些功能有些是openstack官方提供的，有些是我们二次开发实现的，如果我们不打算合并社区新版本，这个问题并不严重，基本所有功能都在代码里面，随版本发布，基本不会发生功能丢失问题，但是一旦要升级到官方更新的版本，移植代码过程中，很容易就会发生功能丢失问题，由于没有完整的功能清单，QA回归测试也很难完整的发现这类问题，尤其是那些对外不提供API接口的功能更容易遗漏。
对于openstack官方提供的功能，官方release notes会把API或者功能变更列出来，我们可以据此获知官方功能的变动，所以没有功能清单一般来说问题不大，只要保证API接口不变即可。
另外我们的API文档已经维护的很规范，自从改进维护方式之后，基本没有发生过API遗漏或忘记更新的问题，这也是我们可以参考的一种可靠的文档维护方式。
解决方案
受影响的项目
初期仅维护云主机使用的开源项目：nova、cinder、keystone、glance，后续根据需要来决定是否把自研项目：umbrella、sentry等纳入管理。
功能清单内容
包含所有非官方改动，基本包含了所有非cherry-pick社区代码的改动。
开发流程变动
为此打算参考我们的API文档维护方式以及openstack社区新功能开发流程，把功能清单放到git仓库里面进行管理，类似当前的API文档维护方式：
- 开发人员提交功能代码到gerrit（nova、cinder等git仓库）
- 开发人员提交API文档改动gerrit（doc-api git仓库）
- review人员对代码和文档进行评审，通过后将代码和API文档改动一起合入仓库，不通过则由开发人员继续修改（只有代码和文档都review通过才能同时入库，代码或文档不能单独合入）
在上述流程中加入功能清单文档改动提交gerrit步骤，也即：
- 开发人员提交功能代码到gerrit
- 开发人员提交API文档改动到gerrit（如有API变动）
- 开发人员提交功能清单文档改动到gerrit（如有功能变动）
- 上述3种改动要同时入库，不可单独合入
- 对于开发人员不确定是否需要提交功能清单改动的开发任务，由review人员负责确定。
功能清单保存方式
初步考虑把功能清单文档放入各个项目的doc目录下，新建netease目录，如nova\doc\netease\features.rst，以rst（reStructuredText）格式文档保存，Jenkins中增加文档编译项目，入库后自动拷贝编译结果到文档服务器相关目录，以供查看。
也即除保存位置不同外其他流程与API文档保存方式相同。
功能清单初始化
针对目前已有的功能，我会整理一份清单出来，大家后续只关注新增功能即可。
