初窥微服务

在当前的这个年月,微服务已经不是一个新的事物.不过我觉得还是应该写几篇文章,整理一下个人对于微服务的一些认识.

什么微服务

以下内容来自维基百科

Microservices are a software development technique—a variant of the service-oriented architecture (SOA) architectural style that structures an application as a collection of loosely coupled services. In a microservices architecture, services are fine-grained and the protocols are lightweight. The benefit of decomposing an application into different smaller services is that it improves modularity. This makes the application easier to understand, develop, test, and become more resilient to architecture erosion.^[1] It parallelizes development by enabling small autonomous teams to develop, deploy and scale their respective services independently.^[2] It also allows the architecture of an individual service to emerge through continuous refactoring.^[3] Microservices-based architectures enable continuous delivery and deployment.^[4]

今天在进行mysql连接的时候,突然遇到了一个问题

1

MySQLNonTransientConnectionException: Could not create connection to database server.

通过上网查询,发现跟mysql驱动有关.

查看MySQL版本,发现我的MySQL版本竟然为最新的8.0.X版本.

查看配置文件

1
2
3

url: jdbc:mysql://localhost:3306/yannis?characterEncoding=utf8
 
driver: com.mysql.jdbc.Driver 

没发现有什么问题.查看文档后发现,MySQL8.0.X版本对应的驱动以及mysql-connectiont-java版本已做过修改.
找个新版本的jar,修改driver及url.

1
2
3

url: jdbc:mysql://localhost:3306/yannis?characterEncoding=utf8&useSSL=false&serverTimezone=UTC&rewriteBatchedStatements=true
 
driver: com.mysql.cj.jdbc.Driver

OpenStack nova compute supports two flavors of Virtual Machine (VM) migration:

• Cold migration(冷迁移) – migration of a VM which requires the VM to be powered off during the migrate operation during which time the VM is inaccessible.
• Hot or live migration(热迁移) – zero down-time migration whereupon the VM is not powered off during the migration and thus remains accessible.

Understanding these VM migration operations from an OpenStack internals perspective can be a daunting task. I had the pleasure of digging into these flows in the latter part of 2013 and as part of that effort created a rough outline of the internal flows. Other’s I’ve worked with found these flow outlines useful and thus they’re provided below.

Note – The outlines below were created based on the OpenStack source in late 2013 and thus reflect the state of OpenStack at that point in time.

虽然已经见过多次Annotation,也亲身自使用过自定义注解.但对此还是不慎寥寥.特整理文档于此,备忘一二.

Annotation是什么

Annotation中文翻译为注解.啥玩意呢?其实看着也不太明白.

官方解释如下:

Java注解用于为Java代码提供元数据。作为元数据，注解不直接影响你的代码执行，但也有一些
类型的注解实际上可以用于这一目的。Java注解是从Java5开始添加到Java 的。

懵吧,说实话看完之后还是各种似懂非懂.

看看百度百科怎么说的

java.lang.annotation，接口 Annotation。对于Annotation，是Java5的新特性，JDK5引入了
Metadata（元数据）很容易的就能够调用Annotations。Annotations提供一些本来不属于程序的数
据，比如：一段代码的作者或者告诉编译器禁止一些特殊的错误。An annotation 对代码的执行没有
什么影响。Annotations使用@annotation的形式应用于代码：类(class),属性(attribute),方法
(method)等等。一个Annotation出现在上面提到的开始位置，而且一般只有一行，也可以包含有任意
的参数。

综合以上的描述,大概可以看到Annotation其实说白了一般就是一行代码,可以包含任意参数.
Annotation能被用来为程序元素（类、方法、成员变量等）设置元数据。Annotaion不影响程序代码的执
行，无论增加、删除Annotation，代码都始终如一地执行。如果希望让程序中的Annotation起一定的作
用，只有通过解析工具或编译工具对Annotation中的信息进行解析和处理。

注意:以上的描述中总有意无意的说一个词叫做元数据,那么什么是元数据呢?

最近在Python内使用单元测试时,发现了大概三种实现.在这里记录一下,以待后续使用
mock官网地址

1. [mox]使用StubOutWithMock

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

