文章以ocata版本进行分析
cinder api 的创建和启动，和 nova api 类似，都是通过在 api-paste.ini 中定义 app ，然后将 app 加载之后，启动 wsgi 服务
走 keystone 验证的 cinder 服务，最后走 apiv3
由此， cinder api 的入口就找到了。
api 请求的 router ，指定了 cinder/api/v3/volumes.py:VolumeController 作为实现 volume 增删改查的控制器。其中包括了 create /delete/get 等方法。
以 create 方法举例，先取出 request 的 body 数据，然后对 body 中的数据进行验证，重组，然后调用 volume_api
这里的 volume_api 指的是 cinder/volume/api.py:create 方法还是针对数据进行进一步格式化，然后使用 taskflow ，完成复杂的 volume 的创建。这个taskflow工具的大致工作方式是，创建一个 flow ，然后再 flow 中添加task ，每一个 task 要实现一个 execute 方法，作为执行函数，然后按步骤执行 task ，每一个 task 必须在前一个 task 成功执行的前提下才能执行，并支持回滚，需要继承指定类，重写 execute 执行方法和 revert 回滚方法。
这里的 api_flow 使用了 linear_flow ，也就是线形顺序依次执行，回滚也是按照倒叙依次回滚， revert 回滚方法会接收到 execute 方法执行的结果作为参数，以便进行相应的回滚操作。
首先第一个 task 是： ExtractVolumeRequestTask
这个 task 主要是完成对数据的检查，权限的验证等等，最后返回的还是创建参数 dict ：
然后进入下一个 task ： QuotareserveTask 。
这个 task 主要是对 quota （配额）进行预展，保证创建的资源不会超过 quota 配额。
查看这个 task 下的 execute 方法：
先调用 QUOTAS 模块（ cinder/quotas.py ）的 limit_check 检查 values 参数中的 quota 是否满足条件，这里可以看到检查的是 per_volume_gigabytes 。这个 quota 的含义是每一个 volume 的最大容量上限。其他的 quota 项可以通过 cinder 命令查看：
通过 quota 验证之后，再进行预占资源：
还是调用 QUOTAS 模块中的方法，这里预占的资源是， volume ： 1 指占用 volume 一个， gigabytes ： size 指占用资源 size 。
QUOTAS.reserve 方法将要预占的资源项目写入到数据库中，对应的相关数据可以查看 mysql cinder 库中的 reservations 表：
这里的数据表示了每一次的资源预占情况，之后 满足条件的情况下 ，则预占资源会更新到实际的 quota_usages 表中（下图），然后将 reservations 中的数据逻辑删除（上图： deleted=1 ）
回到 task 中。
预占资源成功之后会返回对应的数据结果 :
如果失败，会调用 revert 方法：
可以看到这里会获取 reservations ，然后做 quota 的 rollback 。其他的 task 也是类似，不再赘述。
进入下一个 task:EntryCreateTask:
这个 task 的任务是生成 volume 对象，然后写入数据库：
再下一个 task 是： QuotaCommitTask ：这个 task 将占用的 quota （ reservations ） 更新到 正式的 quota 表中：
这时，数据验证和数据库方面的工作就完成了，接下来的工作就是下发创建 volume 的实际任务给 cinder volume ：
可以看到后续的 VolumeCastTask 包括 scheduler 和 volume ，一个是调度，一个是创建。
这个 task 的 execute 方法：
继续调用 cast_create_volume 方法：
这块根据传参决定是由 cinder scheduler 调度选择节点创建 volume 还是 指定 host 创建。
这里按照普通的步骤，从 scheduler 调度开始往下跟踪，因为最终还是会调用 volume_rpcapi.create_volume 的。
进入 cinder/scheduler/rpcapi.py ： create_volume ：
这里先创建一个 worker ，用来记录工作的开始。
然后向 scheduler 发送消息： create_volume
接收这个消息的是 cinder/scheduler/manager.py:create_volume:
这里有个装饰器，对应上面的 worker 。
方法调用了 create_volume.get_flow 方法，这个方法也是一个 taskflow 实现的工作流：
这个方法是 cinder scheduler 的工作流实现：
这个 flow 也是一个线性 flow ： linear flow ，里面添加了两个 task:ExtractSchedulerSpecTask 和 SchedulerCreateVolumeTask
ExtractSchedulerSpecTask ： 整合 volume 的数据
具体细看下面的 task
SchedulerCreateVolumeTask ：调用对应 driver ，进行创建 volume 的动作。
execute 方法，直接调用了 driver 的 scheduler_create_volume 方法：
这里的 self.driver_api 是在 schedulerManager 的 init 方法中初始化的
默认配置使用的是： cinder.scheduler.filter_scheduler.FilterScheduler
先调用 scheduler 方法，选择一个调度创建的存储后端 backend ，然后将这个后端信息更新到 volume 的数据库对象中，
这里有一步 post select populate filter properties ，好像是将此次调度到的存储节点保存，以确保当此次失败之后，重试操作不会再一次调度到这个节点上。
最后使用 rpc 发送创建消息，这里的 volume_rpcapi 是 cinder volume 的 rpc client ，这个 client 负责向 cinder volume 服务发送 create_volume 的消息，接受并处理此消息
的是 cinder/volume/manager.py ： create_volume 。跟踪此方法，还是使用了 taskflow 实现的
这个 flow 里添加的 task 包括
ExtractVolumeRefTask ：刷新数据库 volume 的数据
OnFailureRescheduleTask: 主要是 task 失败 revert 的相关处理
ExtractVolumeSpecTask: 针对创建的参数进行数据重组，例如从 snapshot 创建， clone 等
NotifyVolumeActionTask: 想对应的 host 发送 create.start 的 notifier
CreateVolumeFromSpecTask: 根据对应的 create_type ，调用对应的方法，比如：创建 raw 类型的 volume ，会调用对应 driver 的创建方法：
CreateVolumeOnFinishTask: 这一步根据上一步的创建结果，更新数据库的 volume 状态
接下来深入到 driver 的创建方法中：
以 lvm 为例， lvm 的 driver 为例。
在 cinder/volume/manager.py : VolumeManager 中，初始化了
跟踪代码到 LVMVolumeDriver 下的 create_volume 中：
这里使用了 self.vg, 这个 vg 是在哪里初始化的呢？
回到最初的 cinder service 的启动代码里： cinder/service.py
这里有个 self.manager.init_host 调用，这个 manager 也就是上面的 VolumeManager ，这里调用了 init_host 方法，那 VolumeManager 的 init_host 有哪些内容？
可以看到调用了 driver 的 check_for_setup_error()
这个方法的实现，在对应的 lvm driver 中：
在这里初始化了 self.vg 。
所以这个 self.vg 就跟踪到了 cinder/brick/local_dev/lvm.py 。
也就是说 cinder/volume/drivers/lvm.py 中的方法最终调用到 cinder/brick/local_dev/lvm.py
当前分析的 create_volume 如下：
可以看到调用了 lvcreate 命令，进行了最终的 volume 的创建