视频了解:
glance：为虚拟机的创建提供镜像的服务
glance的功能：使用户能够发现、注册、检索虚拟机的镜像，它提供一个能够查询虚拟机镜像元数据和检索真实镜像的REST API
REST API的体现就是一个URL，而在glance中通过一个URL地址来标识一个URL地址来唯一标识一个镜像的形式如:
<Glance Server Location>/v1/images/<ID>
<Glance Server Location>：glance服务按照的位置
/v1：使用v1版本，详见四
/images：请求的类型为镜像
/<ID>：一个uuid，在glance中全局唯一
v1版本的glance：
1、V1版本的实现，具有glance-api和glance-registry两个WSGI服务，二者都提供REST API,但需要强调的一点是：glance-registry提供的REST API是给glance-api使用的
2、Glance-API：1、接受api发来的请求，发给glance-registry。2、到后端的存储设备拉取镜像
3、Glance-Registry：1、连接数据库，从数据库中找到符合客户端标准的镜像，获取镜像的元数据，将镜像的信息返回给glance-api
v2版本的glance：
1、v2的实现就是将glance-registry集成到了glance-api内部，这么做的好处是减少了一个中间的处理环节。
2、Glance-API：接受api发来的请求直接去访问数据库，获取到镜像的元数据后去存储设备拉取镜像。
书籍笔记：
Glance体系结构（v1版本）：
1、Glance主要由glance-api与glance-registry两个服务组成。
2、glance-api 是进入Glance的入口，负责接收用户的RESTful请求，然后通过后台的Swift 等存储系统完成镜像的存储与获取。
3、Glance的Store模块实现了一个存储后台的框架，根据这个框架所提供的接口，实现了对各种不同后台存储系统的支持。
4、在Juno版本之前，Store模块的实现位于glance/store目录；Juno版本之后，Store模块作为一个独立的项目glance store被剥离出来 ,以便为更多的项目服务
5、glacne-registry也是一个 WSGI Server，不同的是，glance-registry处理的是与镜像元数据（这里的元数据是指保存在数据库中的关于镜像的一些信息）相关的RESTful请求。
6、glance-api接收到用户的RESTful请求后，如果该请求与元数据相关，则将其转发给glance-registry服务。然后glance-registry会解析请求的内容，并与数据库进行交互,存取或更新镜像的元数据，Glance的DB模块存储的仅仅是镜像的元数据。
v2版本的Glance中，glance-registry服务的内容被整合进了glance-api之中。
Glance源码结构分析：
1、Glance的核心代码位于glance目录
2、所有服务以及工具的执行脚本位于glance/cmd
3、glance-api、glance/registry分别对应GlanceAPI 和 Glance-registry
4、glance-api可以为镜像建立本地缓存，实现API服务节点的数量扩展，提供多个API节点为同一个镜像提供服务的效率（本地的Image Cache是镜像文件的完全复制，这种缓存机制对用户来说是透明的）。
5、用户可以通过配置文件/etc/glance/glance-cache.conf指定Cache文件存放的路径、本地能够用于Cache的存储空间等信息。
6、镜像缓存的实现位于glance/image_cache目录。
7、针对import、export等镜像操作，Glance引入Task的概念（针对镜像的异步操作，glance/async即是部分实现）
8、Glance釆用了责任链(Chain of Responsibility)的设计模式实现用户请求的处理流程。使系统可以在不影响客户端的情况下动态地重新组织链和分配责任。
9、glance.domain模块定义了一些基类或接口，glance.gateway.Gateway模块则是实现了责任链的建立。
10、Rally是一个用于性能测试的项目,glance/rally-jobs目录是一些用于Rally的文件或插件。
setup.cfg：
entry_points,中的命名空间“consolc_scripts”里，涵盖了Glance所提供的所有服务以及工具
其中的每一项都表示一个可执行的脚本，这些脚本在部署时会被安装，它们同时也是 Glance各项工作的入口。
1、glance-cache-*： 4 个对 Image Cache 进行管理的工具。
2、glance-manage：用于Glance数据库的管理。
3、glance-replicator：用于实现镜像的复制。
4、glance-scrubber：用于清理已经删除的Image。
5、glance-control： Glance 提供了 glance-api 和 glance-registry 两个WSGI Server.以及一 个glance-scrubber后台服务进程，这里的glance-control工具即是用于控制这3个服务进程。
6、glance-glare： Glare API 服务，目前正在开发中。
Glance API详细介绍：
Glance API主要提供镜像的管理功能。比如Image的导入/导出、镜像元数据的管理等。
目前Glance API共有v1和v2两个版本，v2版本整合了glance-registry服务的功能，并且采用责任链设计模式来实现了API的处理流程。
Image：
Image是Glance所管理的主要资源。如果从Image启动VM，该VM被删除后，Image依然存在，但是Image上不包含本次在该VM实例上的修改（因为Image只是给VM启动的模板）
对Image的描述：
1、id：唯一一个标识Image的UUID
2、name：Image的名字
3、owner：Image的拥有者
4、size：Image的字节大小
5、created_at、updated_at：表示Image的出生时间、最后一次被修改的时间
6、location：Image存储的位置
7、disk_format：Image本身的格式（比如raw、qcow2（用于Qemu）、vdi（用于Virtual Box）、vmdk（用于Vmware）等）
8、status：镜像的状态。（Glance负责管理Image的生命周期）
Image的各种状态：
1、queued：表面镜像ID已经被保留，但是镜像数据还没有上传
2、saving：表面此时镜像正在上传
3、active：是Image成功上传完毕后的状态，此时该Image完全可用
4、killed：表面上传时发生错误，此时Image完全不可用。（在v2中被废除，如果上传失败，状态码变为“queued”以便上传可以重试）
5、deleted：虽然此时Glance还保留Image的相关信息，但是该Image已不可用，在未 来某个时候会被glance-scrubber彻底删除。
6、pending_delete：和deleted类似，但是并不会删除Image，此时尚可恢复。
Task：
Task是针对Image的异步（Async）操作，具有的一些属性包括id、owner状态等。Glance同时也实现了统一的JSON格式的API来操作这些Task，比如创建、删除、查询状态等。
在一个Task运行过程中，我们不断查询它的状态。
1、pending：表示Task被创建，但未被执行
2、processing：表示Task正在被执行中。
3、success：表示Task正在执行中。
4、failure：表示Task由于某种原因未能成功结束。
Task和Image的操作完全是两个概念：
1、首先它们都是不同的API资源；
2、其次，Task是异步的操作，是对Image操作的封装，目前只对clone、imports export 3种操作进行了封装；
3、最后，Task一旦创建，可以不断查询这个它的状态，在一次操作比如import之后，Task可以消亡，但是此时生成的Image依然存在。