标签：manager 下一步 stack 记录 ons 基类 res width 数据库
上一篇博文将nova创建虚机的流程推进到了/compute/api.py中的create()函数，接下来就继续分析。
在分析之前简单介绍nova组件源码的架构。以conductor组件为例：
每个组件都会有这三个文件：api.py rpcapi.py manager.py。
下面是/compute/api.py中的create()函数。
/nova/compute/api::create()
总结：该函数的主要任务是对check policies、check quota、创建db记录，创建下一步中schedule所需要的调度规则信息filter_properties，将部分参数整合，
然后将创建请求发送到本类中的_create_instance()函数中，进行下一步处理。
/compute/api.py ::_create_instance()函数：
/nova/compute/api::create_instance()
总结：本函数的主要做的是获取镜像-id，检查网络，写入数据库等工作。
其中获取image-id的流程具有代表性，值得细细分析。
首先看glance架构：
glance-registry负责存储镜像的的具体信息，包括镜像的大小，格式，位置等。glance-backend负责存储真正的镜像。
当获取镜像时，首先会到glance-registry组件中获取将请求的镜像的数据，大小，格式，位置等，
然后到需要创建虚拟机时再去相应路径下载镜像作为虚机启动模板。
所以这里就会有一个请求镜像id的过程，从nova的以http请求的方式去调用glance-api，glance-api调用glance-registry查询数据库获得镜像的id。
代码流程如下：
session, image_id = self._get_session_and_image_id(context, id_or_uri)
return session.show(context, image_id,
include_locations=include_locations,
show_deleted=show_deleted)
这段代码的作用是通过glanceclient获取镜像文件信息。 在openstack中，不同组件之间的通信是通过RESTful API完成的，openstack的处理方式是为每个组件都包含了这样一个client，
它们都继承于HTTPClient这个基类，但做了一些个性化的封装，用于向各自的组件发送HTTP请求。具体到这里，nova需要和glace通信，以获取镜像文件的信息，所以需要声明了这样一个glanceclient。
代码self._get_session_and_image_id(context, id_or_uri) 的作用就是创建一个glaceclient对象，然后把这个对象封装入GlanceImageService类里，即返回值image_service。
然后调用该类下的show方法来获取镜像文件的信息。
摘录自：http://blog.csdn.net/qiuhan0314/article/details/43057591
可以看到这里有 image = self._client.call(context, version, ‘get‘, image_id) 这条调用函数就是restful 请求。
这样就通过restful api获取了镜像id。由于镜像不是主题讨论的重点，所以就不再话下。
_create_instance()函数中另一个比较重要的方法是 _provision_instances()，该函数实现了对创建虚机时的各项配额进行检查，并将虚机信息写入数据库。
instance = self.create_db_entry_for_new_instance(context, instance_type, boot_meta, instance, security_groups,
block_device_mapping, num_instances, i, shutdown_terminate, create_instance=False)
是向数据库中写入实例信息的函数
介绍完/compuet/api.py文件中的_create_instance()函数，目前推进的进度在这里。
标签：manager 下一步 stack 记录 ons 基类 res width 数据库
原文地址：http://www.cnblogs.com/goldsunshine/p/7800721.html