from mox3 import mox

    def test_create(self):
        req = fakes.HTTPRequest.blank('/fake/xen')
        req.method = 'POST'
        req.headers["content-type"] = "application/json"
        req.environ['nova.context'] = context.RequestContext(
            user_id='fake_user_id', project_id='fake_project_id',
            is_admin=True,
            roles=['admin', '_members_'])
        body_json = {"xen": {"address": "10.160.60.254",
                             "username": "root", "password": "tuscloud",
                             "pool_name": "fake_pool_name",
                             "physical_host": "fake_host"}}
        self.mox.StubOutWithMock(compute_api.API, 'create_xen_pool')
        compute_api.API.create_xen_pool(mox.IgnoreArg(), mox.IgnoreArg())\
            .AndReturn(None)
        self.mox.ReplayAll()
        self.controller.create(req, body_json)

该方法使用self.mox.StubOutWithMock将compute_api.API内的create_xen_pool进行mock,后续使用

1
2

compute_api.API.create_xen_pool(mox.IgnoreArg(), mox.IgnoreArg())\
            .AndReturn(None)

mock了该方法的返回值.

并使用了

1

self.mox.ReplayAll()

将所有的mock生效.

注意:

1
2

compute_api.API.create_xen_pool(mox.IgnoreArg(), mox.IgnoreArg())\
            .AndReturn(None)

以上代码的create_xen_pool方法内的参数个数与实际的参数个数一致.

该种方法存在问题:若想测试的方法内,同时调用了多次同一个方法.则无法使用该方式.self.mox.StubOutWithMock(compute_api.API, 'create_xen_pool')mock出来的方法,只能被一次有效调用.

2. [stub]使用stubs

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

def test_disable_host(self):
    def disable_xen_host(self, context, physical_host, host_uuid):
        return None
    req = fakes.HTTPRequest.blank(
        '/fake/xen/disable_host')
    req.method = 'POST'
    req.headers["content-type"] = "application/json"
    req.environ['nova.context'] = context.RequestContext(
        user_id='fake_user_id', project_id='fake_project_id',
        is_admin=True,
        roles=['admin', '_members_'])
    self.stubs.Set(objects.XenHost, 'get_host_by_filter',
                   self.fill_mock_host_enabled)
    self.stubs.Set(compute_api.API, 'disable_xen_host',
                   disable_xen_host)
    body_json = {"xen_host": "fake_host_id"}
    self.controller.disable_host(req, body_json)
    

def fill_mock_host_enabled(self, context, host_uuid):
    _mock_host = objects.XenHost()
    _mock_host.id = 4
    _mock_host.uuid = 'fake_host_id'
    _mock_host.name = 'fake_host_name'
    _mock_host.description = 'for test'
    _mock_host.address = '10.160.59.112'
    _mock_host.username = 'root'
    _mock_host.password = 'tuscloud'
    _mock_host.physical_host = 'sk-xen'
    _mock_host.is_master = 1
    _mock_host.master_uuid = 'c6d72541-bcb6-20f5-f1f0-64c66d24df91'
    _mock_host.pool_uuid = 'fake_pool_id'
    _mock_host.enabled = 1
    _mock_host.status = 'active'
    _mock_host.power_state = 'on'
    return _mock_host

如你所见,我们想要对objects.XenHost的get_host_by_filter进行mock,仅需要一句

1
2

self.stubs.Set(objects.XenHost, 'get_host_by_filter',
                       self.fill_mock_host_enabled)

就可以了.不过这里的self.fill_mock_host_enabled对应的是mock方法的返回值.
注意:

在self.fill_mock_host_enabled方法内的入参个数,要与实际要mock的get_host_by_filter方法要求的参数个数一样.

3. [mock]使用mock

该方法是我主要推荐的方法,最主要是因为写着简单,直接上示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

import mock

    @mock.patch('nova.objects.XenHost.get_host_by_filter')
    @mock.patch('nova.virt.tusxenapi.driver.XenAPIDriver._create_session')
    @mock.patch('nova.virt.tusxenapi.driver.XenAPIDriver._sync_pool_resources')
    def test_add_pool(self, _sync_pool_resources, _create_session, get_host_by_filter):
        pool_config = {
            "address": '192.168.1.1',
            "username": 'fake',
            "password": 'fake',
            "pool_name": 'test_pool_0',
            "physical_host": 'test-phy-host'
        }
        _create_session.return_value = self.create_fake_xen_session(pool_config.get('address', '127.0.0.1'))
        _sync_pool_resources.return_value = self._sync_pool_resources()
        get_host_by_filter.return_value = None
        self.driver.add_pool(context, pool_config)

