glance学习小结

接口

glance image-create

glanceclient

先由glanceclient在对应版本的shell里寻找action，找到后执行action

创建镜像先获取field，field获取前先get获取schemas，创建镜像时，在传入的参数中，仅保留在schema中记录的参数，然后调用glanceclient对应版本下的images拼接header设置参数等，最后将参数打包发到v2/images或v1/images创建镜像，文件创建的镜像，文件内容好像会通过标准输入传递过去

glance

v2/images逻辑在glance仓库中

创建镜像时，准备参数。先获取image factory和repo，这两个都是从gateway拿到。然后设置image对象的own属性，如果创建镜像没传入own属性，则设为project id

基于角色的权限校验

调policy的add_image方法，先进行基于角色的校验。以前好像/etc/项目名底下有policy文件，从policy文件读取校验规则，yoga版本的glance将规则放到仓库里，由glance调用oslo_policy的register_defaults注册角色规则。

从glance.policy.image读到的add_image行为的rule如下，然后调用enforcer的enforce方法进行校验，该方法封装在oslo_policy.policy.Enforcer.enforce方法中

add_image的check字符串如下，DocumentedRuleDefault的父类_BaseDefault会解析check_str加载为check规则，放到实例的_check里面

校验完add_image再校验镜像visibility

oslo_policy

glance的images api controller创建时空参数创建，对应的enforcer对象是oslo_policy.policy.Enforcer()

鉴权调用enforce方法，enforce方法先加载规则，规则会放到self.rules，加载的规则的to_check属性会在enforce用到

enforce中主要下图来进行鉴权

然后校验被某个projectid own的镜像数量，也enforce校验，调oslo_limit校验。应该调oslo_limit从keystone通过connection获取project最大限制镜像数量，从db获取project下现有镜像数量，然后enforce，没细看

创建镜像会校验是否admin，如果是admin则继续创建，如果不是admin会校验创建镜像传入的owner id是否为当前上下文的owner id，如果不是则终止镜像创建。创镜像通过调参数准备过程产生的imagefactory对象的new_image方法创建镜像

调用链很多，基本是层层调用，每层基本是一些校验的任务，最后会创建一个image的实例，然后层层返回

image_factory主要创建image实例，存储有image_repo实现，最终调glance.db.get_api.image_create创建镜像，这个api实际是glance.db.sqlalchemy.api，开始面向存储创建镜像

镜像文件上传通过调用接口/v2/images/{image-id}/file实现，调用是在创建镜像时glanceclient调用文件上传函数去上传

问题

project id从哪来

projectid从context来，context的projectid用来给imgae的owner字段赋值和校验等，那context的projectid从哪来？

glance api pipeline为keystone如下

context在context处创建

X-Identity-Status head可能从keystonemiddleware处赋值 没细看