如何开启OpenStack社区贡献之路

OpenStack作为第二大开源社区，拥有众多代码贡献者。但是，对于刚刚接触OpenStack，想要了解OpenStack源码，并且想为OpenStack的开发贡献自己的一份力量时，经常会不知从何下手。本文便是针对此类情况，介绍如何加入社区，如何提交commit，如何review代码等问题展开的。

1、签订ICLA
参与社区贡献前，需要签订ICLA协议。进入docs.openstack.org网站,在Contributor Guides下找到并点击“OpenStack Infrastructure User Manual ”。如图1所示

图1


图2


图3


图4

2、上传自己的SSH 密钥
这里请参考github上的操作说明: https://help.github.com/articles/generating-ssh-keys

3、配置Git Bash

git config –global user.name “XXX”
git config –global user.email XXX@XXXXXX.com

此处填写要与gerrit账户一致。

4、安装git-review
具体步骤请参考https://www.mediawiki.org/wiki/Gerrit/git-review

5、下载源码库
作为刚刚接触社区的同学，建议先在openstack-manuals项目上下手，一方面可以借此熟悉openstack。同时，在进行社区贡献，验证bug时，促使自己动手操作，增加运维经验。先从github上下载源代码，以OpenStack社区手册openstack-manuals为例：

git clone git://github.com/openstack/openstack-manuals.git
cd openstack-manuals
git review -s

首先会确保能使用你的ssh key登录gerrit，默认使用当前git环境变量配置的用户，否则，会提示输入gerrit用户名，可以通过这个链接查看gerrit用户名。
成功后，会在openstack-manuals目录下生成一个.gitreview目录
最新代码：

git checkout master
git pull

新建分支，如果是blueprint，分支名是“bp/BP-NAME”，其中的BP-NAME是在launchpad上bp的名称;如果是修复bug，分支明是“bug/BUG-NUMBER”，其中BUG-NUMBER可以在bug页面上找到：

git checkout -b BRANTCH-NAME

6、commit

注意，在每提交一个新的commit之前，请先确保代码是最新的。执行下面两条命令更新库。

git checkout master
git pull

提交代码前，还需要对openstack-manuals目录下的.git文件夹内的两个文件进行修改。

cd openstack-manuals
cd .git/
vim config