如上,看着上面的代码有没有感觉很清新啊,基本内部没有什么其他的操作.唯一干的事情就是写上具体mock方法的返回值.

不过,需要注意的是.该方法使用的是装饰器,所以要求mock.patch的顺序与方法内的入参顺序是相反的.其他的就没什么了.你就可以愉快的玩耍了.

额外福利

如何来mock__init__方法内的方法.

1
2
3
4
5
6
7
8
9
10

import a

class Demo(object):
    def __init__(self):
        ......
        fun_return_value = a.methodB()
        ......

   def methodA(self):
       ......

这里给上使用mock的解决办法

1
2
3
4
5
6
7
8

class TestDemo(test.TestCase):
    def setUp(self):
        super(TestDemo, self).setUp()
        self.mocks = [mock.patch('a.methodB',
                                  mock.MagicMock(return_value=None))]
        for single_mock in self.mocks:
            single_mock.start()
            self.addCleanup(single_mock.stop)

此文章用于标记所关注的几个技术类网站.无聊时,可以看看.

• InfoQ
• IBM developer
• leecode
• stackoverflow
• segmentfault
• spring4all
• github
• 掘金
• 开源中国
• 推酷
• Spring Doc
• Spring Cloud中文网

在个人使用多方博客平台的时候，发现有一个需求目前各个博客平台均不支持。

需求：在某一个平台做完博客之后，可同步数据至其他各个博客平台

目前常见的博客网站

• 简书
• CSDN(ITEYE)
• 博客园
• github
• 语雀

其他的暂不清楚。

实现思路：

1. 一旦发出某一个博客的时候，同时向其他博客网站的创建日志接口发送请求；
2. 有一个以其他博客为标准，做博客同步的功能；

规划：

• 通用的http调用接口；
• 每个不同的网站对应不同的文件夹，处理不同的业务逻辑
• 各个网站内的博客查询及发送，独有的参数，需支持自有的配置文件获取；
• 项目开源，年底暂先实现一个网站的同步功能；

花费了将近一周的时间,才把rpm打包弄好.不能说已经了然于胸,但至少踩过了很多坑.接下来就顺顺在打包过程中的二三事.刚开始接到任务的时候,一脸懵逼.

作为专业的JAVA Web程序员,确定要让我干这么跨界的事情吗?之前自己虽然也安装过其他的rpm包,但我保证,我只是看说明书,跟着一路弄下来的.并且之后对它可是有多远躲多远的.不过考虑到自己的title,我知道那不应该是我关心的事情.那么问题来了,什么是rpm呢?

什么是RPM

RPM（RPM软件包管理器）
RPM^ ^ 是Red-Hat Package Manager（RPM软件包管理器）的缩写，这一文件格式名称虽然打上了RedHat的标志，但是其原始设计理念是开放式的，现在包括OpenLinux、SuSE.以及Turbo Linux等Linux的分发版本都有采用，可以算是公认的行业标准了。
看到了rpm是什么,我们就来了解一下RPM相关的命令
本来准备直接 rpm -help让大家看看相关参数的,但是考虑到内容太多,感兴趣的自行点击.这里放几个常用的命令.

1
2
3
4
5
6

# rpm 安装(后面的.rpm为你需要安装的rpm包)
rpm -ivh autoinstall.rpm
# 查看是否安装了某个rpm,注意后面的名称可以是安装的服务的部分名称
rpm -qa | grep autoinstall
# rpm 卸载.(后面的名称即上面查看服务里的服务名称)
rpm -e autoinstall-1.0.0.dev33-1.noarch

至此,基本的rpm基础已经了解到了.那么关键的问题来了,如何制作RPM

如何制作RPM

把制作RPM,道上传闻有多种方式,我自己测过的有两种

1
2
3
4

#第一种
python setup.py bdist_rpm
#第二种
rpmbuild -bb autoinstall.spec

注意:无论上述那种都需要setup.py及setup.cfg文件,描述相关的软件信息.
我自己使用的是第二种rpmbuild,

• 首先安装

1

yum install rpm-build

