openstack在创建虚机的过程中nova的每个服务都扮演了什么角色，以及它们是如何协作的？
nova组件的子服务
nova中的各个子服务介绍：
| 服务 | 说明 |
|---|---|
| nova-api | 接收并相应用户的请求，执行一些策略，并且发起一些流程，比如：启动一个虚机 |
| nova-conductor | 中间层，用于nova-compute和database之间的互动，消除了nova-compute服务对数据库的直接访问 |
| nova-scheduler | 从消息队列中获取一个虚机的请求，然后决定在哪个计算节点执行 |
| nova-compute | nova组件中最核心的服务，通过调用hypervisor API实现了虚机的管理功能。比如：虚机的创建，重启，关闭，删除等操作。 |
| nova-consoleauth | 为控制台代理提供用户的身份令牌。 |
| nova-vpcproxy | 提供了一个通过VNC连接正在运行的虚机的代理。 |
其中每个服务都有以下一个文件：
| 文件 | 作用 |
|---|---|
| api.py | 供其他组件进行调用 |
| rpcapi.py | RPC请求的封装，或者可以这样理解，RPC实现的client端 |
| manager.py | 服务的实现，RPC的server端 |
nova创建虚机的流程
创建虚机的流程图：
创建虚机流程如下:
- 通过Dashboard或者command-line获取用户凭据，然后通过RESTful API调用keystone进行身份验证；
- keystone对用户凭据进行认证并且生成和发送auth-token信息，以便其它组件之间通过REST-call方式发送请求时使用auth-token信息；
- Dashboard或者command-line将‘launch instance’或者‘nova-boot’的请求转化为一个REST API请求，并且发送给nova-api；
- nova-api接收到这个请求后，向keystone发送请求验证auth-token和访问权限；
- keystone验证token是否有效，如果有效，更新auth的头部信息，包括角色和权限，并且返回；
- nova-api与数据库进行通讯；
- 对新建的虚拟机在数据库中初始化一条记录；
- nova-api向nova-scheduler发送RPC同步调用请求；
- nova-scheduler从消息队列中监听到该请求；
- nova-scheduler通过查询数据库计算资源的使用情况，并且通过调度算法，筛选出创建虚机使用的物理机；
- 返回更新后的该虚拟机对应的数据库的记录，此次主要更新虚机对应的物理机的信息；
- nova-scheduler向指定物理机的nova-compute发送创建虚机的RPC异步请求，这里指定的物理机指的是第10步中筛选出的物理机
- nova-compute从消息队列中监听到该请求；
- nova-compute向nova-conductor发送RPC同步调用，更新虚机的信息，比如：物理机ID和规格（内存，CPU，硬盘）等信息
- nova-condutor从消息队列中监听到该请求；
- nova-conudctor更新该虚机对应的数据库记录；
- nova-conductor向nova-compute发送RPC异步调用，发送内容包括该虚机的信息
- nova-compute从消息队列中监听到该请求，并且获取到该虚机的信息；
- nova-compute通过auth-token访问glance-api服务，通过镜像ID获取镜像的URI，然后从镜像存储服务器上下载该镜像；
- glance-api调用keystone验证auth-toker信息；
- 验证通过后，nova-compute获取镜像的元数据；
- nova-cmpute使用auth-toker访问Network API,给虚机分配和配置网络信息，例如：虚机的IP地址；
- quantum-server调用keystone验证auth-token;
- 验证通过后，nova-compute获取到网络信息；
- 同样的，nova-cmpute使用auth-toker访问Volume API，给虚机绑定云硬盘；
- cinder-api调用keystone验证auth-token
- nova-compute获取云硬盘信息；
- nova-compute生成Hypervisor驱动需要的数据，并且在Hypervisor上执行请求（通过libvirt或者API）