[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
#[remote "origin"]
#       url = https://github.com/openstack/keystone
#       fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
        remote = origin
        merge = refs/heads/master

[remote "origin"]
       url = git://git.openstack.org/openstack/openstack-manuals.git
       fetch = +refs/heads/*:refs/remotes/origin/*
[remote "gerrit"]
     url = https://username:password@review.openstack.org/openstack/openstack-manuals.git
     fetch = +refs/heads/*:refs/remotes/gerrit/*

上文代码中的username:password部分请在下图所示的页面中查看，第一次需要生成一个密码，可以重复生成，请尽量选择使用没有特殊字符的密码，由大小写字母加数字的密码即可。

若是在nova项目下，请修改openstack-manuals为nova即可。

vim hooks/commit-msg
此文件为自动生成并添加commit的changeID。

复制粘贴以下内容

#!/bin/sh
# From Gerrit Code Review 2.8.4-19-g4548330
#
# Part of Gerrit Code Review (http://code.google.com/p/gerrit/)
#
# Copyright (C) 2009 The Android Open Source Project
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#
unset GREP_OPTIONS
CHANGE_ID_AFTER="Bug|Issue"
MSG="$1"
# Check for, and add if missing, a unique Change-Id
#
add_ChangeId() {
        clean_message=`sed -e '
                /^diff --git .*/{
                        s///
                        q
                }
                /^Signed-off-by:/d
                /^#/d
        ' "$MSG" | git stripspace`
        if test -z "$clean_message"
        then
                return
        fi
        if test "false" = "`git config --bool --get gerrit.createChangeId`"
        then
                return
        fi
        # Does Change-Id: already exist? if so, exit (no change).
        if grep -i '^Change-Id:' "$MSG" >/dev/null
        then
                return
        fi
        id=`_gen_ChangeId`
        T="$MSG.tmp.$$"
        AWK=awk
        if [ -x /usr/xpg4/bin/awk ]; then
                # Solaris AWK is just too broken
                AWK=/usr/xpg4/bin/awk
        fi
        # How this works:
        # - parse the commit message as (textLine+ blankLine*)*
        # - assume textLine+ to be a footer until proven otherwise
        # - exception: the first block is not footer (as it is the title)
        # - read textLine+ into a variable
        # - then count blankLines
        # - once the next textLine appears, print textLine+ blankLine* as these
        #   aren't footer
        # - in END, the last textLine+ block is available for footer parsing
        $AWK '
        BEGIN {
                # while we start with the assumption that textLine+
                # is a footer, the first block is not.
                isFooter = 0
                footerComment = 0
                blankLines = 0
        }
        # Skip lines starting with "#" without any spaces before it.
        /^#/ { next }
        # Skip the line starting with the diff command and everything after it,
        # up to the end of the file, assuming it is only patch data.
        # If more than one line before the diff was empty, strip all but one.
        /^diff --git / {
                blankLines = 0
                while (getline) { }
                next
        }
        # Count blank lines outside footer comments
        /^$/ && (footerComment == 0) {
                blankLines++
                next
        }
        # Catch footer comment
        /^\[[a-zA-Z0-9-]+:/ && (isFooter == 1) {
                footerComment = 1
        }
        /]$/ && (footerComment == 1) {
                footerComment = 2
        }
        # We have a non-blank line after blank lines. Handle this.
        (blankLines > 0) {
                print lines
                for (i = 0; i < blankLines; i++) {
                        print ""
                }
                lines = ""
                blankLines = 0
                isFooter = 1
                footerComment = 0
        }
        # Detect that the current block is not the footer
        (footerComment == 0) && (!/^\[?[a-zA-Z0-9-]+:/ || /^[a-zA-Z0-9-]+:\/\//) {
                isFooter = 0
        }
        {
                # We need this information about the current last comment line
                if (footerComment == 2) {
                        footerComment = 0
                }
                if (lines != "") {
                        lines = lines "\n";
                }
                lines = lines $0
        }
        # Footer handling:
        # If the last block is considered a footer, splice in the Change-Id at the
        # right place.
        # Look for the right place to inject Change-Id by considering
        # CHANGE_ID_AFTER. Keys listed in it (case insensitive) come first,
        # then Change-Id, then everything else (eg. Signed-off-by:).
        #
        # Otherwise just print the last block, a new line and the Change-Id as a
        # block of its own.
        END {
                unprinted = 1
                if (isFooter == 0) {
                        print lines "\n"
                        lines = ""
                }
                changeIdAfter = "^(" tolower("'"$CHANGE_ID_AFTER"'") "):"
                numlines = split(lines, footer, "\n")
                for (line = 1; line <= numlines; line++) {
                        if (unprinted && match(tolower(footer[line]), changeIdAfter) != 1) {
                                unprinted = 0
                                print "Change-Id: I'"$id"'"
                        }
                        print footer[line]
                }
                if (unprinted) {
                        print "Change-Id: I'"$id"'"
                }
        }' "$MSG" > "$T" && mv "$T" "$MSG" || rm -f "$T"
}
_gen_ChangeIdInput() {
        echo "tree `git write-tree`"
        if parent=`git rev-parse "HEAD^0" 2>/dev/null`
        then
                echo "parent $parent"
        fi
        echo "author `git var GIT_AUTHOR_IDENT`"
        echo "committer `git var GIT_COMMITTER_IDENT`"
        echo
        printf '%s' "$clean_message"
}
_gen_ChangeId() {
        _gen_ChangeIdInput |
        git hash-object -t commit --stdin
}
add_ChangeId

一个示例：
在通过按照社区安装文档上的指导进行部署OpenStack后，登录dashboard，会提示一系列错误，找到修复办法是需要禁用掉三层的各个服务。首先需要在配置文档界面提交bug,该页面应该是你增加修复办法的页面。如下图所示：

会进入提交bug界面：

1. 先用尽量简洁的话概述自己所遇到的bug.
2. 点击Check ,看是否已经有人提出过，系统会搜索所有已提出的bug,然后列出与你所提出的可能相同的bug，逐个检查是否与你将要提出的bug一致，若一致，请勿再次提出，若没有，则点击继续提出bug。
3. 填写更多信息，若标题已足以表情达意，则无需赘述。
4. 点击Submit Bug Report.
   
   
   进入bug详细信息界面，如下图所示：
   

回到终端界面，新建一个分支，并且修改如图中所示的doc/install-guide/source/horizon-install.rst文件。命令如下:
新建一个分支，为了便于以后好查看，分支名可以使用bug/ BUG-NUMBER来命名，实现一个BP也是同理。

git checkout -b bug/1526721

修改文件。

vim doc/install-guide/source/horizon-install.rst

将要添加的修复bug配置根据OpenStack社区文档格式要求进行修改，添加。然后保存。

cd doc/install-guide/source/
git add horizon-install.rst
git commit

会跳转至commit message编辑界面。
在单独的一行中写summary(小于50个字符)，然后空一行，第二段进行详细的描述。再空一行，最后一段如果是实现bp或修复bug，需注明：

blueprint BP-NAME
Close-bug: #BUG-NUMBE

如下图所示。

详细的代码提交信息，参见：https://wiki.openstack.org/wiki/GitCommitMessages
然后提交代码，申请review

git commit –amend
git review

需要注意的是，如果进行了第二次修改，再次git commit时，请务必加上—amend参数，除非你想覆盖掉之前的patch。

7、review

下面介绍如何评审他人提交的代码。如图5所示，点击所标注的链接，进入还未合并的代码页面，如图6所示。

图5

图6

图6中，需要说明的是最后的三列，”CR”指的是最新的一个reviewer评审的情况，”+1“指代码没什么问题，看起来不错；”-1”表示代码有些问题，需要代码提交者进一步修改；”+2”会显示成绿色的小勾，一般的社区人员无法给出，是由社区的Core给出的，表示代码满足合并的要求，当有两个不同的项目下的Core都给出了”+2”，workflow（也就是最后一列的”W”）+1后，该Commit才会进入合并阶段。当给出CR显示为”-2”时，该Commit就可以被Abandoned掉了。

“V”列表示verified，代码测试。每当一个新的Commit或者原有的Commit有新的修改后，会由Jenkins自动测试，若测试通过，则为”+1”，若有一项失败，便会显示为”-1”。

“W“列表示workflow，”+1”时在上文已经介绍过，这里不在重复，当”W”列为”-1”时，表示代码不能进入合并阶段。

点击一个subject，进入gerrit评审界面。

点击图中箭头指示的链接，进入代码展示界面。

图中绿色区域便是我们新添加进去的配置，与原来的文件内容不同的，背景都会是绿色高亮显示。当你评审一处绿色区域的代码后，发现了有需要改正的地方，可以按住鼠标左键划动你觉得需要修改的地方，然后按c键，就会弹出代码评论编辑对话框：

在评审了所有绿色区域的代码后，便可以点击右上角的绿色的向上箭头回到gerrit评审界面，点击Reply进行评审给分。

各分值得含义在上面我已经介绍过了，如果你要-1，请说明理由。请不要在别人已经指出需要修改，并且给出了code review-1的地方再次提出-1，此为刷榜行为，会严重影响公司国际形象。

这样，我们就完成了一个review。

本文由九州云独家授权发布

2016年3月18日-19日，由CSDN重磅打造的数据库核心技术与实战应用峰会、互联网应用架构实战峰会将在上海举行。这两场峰会将邀请业内顶尖的架构师和技术专家，共同探讨高可用/高并发系统架构设计、新技术应用、移动应用架构、微服务、智能硬件架构、云数据库实战、新一代数据库平台、产品选型、性能调优、大数据应用实战等领域的热点话题与技术。

2月29日24点前仍处于最低六折优惠票价阶段，单场峰会（含餐）门票只需799元，5人以上团购或者购买两场峰会通票更有特惠，限量供应，预购从速。（票务详情链接）。