• 文件setup.py

1
2
3
4
5
6
7
8
9
10
11
12
13

import setuptools

# In python < 2.7.4, a lazy loading of package `pbr` will break
# setuptools if some other modules registered functions in `atexit`.
# solution from: http://bugs.python.org/issue15881#msg170215
try:
    import multiprocessing  # noqa
except ImportError:
    pass

setuptools.setup(
    setup_requires=['pbr'],
    pbr=True)

• 文件setup.cfg,想了解更多,请点击

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

[metadata]
name = autoinstall
version = 1.0
summary = autoinstall
author = Yannis
author-email = openstack-dev@lists.openstack.org
home-page = http://www.openstack.org/
classifier =
    Environment :: TusCloud
    Intended Audience :: Information Technology
    Intended Audience :: System Administrators
    License :: OSI Approved :: Apache Software License
    Operating System :: POSIX :: Linux
    Programming Language :: Python
    Programming Language :: Python :: 2
    Programming Language :: Python :: 2.7

[files]
packages =
    autoinstall

[pbr]
autodoc_index_modules = True

[build_sphinx]
all_files = 1
build-dir = doc/build
source-dir = doc/source

[egg_info]
tag_build =
tag_date = 0
tag_svn_revision = 0

[wheel]
universal = 1

• 使用rpm安装不可缺少的spec文件,想了解更多spec,请点击

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58

