问题背景
最近在研究openstack 服务的源代码，由于项目代码较多对其又不熟悉，刚开始就不知道从哪里开始入手分析。经过分析发现，在正式分析源码之前需要对python的wsgi、paste、routes和webob这几个模块有所了解才可以继续深入。在此，就我对paste的学习理解首先分享出来，其余模块接下来会娓娓道来。
研究对象
- Devstack 安装的OpenStack Pike版本的Cinder项目
研究过程
1、打开cinder项目下的paste.ini文件，如下所示：
[composite:osapi_volume]
use = call:cinder.api:root_app_factory
/: apiversions
/v1: openstack_volume_api_v1
/v2: openstack_volume_api_v2
/v3: openstack_volume_api_v3[composite:openstack_volume_api_v1]
use = call:cinder.api.middleware.auth:pipeline_factory
noauth = cors http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler noauth apiv1
keystone = cors http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler authtoken keystonecontext apiv1
keystone_nolimit = cors http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler authtoken keystonecontext apiv1[composite:openstack_volume_api_v2]
use = call:cinder.api.middleware.auth:pipeline_factory
noauth = cors http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler noauth apiv2
keystone = cors http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler authtoken keystonecontext apiv2
keystone_nolimit = cors http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler authtoken keystonecontext apiv2[composite:openstack_volume_api_v3]
use = call:cinder.api.middleware.auth:pipeline_factory
noauth = cors http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler noauth apiv3
keystone = cors http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler authtoken keystonecontext apiv3
keystone_nolimit = cors http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler authtoken keystonecontext apiv3[filter:request_id]
paste.filter_factory = oslo_middleware.request_id:RequestId.factory[filter:http_proxy_to_wsgi]
paste.filter_factory = oslo_middleware.http_proxy_to_wsgi:HTTPProxyToWSGI.factory[filter:cors]
paste.filter_factory = oslo_middleware.cors:filter_factory
oslo_config_project = cinder[filter:faultwrap]
paste.filter_factory = cinder.api.middleware.fault:FaultWrapper.factory[filter:osprofiler]
paste.filter_factory = osprofiler.web:WsgiMiddleware.factory[filter:noauth]
paste.filter_factory = cinder.api.middleware.auth:NoAuthMiddleware.factory[filter:sizelimit]
paste.filter_factory = oslo_middleware.sizelimit:RequestBodySizeLimiter.factory[app:apiv1]
paste.app_factory = cinder.api.v1.router:APIRouter.factory[app:apiv2]
paste.app_factory = cinder.api.v2.router:APIRouter.factory[app:apiv3]
paste.app_factory = cinder.api.v3.router:APIRouter.factory[pipeline:apiversions]
pipeline = cors http_proxy_to_wsgi faultwrap osvolumeversionapp[app:osvolumeversionapp]
paste.app_factory = cinder.api.versions:Versions.factory[filter:keystonecontext]
paste.filter_factory = cinder.api.middleware.auth:CinderKeystoneContext.factory[filter:authtoken]
paste.filter_factory = keystonemiddleware.auth_token:filter_factory
通过观察，我们很快就能发现这个文件的规律。都是以[type:name]的形式组织起来的，只不过type：name的名称和所包含的内容不太相同而已，接下来我们就对这个文件进行分析；
2、首先，我们需要明确几个概念：
- 针对composite、app、filter或者pipeline这种带有[]的，我们称之为section；
- composite：request进来后通过的第一个section，表示需要将一个http url request调度到一个或者多个application上；
- filter：是一个实现了过滤功能的中间件(将application进行进一步的封装)，用于过滤request和response；
- pipeline：最后一个名字对应的一定是app类型，非最后一个名字对应的是filter；
- app：一个app就是一个实现主要功能的具体application。所以，app必须是callable object类型，接受的参数(environ, start_response)，这是WSGI server交给application的符合WSGI规范的参数。
3、下面对各个section进行简单介绍
(1)[composite:name]
composite section定义了一种application，表示将请求调度定向到多个或者多种应用上。composite section可以是WSGI application的集合，可以包括其他application section中定义的application，常用用法：
[composite:osapi_volume]
use = call:cinder.api:root_app_factory
/: apiversions
/v1: openstack_volume_api_v1
/v2: openstack_volume_api_v2
/v3: openstack_volume_api_v3[composite:openstack_volume_api_v1]
use = call:cinder.api.middleware.auth:pipeline_factory
noauth = cors http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler noauth apiv1
keystone = cors http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler authtoken keystonecontext apiv1
keystone_nolimit = cors http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler authtoken keystonecontext apiv1[composite:openstack_volume_api_v2]
use = call:cinder.api.middleware.auth:pipeline_factory
noauth = cors http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler noauth apiv2
keystone = cors http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler authtoken keystonecontext apiv2
keystone_nolimit = cors http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler authtoken keystonecontext apiv2[composite:openstack_volume_api_v3]
use = call:cinder.api.middleware.auth:pipeline_factory
noauth = cors http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler noauth apiv3
keystone = cors http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler authtoken keystonecontext apiv3
keystone_nolimit = cors http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler authtoken keystonecontext apiv3
(2)[filter:name]
filter section定义了一个过滤器，过滤器接收一个application参数作为对象，并返回一个封装后的application；
(3)[filter-app:name]
filter-app section定义的也是过滤器，这个过滤器直接作用在application上面。filter-app section表明对某个application进行修饰，需要修饰的application通过参数next指明，例如：
[filter-app:myblog]
use = egg:Authentication
next = myblogapp
这个字段表明在正式调用myblogapp之前，会调用egg:Authentication进行用户验证，随后才会调用myblogapp进行处理，这也就实现了对myblogapp的修饰。
(4)[pipeline:name]
当使用多个filter的时候需要使用pipeline的方式，它需要提供一个key参数pipeline，后面的值是一个列表，最后以应用结尾。如下：
[pipeline:apiversions]
pipeline = cors http_proxy_to_wsgi faultwrap osvolumeversionapp
(5)[app:name]
app section直接或间接地定义了一个符合WSGI协议的应用application，有以下几种使用方法：
- 指向某个配置文件中的application
[app:app_1]
use = config:another_config_file.ini
- 指向某个URL
[app:app_2]
use = egg:App_2
- 指向从指定模块可调用的application
[app:app_3]
use = call:my.project:APP_3
- 指向其他已经定义或即将定义的section
[app:app_4]
use = app_4
- 直接指向具体的python代码(cinder中，应用的就是这种定义的section方式)
[app:app_5]
paste.app_factory = myapp.moudulename:app_factor
