OpenStack Paste.ini详解(二)

接着OpenStack Paste.ini详解(一)，接下来就分析request被paste.ini处理的流程

WSGI server接收到URL形式的request时，这些request首先会被Paste模块按照配置文件paste.ini进行处理，其过程大致如下：

• composite：将request和application进行映射。然后将request转发到pipeline或app中，最终到达指定的application；
• pipeline：包含filter和app；
• filter：调用具体的中间件(MiddleWare)对request进行过滤处理；
• app：具体的application实现对request的操作；
  我们来逐个字段对文件api-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

对于osapi_volume，这里使用composite的分发机制：

• 实现xxx/xxx形式的API交给apiversions来处理；
• 实现xxx/v1(2/3)/xxx形式的API交给openstack_volume_api_v1(2/3)来处理；

其次，来看apiversions的实现机制：

[pipeline:apiversions]
pipeline = cors http_proxy_to_wsgi faultwrap osvolumeversionapp

[app:osvolumeversionapp]
paste.app_factory = cinder.api.versions:Versions.factory

这里使用pipeline字段实现cors、http_proxy_to_wsgi faultwrap对osvolumeversionapp的过滤操作，而osvolumeversionapp具体映射为application：ciner.api.versions:Versions.factory

再次，来看openstack_volume_api_v3(以此为例子说明v1/v2的实现)

[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

这里的composite字段实现了多个application的集合应用，openstack_volume_api_v3具体映射到的application为use = call:cinder.api.middleware.auth:pipeline_factory，pipeline_factory是这个application实现的具体方法，这个application对应了三个参数：noauth、keystone、keystone_nolimit。在这三个参数中，分别集成了多个filter，因为每个参数的application是最后一个字段，即apiv3、apiv3和apiv3。

由于openstack默认使用的是keystone认证，所以我们以参数keystone为例，实现参数keystone的application为：keystone = cors http_proxy_to_wsgi request_id faultwrap sizelimit osprofiler authtoken keystonecontext apiv3
在apiv3前面的都是它的过滤器，其实现过程也就是cors(http_proxy_to_wsgi(request_id(faultwrap(sizelimit(osprofiler(authtoken(keystonecontext(apiv3))))))))，具体的调用过程为apiv3->keystonecontext->authtoken->osprofiler ->sizelimit ->faultwrap ->request_id ->http_proxy_to_wsgi ->cors ，前面方法的执行结果作为后面方法的输入参数，最后得到的运行结果作为keystone的值。可以说明，noauth、keystone和keystone_nolimit的值都是这样得到的，作为application use = call:cinder.api.middleware.auth:pipeline_factory的输入值。

最后，分别来看其他application的实现：

[app:apiv3]
paste.app_factory = cinder.api.v3.router:APIRouter.factory

[filter:keystonecontext]
paste.filter_factory = cinder.api.middleware.auth:CinderKeystoneContext.factory

[filter:authtoken]
paste.filter_factory = keystonemiddleware.auth_token:filter_factory

[filter:osprofiler]
paste.filter_factory = osprofiler.web:WsgiMiddleware.factory

[filter:sizelimit]
paste.filter_factory = oslo_middleware.sizelimit:RequestBodySizeLimiter.factory

[filter:faultwrap]
paste.filter_factory = cinder.api.middleware.fault:FaultWrapper.factory

[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类型的都是过滤器，而apiv3作为最后实现的application都是app类型，接下来我们就可以到对应的类下面去看看具体每个中间件的代码实现了。通过分析我们可以发现，这些application主要是实现了一些身份认证和请求参数限制等验证性质的功能。
接下来就可以使用debug的方式或者print的方式来查看这个过程，至此对paste.ini的简单分析就暂时结束，接下来就是结合源码更加深入的分析。