%if 0%{?rhel} && 0%{?rhel} <= 6
%{!?__python2: %global __python2 /usr/bin/python2}
%{!?python2_sitearch: %global python2_sitearch %(%{__python2} -c "from distutils.sysconfig import get_python_lib; print(get_python_lib(1))")}
%{!?python2_sitelib: %global python2_sitelib %(%{__python2} -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())")}
%else
%global __python2 /usr/bin/python
%endif

%define name autoinstall
%define version 1.0
%define unmangled_version 1.0
%define unmangled_version 1.0
%define release 1
Summary: auto install scripts for tusCloud
Name: %{name}
Version: %{version}
Release: %{release}
Source0: %{name}-%{unmangled_version}.tar.gz
License: UNKNOWN
Group: Development/Libraries
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-buildroot
Prefix: %{_prefix}
BuildArch: noarch
Vendor: UNKNOWN <UNKNOWN>
Provides: provide-files

%description
UNKNOWN

%prep
%setup -n %{name}-%{unmangled_version} -n %{name}-%{unmangled_version}

%build
%{__python2} setup.py build

%install
%{__python2} setup.py install -O1 --skip-build --root=$RPM_BUILD_ROOT
mkdir -p %{buildroot}%{_sysconfdir}/%{name}/
mkdir -p %{buildroot}%{_bindir}/
mkdir -p %{buildroot}/var/lib/autoinstall
mkdir -p %{buildroot}/var/log/autoinstall
mv %{name}/initconfig.yaml %{buildroot}%{_sysconfdir}/%{name}/
touch %{buildroot}/var/log/autoinstall/auto_install.log
touch %{buildroot}%{_sysconfdir}/%{name}/exec.txt

install -p -D -m 755 %{_builddir}/%{name}-%{version}/bin/* %{buildroot}%{_bindir}/

%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr(-,root,root)
%{python_sitelib}/autoinstall*
%config(noreplace) %attr(-,root,root) %{_sysconfdir}/%{name}/
%{_bindir}/*
/var/log/autoinstall
/var/lib/autoinstall

• 必须要有的requirements.txt(因为缺少这个文件遇到过问题)

1
2
3
4
5
6
7
8
9
10

# The order of packages is significant, because pip processes them in the order
# of appearance. Changing the order has an impact on the overall integration
# process, which may cause wedges in the gate later.

pbr>=1.3,<2.0
requests
datetime
bs4
PyYAML
abc

• 描述文件PKG-INFO

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

Metadata-Version: 1.1
Name: autoinstall
Version: 1.0
Summary: autoinstall
Home-page: http://www.openstack.org/
Author: Yannis
Author-email: openstack-dev@lists.openstack.org
License: UNKNOWN
Description: False
Platform: UNKNOWN
Classifier: Environment :: TusCloud
Classifier: Intended Audience :: Information Technology
Classifier: Intended Audience :: System Administrators
Classifier: License :: OSI Approved :: Apache Software License
Classifier: Operating System :: POSIX :: Linux
Classifier: Programming Language :: Python
Classifier: Programming Language :: Python :: 2
Classifier: Programming Language :: Python :: 2.7

• 整体的文件夹结构

至此就可以欢快的进行打包了.执行

1

rpmbuild -bb autoinstall.spec

以上命令运行成功后会在当前用户目录下生成rpmbuild目录，该目录会包含以下子目录

–BUILD #编译之前，如解压包后存放的路径
–BUILDROOT #编译后存放的路径
–RPMS #打包完成后rpm包存放的路径
–SOURCES #源包所放置的路径
–SPECS #spec文档放置的路径
–SPRMS #源码rpm包放置的路径

• 执行安装

  1	rpm -ivh autoinstall.rpm

  安装成功后,即可直接执行相关命令了.

必要条件

• 具体的软件对应的文件在autoinstall下的autoinstall下,目前感觉应该名称一致
• 必须有个bin目录,存放需放置至/usr/bin下的文件
• requirements.txt
• PKG-INFO
• setup.cfg
• setup.py
• *.spec
• *.tar.gz

  坑坑不息

1. Python文件路径,在Python内使用相对路径,由于在做编排文件的时候调整了目录结构,如上图,原本仅有一层的autoinstall文件夹,后面在制作spec的时候,要求必须要有一个bin目录,所以又加了一层文件夹.但加完之后,发现路径找不到了.后,修改项目内关于其他文件的引用为绝对路径;坑深度 ****
2. 缺少PKG-INFO文件.之前未接触过相关东西,直接参照其他项目.其他项目没有该文件正常能编译,但自己制作的怎么也不成功.后来使用了python setup.py bdist_rpm可以正常打包,只是打包的包名及其他的格式与要求不符,就未采用.不过把这种方式对应的tar.gz包,放到环境上,执行rpmbuild打包,竟然正常.比对发现,我的项目内缺少了PKG-INFO文件.copy该文件,重新执行,就可以打包了;坑深度 *****
3. bin内的autoinstall调用的主文件与外层文件夹名称一致,造成无法正确获取.最好要修改主文件的名称,不要跟文件夹名称一致;坑深度 *****
4. 当所有安装在测试环境成功后,执行命令,尽然发现对应代码引用一直为我本地的路径.百思不得其解.后来意外发现在/usr/bin下除了有个autoinstall的文件外,还有一个autoinstall.pyc的文件.删除.pyc的文件,执行即可;坑深度 *****
5. 在spec内有一个%{python_sitelib}获取的是本地python的路径,造成在ubuntu下不能正确在rpmbuild的路径下找到python路径,不过在centos下正常;坑深度 *****

   附录

   rpmbuild

   rpmbuild
   -ba 既生成src.rpm又生成二进制rpm
   -bs 只生成src的rpm
   -bb 只生二进制的rpm
   -bp 执行到pre
   -bc 执行到 build段
   -bi 执行install段
   -bl 检测有文件没包含

rpm打包中的setup.cfg解析

setup说明

主要的安装包为setuptools,setuptools 是一组由PEAK(Python Enterprise Application Kit)开发的 Python 的 distutils 工具的增强工具，可以让程序员更方便的创建和发布 Python的egg 包，特别是那些对其它包具有依赖性的状况。类似Java里面的ant，maven。比如下载所需要的包,打包，发布，单元测试等。
在Linux下的安装命令

1

sudo apt-get install python-setuptools

setup.py说明

setup.py其实是python工具包distutils的配置文件，setuptools就是基于distutils来做的。 在setup.py中通过setup函数来配置打包信息。首先要引入setuptools的函数setup。setuptools的setup其实就是distutils的setup函数，填写setup.py为以下内容：

1
2
3
4
5
6
7
8
9
10
11
12
13

import setuptools

# In python < 2.7.4, a lazy loading of package `pbr` will break
# setuptools if some other modules registered functions in `atexit`.
# solution from: http://bugs.python.org/issue15881#msg170215
try:
    import multiprocessing  # noqa
except ImportError:
    pass

setuptools.setup(
    setup_requires=['pbr'],
    pbr=True)

详细setup的说明参见链接

setup.cfg说明

setup.cfg提供一种方式，可以让包的开发者提供命令的默认选项，同时为用户提供修改的机会。对setup.cfg的解析，是在setup.py之后，在命令行执行前。

符合Distutils2的setup.cfg有些不同。包含一些sections：
1、global
定义Distutils2的全局选项，可能包含commands，compilers，setup_hook（定义脚本，在setup.cfg被读取后执行，可以修改setup.cfg的配置，pbr就用到了这个）
2、metadata

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

[metadata]
name = autoinstall
version = 1.0
summary = autoinstall
author = Yannis
author-email = openstack-dev@lists.openstack.org
home-page = http://www.openstack.org/
classifier =
    Environment :: TusCloud
    Intended Audience :: Information Technology
    Intended Audience :: System Administrators
    License :: OSI Approved :: Apache Software License
    Operating System :: POSIX :: Linux
    Programming Language :: Python
    Programming Language :: Python :: 2
    Programming Language :: Python :: 2.7

3、files

1
2
3
4

[files]
packages =
    autoinstall

4、pbr

1
2

[pbr]
autodoc_index_modules = True

pbr段落控制pbr相关的参数以及行为

• autodoct_tree_index_modules 是一个布尔型参数，描述pbr是否应该为sphinx-apidoc中的模块自动产生索引。默认的，setup.py排除在外。可以在autodoc_tree-excludes的设置中设定一系列被排除在外的模块。参考sphinx-apidoc man page 获取更多帮助信息。

• autodoc_index_modules是一个布尔型参数,控制pbr是否自己为项目的python模块产生文档。默认的，所以找到的python模块包含在内；他们有些被autodoc_exclude_modules排除掉了。这个排除文件模块列表可以包含fnmatch 风格的设置(例如myapp.tests.*) 

当使用autodoc_tree_excludes 或者autodoc_index_modules。你也需要在sphinx的配置文件中设置exclude_patterns(一般在项目中的 /doc/source/conf.py找到)。否则sphinx将会告知文档不在toctree中。当warnerrors=True开启后这个也需要为真。参考Sphinx build configuration file 文档获取更多如何配置sphinx.
5 其它参数,由于基本参见openStack的编排文件,很多还不是很清楚.待后续补充

1
2
3
4
5
6
7
8
9
10
11
12

[build_sphinx]
all_files = 1
build-dir = doc/build
source-dir = doc/source

[egg_info]
tag_build =
tag_date = 0
tag_svn_revision = 0

[wheel]
universal = 1

Setuptools

上面的setup.py和setup.cfg都是遵循python标准库中的Distutils，而setuptools工具针对Python官方的distutils做了很多针对性的功能增强，比如依赖检查，动态扩展等。很多高级功能我就不详述了，自己也没有用过，等用的时候再作补充。详情可参见这里。

setuptools相对distutils，增强的关键字：

extras_require：当前包的高级/额外特性需要依赖的分发包。
entry_points：这个很经典。见下面的讲解。
pbr会自动寻找 requirements.txt 进行安装

PBR

pbr是setuptools的辅助工具，最初是为OpenStack开发(https://launchpad.net/pbr)，基于d2to1。
A library for managing setuptools packaging needs in a consistent manner.

pbr会读取和过滤setup.cfg中的数据，然后将解析后的数据提供给setup.py作为参数。包含如下功能：
1、从git中获取Version、AUTHORS and ChangeLog信息
2、Sphinx Autodoc。pbr会扫描project，找到所有模块，生成stub files
3、Requirements。pbr会读取requirements.txt，生成setup函数需要的install_requires/tests_require/dependency_links

这里需要注意，在requirements.txt文件的头部可以使用：–index https://pypi.python.org/simple/，这一行把一个抽象的依赖声明如 requests==1.2.0 转变为一个具体的依赖声明 requests 1.2.0 from pypi.python.org/simple/
4、long_description。从README.rst, README.txt or README file中生成long_description参数

引用 链接

rpm包的spec解析

SPEC文件的一些语法：

.spec中的条件判断语句有两种：

1、if结构

1
2
3
4
5

引用
%if %{str}
%else
       动作
%endif

其中%{str}是条件，0为假，非0为真。
2、?:结构

1
2

引用
%{?变量:动作1}动作2

其中{}用于控制范围，而“？”号和“：”号是分割符，如果要判断条件是非的情况，可以在“？”号前加“！”号。
此条件与前面的%if有点不同，其只判断变量是否定义，定义了就为真，否则就为假，即使变量定义为0，也为真，并运行后面的语句。

spec文件的一些定义：

1
2
3
4
5
6
7
8
9
10
11
12

Name:　　#软件包的名称
Version:　　#软件包的版本号
Release:　　#发布的序列
Epoch:　　#发布的序列
Summary:　　#摘要
Group:　　#组描述
License:　　发行许可证
Sources[0-n]:　　#打包的源码包
Patch0:  \*.patch      #补丁文件
BuildRequires:　　#打包时依赖的软件
Requires:　　#安装此rpm包时依赖的软件包
BuildRoot:　　#安装此软件的虚拟根目录

以上是描述性的元素，其中Epoch:Version:Release表示了rpm包的新旧，优先级依次降低，打出的rpm包也是以${package}-${Version}-${Release}命名。

spec文件主体内容：

spec文件中引用的一些宏变量主要定义在/usr/lib/rpm/macros中
主要有三个阶段：

• %pre
  #预处理阶段，解压缩软件包
• %setup 

  1 2 3 4 5 6 7 8 9 10 11 12 13

  %setup 不加任何选项，仅将软件包打开。 %setup -n newdir 将软件包解压在newdir目录。 %setup -c 解压缩之前先产生目录。 %setup -b num 将第num个source文件解压缩。 %setup -T 不使用default的解压缩操作。 %setup -T -b 0 将第0个源代码文件解压缩。 %setup -c -n newdir 指定目录名称newdir，并在此目录产生rpm套件。 %patch 最简单的补丁方式，自动指定patch level。 %patch0 -p0 打第1个补丁，利用当前相对路径名称 %pacth1 -p2 打第2个补丁，忽略补丁文件第一层目录 %patch 0 使用第0个补丁文件，相当于%patch ?p 0。 %patch -s 不显示打补丁时的信息。 %patch -T 将所有打补丁时产生的输出文件删除。

• %build 编译阶段

  1	%{__python2} setup.py build

• %install 将软件安装到虚拟根目录

  1 2 3 4 5 6 7 8 9 10 11

  %{__python2} setup.py install -O1 --skip-build --root=$RPM_BUILD_ROOT mkdir -p %{buildroot}%{_sysconfdir}/%{name}/ mkdir -p %{buildroot}%{_bindir}/ mkdir -p %{buildroot}/var/lib/autoinstall mkdir -p %{buildroot}/var/log/autoinstall mv %{name}/initconfig.yaml %{buildroot}%{_sysconfdir}/%{name}/ touch %{buildroot}/var/log/autoinstall/auto_install.log touch %{buildroot}%{_sysconfdir}/%{name}/exec.txt install -p -D -m 755 %{_builddir}/%{name}-%{version}/bin/* %{buildroot}%{_bindir}/

  常用命令：

  1 2	make DESTDIR=$RPM_BUILD_ROOT install install [options] src ${RPM_BUILD_ROOT}/${dst} #安装配置文件至指定目录,相当于cp建立连接关系等。-

• %clean
  清理一些临时文件，或是生产中不需要的文件
• %files [name]
  文件和目录的归档，rpm包真正包含的内容，$name 与package name对应，一个package生成一个rpm包,名字${name}-￥{version}-${release}.rpm。若没有name，则即是spec Name项。
  files是相对路径，应用宏或变量表示相对路径：
  如果描述为目录，表示目录中除%exclude外的所有文件。
• %defattr (-,root,root) 指定包装文件的属性，分别是(mode,owner,group)，-表示默认值，对文本文件是0644，可执行文件是0755
• %changelog 变更日志
  一般会把git log记录输入，openstack文件中记录的日志：

  1 2	git rev-parse --abbrev-ref HEAD >> *.spec git log --pretty=oneline --abbrev-commit | head -n +1 >> *.spec

   #生成patch的命令

  1	diff -Naur path/to/A_Project  path/to/B_Project > Project.patch （A是原始项目）

  或者利用 git命令:

  1 2 3 4 5

  #new 是有更改的分支，old是没有更改的分支 git checkout new git format-patch -M old   生成：000-*.patch

  git打patch的命令：

1

git am 000-*.patch