nova分析（3）—— nova-api
nova-api是nova对外提供Restful API的服务，Horizon、novaclient等均通过该api与nova进行通信。
nova其实对外提供了多个api服务，包括下面这些服务：
nova-api
nova-api-ec2
nova-api-metadata
nova-api-os-compute
其中，nova-api用于启动其他三个服务。下面逐个分析下。
nova-api
入口在 nova.cmd.api:main ，主要是基于WSGI、PasteDeploy、Webob、Routes等框架实现Restful API：
launcher = service.process_launcher() for api in CONF.enabled_apis: should_use_ssl = api in CONF.enabled_ssl_apis if api == 'ec2': server = service.WSGIService(api, use_ssl=should_use_ssl, max_url_len=16384) else: server = service.WSGIService(api, use_ssl=should_use_ssl) launcher.launch_service(server, workers=server.workers or 1) launcher.wait()
对每一个enabled_api，都会创建一个WSGIService，然后调用launch_service:
def _start_child(self, wrap): if len(wrap.forktimes) > wrap.workers: # Limit ourselves to one process a second (over the period of # number of workers * 1 second). This will allow workers to # start up quickly but ensure we don't fork off children that # die instantly too quickly. if time.time() - wrap.forktimes[0] < wrap.workers: LOG.info(_LI('Forking too fast, sleeping')) time.sleep(1) wrap.forktimes.pop(0) wrap.forktimes.append(time.time()) pid = os.fork() if pid == 0: # create a green thread to run child # 实际上最终调用的service的start/wait方法 launcher = self._child_process(wrap.service) while True: self._child_process_handle_signal() status, signo = self._child_wait_for_exit_or_signal(launcher) if not _is_sighup_and_daemon(signo): break launcher.restart() os._exit(status) LOG.info(_LI('Started child %d'), pid) wrap.children.add(pid) self.children[pid] = wrap return pid def launch_service(self, service, workers=1): wrap = ServiceWrapper(service, workers) LOG.info(_LI('Starting %d workers'), wrap.workers) while self.running and len(wrap.children) < wrap.workers: self._start_child(wrap)
既然每个服务都是 service.WSGIService ，那么WSGIService是如何初始化的呢
class WSGIService(object): """Provides ability to launch API from a 'paste' configuration.""" def __init__(self, name, loader=None, use_ssl=False, max_url_len=None): """Initialize, but do not start the WSGI server. :param name: The name of the WSGI server given to the loader. :param loader: Loads the WSGI application using the given name. :returns: None """ self.name = name # 根据self.name从配置文件中获取manager，若有则实例化对应的manager self.manager = self._get_manager() self.loader = loader or wsgi.Loader() # 通过paste.deploy加载app，对应配置文件为api-paste.ini self.app = self.loader.load_app(name) self.host = getattr(CONF, '%s_listen' % name, "0.0.0.0") self.port = getattr(CONF, '%s_listen_port' % name, 0) self.workers = (getattr(CONF, '%s_workers' % name, None) or processutils.get_worker_count()) if self.workers and self.workers < 1: worker_name = '%s_workers' % name msg = (_("%(worker_name)s value of %(workers)s is invalid, " "must be greater than 0") % {'worker_name': worker_name, 'workers': str(self.workers)}) raise exception.InvalidInput(msg) self.use_ssl = use_ssl self.server = wsgi.Server(name, self.app, host=self.host, port=self.port, use_ssl=self.use_ssl, max_url_len=max_url_len) # Pull back actual port used self.port = self.server.port self.backdoor_port = None
即从api-paste.ini加载app后，创建wsgi.Server
Paste Deployment是用于发现和配置WSGI appliaction和server的系统。对于WSGI application，用户提供一个单独的函数（loadapp），用于从配置文件或者python egg中加载WSGI application。因为WSGI application提供了唯一的单独的简单的访问入口，所以application不需要暴露application的内部的实现细节。首先了解几个基本的概念：
-
application: 应用，符合WSGI规范的可调用对象，接受参数（environ,start_response）, 调用start_response返回状态和消息头，返回结果作为消息体。
-
filter：过滤器，可调用对象，类型python中的装饰器，接受一个application对象作为参数，返回一个封装后的application。
-
app_factory:可调用对象，接受参数（global,**local_conf）,返回application对象
-
composite_factory: 可调用对象，接受参数（loader,global_config,**local_conf）, loader有几个方法, get_app用于获取wsgi_app, get_filter用于加载filter, 返回application对象。
-
filter_factory: 可调用对象，接受参数(global_config, **local_conf)，返回filter对象
以nova-api-os-compute为例看看这个配置文件是咋回事
# 这儿是整个api的入口，将不同版本转发到compiste处理 [composite:osapi_compute] use = call:nova.api.openstack.urlmap:urlmap_factory /: oscomputeversions /v1.1: openstack_compute_api_v2 /v2: openstack_compute_api_v2 /v3: openstack_compute_api_v3 # 比如v3版本api在这儿处理，在使用keystone配置时，要经过request_id faultwrap sizelimit authtoken keystonecontext这些filter的处理最后再交给osapi_compute_app_v3这个app来处理 # 注意这些filter的顺序：先把前n-1个filter逆序，然后逐个应用到app上 [composite:openstack_compute_api_v3] use = call:nova.api.auth:pipeline_factory_v3 noauth = request_id faultwrap sizelimit noauth_v3 osapi_compute_app_v3 keystone = request_id faultwrap sizelimit authtoken keystonecontext osapi_compute_app_v3 # filter部分定义了这个filter由哪个类来处理 [filter:request_id] paste.filter_factory = nova.openstack.common.middleware.request_id:RequestIdMiddleware.factory [filter:compute_req_id] paste.filter_factory = nova.api.compute_req_id:ComputeReqIdMiddleware.factory [filter:faultwrap] paste.filter_factory = nova.api.openstack:FaultWrapper.factory [filter:noauth] paste.filter_factory = nova.api.openstack.auth:NoAuthMiddleware.factory [filter:noauth_v3] paste.filter_factory = nova.api.openstack.auth:NoAuthMiddlewareV3.factory [filter:ratelimit] paste.filter_factory = nova.api.openstack.compute.limits:RateLimitingMiddleware.factory [filter:sizelimit] paste.filter_factory = nova.api.sizelimit:RequestBodySizeLimiter.factory # 这儿是v3的处理app，即APIRouterV3.factory [app:osapi_compute_app_v3] paste.app_factory = nova.api.openstack.compute:APIRouterV3.factory
APIRouterV3会加载setup.cfg中配置的extensions:
# 初始化api_extension_manager并加载所有的API_EXTENSION_NAMESPACE对应的extensions。 # 这儿加载的就是setup.cfg中配置的nova.api.v3.extensions部分，比如： # nova.api.v3.extensions = # access_ips = nova.api.openstack.compute.plugins.v3.access_ips:AccessIPs # admin_actions = nova.api.openstack.compute.plugins.v3.admin_actions:AdminActions # admin_password = nova.api.openstack.compute.plugins.v3.admin_password:AdminPassword # agents = nova.api.openstack.compute.plugins.v3.agents:Agents # ... # 当然如果有第三方的应用也声明了此namespace的extension，这里也会一并load进来。 # 其中的check_func为check_load_extension,其所作的工作主要包括： # a) 检测是否为相V3APIExtensionBase类型 # b) extension的黑白名单过滤和验证 self.api_extension_manager = stevedore.enabled.EnabledExtensionManager( namespace=self.API_EXTENSION_NAMESPACE, # 'nova.api.v3.extensions' check_func=_check_load_extension, invoke_on_load=True, invoke_kwds={"extension_info": self.loaded_extension_info}) mapper = PlainMapper() self.resources = {} # NOTE(cyeoh) Core API support is rewritten as extensions # but conceptually still have core if list(self.api_extension_manager): # NOTE(cyeoh): Stevedore raises an exception if there are # no plugins detected. I wonder if this is a bug. # Extensions define what resources they want to add through a get_resources function self.api_extension_manager.map(self._register_resources, mapper=mapper) # Extensions define what resources they want to add through # a get_controller_extensions function self.api_extension_manager.map(self._register_controllers) # 检测core extensions是否全部加载成功 missing_core_extensions = self.get_missing_core_extensions( self.loaded_extension_info.get_extensions().keys()) if not self.init_only and missing_core_extensions: LOG.critical(_("Missing core API extensions: %s"), missing_core_extensions) raise exception.CoreAPIMissing( missing_apis=missing_core_extensions)
以 servers = nova.api.openstack.compute.plugins.v3.servers:Servers 这个extension为例来看看加载过程是怎么样的。从前面的代码可以看到对每个extension，会调用get_resources和get_controller_extensions两个函数，其所作的工作分别为新增资源和扩展现有资源以添加action。
class Servers(extensions.V3APIExtensionBase): """Servers.""" name = "Servers" alias = "servers" version = 1 def get_resources(self): member_actions = {'action': 'POST'} collection_actions = {'detail': 'GET'} resources = [ extensions.ResourceExtension( 'servers', ServersController(extension_info=self.extension_info), member_name='server', collection_actions=collection_actions, member_actions=member_actions)] return resources def get_controller_extensions(self): return []
这里需要注意的是，V2 API中会区分Core API和Extension API。在V3 API中，所有的API均作为extension的形式提供。如V2 API中的servers是Core API，在V3 API中也是一个普通的extension，此extension会在get_resources方法中返回servers资源对象，而get_controller_extensions方法会返回空list。
而当disk_config等需要对servers资源扩展action时，其所需做的就是在get_controller_extensions中返回对servers资源的扩展：
class Disk_config(extensions.ExtensionDescriptor): """Disk Management Extension.""" name = "DiskConfig" alias = ALIAS namespace = XMLNS_DCF updated = "2011-09-27T00:00:00Z" def get_controller_extensions(self): servers_extension = extensions.ControllerExtension( self, 'servers', ServerDiskConfigController()) images_extension = extensions.ControllerExtension( self, 'images', ImageDiskConfigController()) return [servers_extension, images_extension]
最后再来看看V3版本API是如何避免各Extension之间代码耦合的
V3中，主要是利用了Stevedore避免了各Extension之间的代码耦合，从而避免了上述问题。
还是以当前对核心资源“虚拟机”的create方法扩展来看，在servers资源对应的Controller nova.api.openstack.compute.pulgins.v3.servers:ServersController中，将create作为了一个extension的namespace，并会在初始化时就load所有的extensions：
# Look for implementation of extension point of server creation self.create_extension_manager = \ stevedore.enabled.EnabledExtensionManager( namespace=self.EXTENSION_CREATE_NAMESPACE, #nova.api.v3.extensions.server.create check_func=_check_load_extension('server_create'), invoke_on_load=True, invoke_kwds={"extension_info": self.extension_info}, propagate_map_exceptions=True) if not list(self.create_extension_manager): LOG.debug("Did not find any server create extensions")
然后在create方法中，会通过map方法依次调用各个Extensions的server_create方法：
# Query extensions which want to manipulate the keyword # arguments. # NOTE(cyeoh): This is the hook that extensions use # to replace the extension specific code below. # When the extensions are ported this will also result # in some convenience function from this class being # moved to the extension if list(self.create_extension_manager): self.create_extension_manager.map(self._create_extension_point, server_dict, create_kwargs) def _create_extension_point(self, ext, server_dict, create_kwargs): handler = ext.obj LOG.debug("Running _create_extension_point for %s", ext.obj) handler.server_create(server_dict, create_kwargs)
在nova的setup.cfg中也配置了此namespace对应的所有的extensions，比如 nova.api.openstack.compute.plugins.v3.config_drive:ConfigDrive，其server_create方法如下所示，会更新ServersController:create方法中传入的create_kwargs字典：
def server_create(self, server_dict, create_kwargs): create_kwargs['config_drive'] = server_dict.get(ATTRIBUTE_NAME)
最终，ServersController:create方法会以如下方式调用内部API来创建VM，即直接使用被各个extensions更新过的create_kwargs，而不用感知其实际的内容。
(instances, resv_id) = self.compute_api.create(context, inst_type, image_uuid, display_name=name, display_description=name, metadata=server_dict.get('metadata', {}), admin_password=password, requested_networks=requested_networks, **create_kwargs)
由上面的分析可知，如上所有的所谓的Extension，最终均依赖的还是一个内部的API，如果此API本身不具有扩展性，那么如上所有的Extension，均只能在此内部API支持的功能的基础上进行发挥。 比如文中提到的创建VM的内部create API，此API的参数是固定的：
def create(self, context, instance_type, image_href, kernel_id=None, ramdisk_id=None, min_count=None, max_count=None, display_name=None, display_description=None, key_name=None, key_data=None, security_group=None, availability_zone=None, user_data=None, metadata=None, injected_files=None, admin_password=None, block_device_mapping=None, access_ip_v4=None, access_ip_v6=None, requested_networks=None, config_drive=None, auto_disk_config=None, scheduler_hints=None, legacy_bdm=True): """Provision instances, sending instance information to the scheduler. The scheduler will determine where the instance(s) go and will handle creating the DB entries. Returns a tuple of (instances, reservation_id) """
参考文档：
http://blog.csdn.net/cloudresearch/article/details/19050595
http://www.choudan.net/2013/07/30/OpenStack-API分析%28一%29.html
http://www.choudan.net/2013/07/31/OpenStack-API分析%28二%29.html