二、nova-api中app加载过程分析
目录结构如下：
上面介绍了nova-api发布所用到的一些lib库，有了上面的基础知识，再来分析nova-api的发布流程，就比较轻松了。nova-api可以提供多种api服务：ec2, osapi_compute, osapi_volume, metadata。可以通过配置项enabled_apis来设置启动哪些服务，默认情况下，四种服务都是启动的。从nova-api的可执行脚本中，可以看出每个nova-api服务都是通过nova.service.WSGIService来管理的：
class WSGIService(object): def __init__(self, name, loader=None): self.name = name self.manager = self._get_manager() self.loader = loader or wsgi.Loader() self.app = self.loader.load_app(name) self.host = getattr(FLAGS, ‘%s_listen‘ % name, "0.0.0.0") self.port = getattr(FLAGS, ‘%s_listen_port‘ % name, 0) self.workers = getattr(FLAGS, ‘%s_workers‘ % name, None) self.server = wsgi.Server(name, #这里通过eventlet来启动服务 self.app, host=self.host, port=self.port) def start(self): if self.manager: self.manager.init_host() self.server.start() .......
从上可知，WSGIService使用self.app = self.loader.load_app(name)来加载wsgi app，app加载完成后，使用nova.wsgi.Server来发布服务。Server首先用指定ip和port实例化一个监听socket，并使用wsgi.server以协程的方式来发布socket，并将监听到的http请求交给app处理。下面我们主要来分析处理HTTP请求的wsgi app是如何构建的，对于每一个请求，它是如何根据url和请求方法将请求分发到具体的具体函数处理的。
1、 composite:osapi_compute
上个语句self.loader.load_app(name)中的loader是nova.wsgi.Loader的实例。Loader.load_app(name)执行下面指令，使用deploy来加载wsgi app：
deploy.loadapp("config:%s" % self.config_path, name=name)
self.config_path为api-paste.ini文件路径，一般为/etc/nova/api-paste.ini。name为ec2, osapi_compute, osapi_volume, metadata之一，根据指定的name不同来加载不同的wsgi app。下面以name=“osapi_compute”时，加载提供openstack compute API服务的wsgi app作为具体分析。osapi_compute的配置如下
[composite:osapi_compute] use = call:nova.api.openstack.urlmap:urlmap_factory /: oscomputeversions /v2: openstack_compute_api_v2
osapi_compute是调用urlmap_factory函数返回的一个nova.api.openstack.urlmap.URLMap实例，nova.api.openstack.urlmap.URLMap继承paste.urlmap.URLMap，它提供了wsgi调用接口，所以该实例为wsgi app。但是函数nova.api.openstack.urlmap.urlmap_factory与paste.urlmap.urlmap_factory定义完全一样，不过由于它们所在的module不同，使得它们所用的URLMap分别为与它处于同一module的URLMap。paste.urlmap.URLMap实现的功能很简单：根据配置将url映射到特定wsgi app，并根据url的长短作一个优先级排序，url较长的将优先进行匹配。所以/v2将先于/进行匹配。URLMap在调用下层的wsgi app前，会更新SCRIPT_NAME和PATH_INFO。nova.api.openstack.urlmap.URLMap继承了paste.urlmap.URLMap，并写了一堆代码，其实只是为了实现对请求类型的判断，并设置environ[‘nova.best_content_type‘]：如果url的后缀名为json（如/xxxx.json），那么environ[‘nova.best_content_type‘]=“application/json”。如果url没有后缀名，那么将通过HTTP headers的content_type字段中mimetype判断。否则默认environ[‘nova.best_content_type‘]=“application/json”。
2、composite:openstack_compute_api_v2
经上面配置加载的osapi_compute为一个URLMap实例，wsgi server接受的HTTP请求将直接交给该实例处理。它将url为‘/v2‘的请求将交给openstack_compute_api_v2，url为‘/‘的请求交给oscomputerversions处理（它直接返回系统版本号）。其它的url请求，则返回NotFound。下面继续分析openstack_compute_api_v2，其配置如下：
[composite:openstack_compute_api_v2] use = call:nova.api.auth:pipeline_factory noauth = faultwrap sizelimit noauth ratelimit osapi_compute_app_v2 keystone = faultwrap sizelimit authtoken keystonecontext ratelimit osapi_compute_app_v2 keystone_nolimit = faultwrap sizelimit authtoken keystonecontext osapi_compute_app_v2
openstack_compute_api_v2是调用nova.api.auth.pipeline_factory()返回的wsgi app。pipeline_factory()根据配置项auth_strategy来加载不同的filter和最终的osapi_compute_app_v2。filter的大概配置如下：
[filter:faultwrap] paste.filter_factory = nova.api.openstack:FaultWrapper.factory
filter在nova中对应的是nova.wsgi.Middleware，它的定义如下：
class Middleware(Application): @classmethod def factory(cls, global_config, **local_config): def _factory(app): return cls(app, **local_config) return _factory def __init__(self, application): self.application = application def process_request(self, req): return None def process_response(self, response): return response @webob.dec.wsgify(RequestClass=Request) def __call__(self, req): response = self.process_request(req) if response: return response response = req.get_response(self.application) return self.process_response(response)
Middleware初始化接收一个wsgi app，在调用wsgi app之前，执行process_request()对请求进行预处理，判断请求是否交给传入的wsgi app，还是直接返回，或者修改些req再给传入的wsgi app处理。wsgi app返回的response再交给process_response()处理。例如，对于进行验证的逻辑，可以放在process_request中，如果验证通过则继续交给app处理，否则返回“Authentication required”。不过查看nova所有Mddlerware的编写，似乎都不用这种定义好的结构，而是把处理逻辑都放到__call__中，这样导致__call__变得复杂，代码不够整洁。当auth_strategy=“keystone”时，openstack_compute_api_v2=FaultWrapper-> RequestBodySizeLimiter-> auth_token-> NovaKeystoneContext-> RateLimitingMiddleware-> osapi_compute_app_v2。所以HTTP请求需要经过五个Middleware的处理，才能到达osapi_compute_app_v2。这五个Middleware分别完成：
1）异常捕获，防止服务内部处理异常导致wsgi server挂掉；
2）限制HTTP请求body大小，对于太大的body，将直接返回BadRequest；
3）对请求keystone对header中token id进行验证；
4）利用headers初始化一个nova.context.RequestContext实例，并赋给req.environ[‘nova.context‘]；
5）限制用户的访问速度。
注意以上filter是正序调用，逆序返回。即正序处理请求，逆序处理结果！
3、app:osapi_compute_app_v2
当HTTP请求经过上面五个Middlerware处理后，最终交给osapi_compute_app_v2，它是怎么继续处理呢？它的配置如下：
[app:osapi_compute_app_v2] paste.app_factory = nova.api.openstack.compute:APIRouter.factory
osapi_compute_app_v2是调用nova.api.openstack.compute.APIRouter.factory()返回的一个APIRouter实例。具体的请求会调用APIRouter的__call__函数。大致为，app加载主要是构造APIRouter，调用__init__函数，然后发散开去构造其他的Resource（或者Controller），走这一条线索；而请求的处理主要是调用APIRouter的__call__函数，然后匹配到相应的Controller，调用Controller的函数，走这一条线索。可以参考：
http://www.choudan.net/2013/07/30/OpenStack-API%E5%88%86%E6%9E%90(%E4%B8%80).html
先看看这部分的类关系，如下图所示：
3.1 首先分析APIRouter的构造
nova/api/openstack/__init__.py
APIRouter类：
def __init__(self, ext_mgr=None, init_only=None):
if ext_mgr is None:
if self.ExtensionManager:
ext_mgr = self.ExtensionManager()
else:
raise Exception(_("Must specify an ExtensionManager class"))
mapper = ProjectMapper()
self.resources = {}
self._setup_routes(mapper, ext_mgr, init_only)
self._setup_ext_routes(mapper, ext_mgr, init_only)
self._setup_extensions(ext_mgr)
super(APIRouter, self).__init__(mapper)
nova/wsgi.py
Router类：
def __init__(self, mapper):
self.map = mapper
self._router = routes.middleware.RoutesMiddleware(self._dispatch,
self.map)
APIRouter通过它的成员变量self.map(mapper)来建立和维护url与controller之间的映射，该mapper是nova.api.openstack.ProjectMapper的实例，它继承nova.api.openstack.APIMapper(routes.Mapper)。APIMapper将每个url的format限制为json或xml，对于其它扩展名的url将返回NotFound。ProjectMapper在每个请求url前面加上一个project_id，这样每个请求的url都需要带上用户所属的project id，所以一般请求的url为/v2/project_id/resources。
APIRouter通过self._setup_routes，self._setup_ext_routes，self._setup_extensions三个函数对mapper进行设置，下面会进行详细分析。其中使用到的ExtensionManager实例，该实例的构造可以参见：http://www.cnblogs.com/littlebugfish/p/4049853.html，此处不再详述，ExtensionManager中会有属性索引到扩展模块中对应的扩展类的实例。最后调用父类Router的__init__函数，其中self._router是routes.middleware.RoutesMiddleware的实例，使用self._dispatch和self.map来初始化的。
3.1.1 _setup_routes分析（核心Resource）
class APIRouter(nova.api.openstack.APIRouter):
ExtensionManager = extensions.ExtensionManager
def _setup_routes(self, mapper, ext_mgr):
self.resources[‘servers‘] = servers.create_resource(ext_mgr)
mapper.resource("server", "servers",
controller=self.resources[‘servers‘])
self.resources[‘ips‘] = ips.create_resource()
mapper.resource("ip", "ips", controller=self.resources[‘ips‘],
parent_resource=dict(member_name=‘server‘,
collection_name=‘servers‘))
.......
APIRouter通过调用routes.Mapper.resource()函数建立RESTFUL API，也可以通过routes.Mapper.connect()来建立url与controller的映射。如上所示，servers相关请求的controller设为servers.create_resource(ext_mgr)，该函数返回的是一个用nova.api.openstack.compute.servers.Controller()作为初始化参数的nova.api.openstack.wsgi.Resource实例，ips相关请求的controller设为由nova.api.openstack.ips.Controller()初始化的nova.api.openstack.wsgi.Resource实例。因为调用mapper.resource建立ips的url映射时，添加了一个parent_resource参数，使得请求ips相关api的url形式为/v2/project_id/servers/server_id/ips。对于limits、flavors、metadata等请求情况类似。
3.1.2 _setup_ext_routes分析（扩展Resource）
def _setup_ext_routes(self, mapper, ext_mgr, init_only):
for resource in ext_mgr.get_resources():
LOG.debug(_(‘Extended resource: %s‘),
resource.collection)
if init_only is not None and resource.collection not in init_only:
continue
inherits = None
if resource.inherits:
inherits = self.resources.get(resource.inherits)
if not resource.controller:
resource.controller = inherits.controller
wsgi_resource = wsgi.Resource(resource.controller,
inherits=inherits)
self.resources[resource.collection] = wsgi_resource
kargs = dict(
controller=wsgi_resource,
collection=resource.collection_actions,
member=resource.member_actions)
if resource.parent:
kargs[‘parent_resource‘] = resource.parent
mapper.resource(resource.collection, resource.collection, **kargs)
if resource.custom_routes_fn:
resource.custom_routes_fn(mapper, wsgi_resource)
首先会调用ExtensionManager的get_resources函数，该函数会遍历调用注册在ExtensionManager中的扩展类实例的get_resources函数（即nova/api/openstack/compute/contrib中每个文件里面对应文件名的类的get_resources函数），从而获取一个nova.api.openstack.ResourceExtension对象列表。接着将这些ResourceExtension对象的controller封装成nova.api.openstack.wsgi.Resource对象，最后使用mapper.resource函数构建URL到这些Resource的映射。
3.1.3 _setup_extensions分析（扩展Controller）
def _setup_extensions(self, ext_mgr):
for extension in ext_mgr.get_controller_extensions():
collection = extension.collection
controller = extension.controller
msg_format_dict = {‘collection‘: collection,
‘ext_name‘: extension.extension.name}
if collection not in self.resources:
LOG.warning(_(‘Extension %(ext_name)s: Cannot extend ‘
‘resource %(collection)s: No such resource‘),
msg_format_dict)
continue
LOG.debug(_(‘Extension %(ext_name)s extending resource: ‘
‘%(collection)s‘),
msg_format_dict)
resource = self.resources[collection]
resource.register_actions(controller)
resource.register_extensions(controller)
首先会调用ExtensionManager的get_controller_extensions函数，该函数会遍历调用注册在ExtensionManager中的扩展类实例的get_controller_extensions函数（即nova/api/openstack/compute/contrib中每个文件里面对应文件名的类的get_controller_extensions函数），从而获取一个nova.api.openstack. ControllerExtension对象列表。接着获取每个ControllerExtension中collection对应的nova.api.openstack.wsgi.Resource资源，向该资源注册ControllerExtension中controller的各个函数。