目前的prebake流程如下：
PBStage-init:
此时ws-agent尚在获取流水线数据，PBStage0仅仅是等待其获取流水线定义文件(prebake.yml, bake.sh, finalize.yml)并尝试优先获取重要文件（如Dockerfile）。
ws-agent在获取完数据后还会继续获取与配置缓存。此时PBStage与ws-agent是异步的。
ws-agent获取数据可能随时结束，也可能随时出错，此时若不可恢复，则流水线生命周期终止。
PBStage-env:
ws-executor于主机运行，并开始根据environment配置环境。此时可能会拉取镜像，下载img文件或完成自定义环境准备。
特殊地，若environment=container且dockerfile被指定，容器便会开始构建，但只要其依赖流水线的其它文件（且尚未被获取到）则PBStage1暂停于此，等待ws-agent的“获取结束”信号。这样做可以保证其依赖获取(FROM)字段能被处理，节省时间。
PBStage-bootstrap:
ws-executor被复制到目标环境并以root运行。其会与主机ws-executor通信并获取固定的环境初始化程序（有点像cloud-init），设置一般用户Vulcan和必要的免密权限，根据环境不同可能会使用systemd-run0/sudo/直接使用root，用户也可以使用模板或手动编写的程序覆盖此行为。若条件不可满足（如尝试在busybox中使用普通用户，但没有包管理器也没有用户管理手段）则流水线终止于此。该阶段还可能设置其它必要的信息。prebake环境变量也于此时注入。
PBStage-earlysecurity:
ws-executor@host,ws-executor@env开始按照配置文件设置必要的早期安全环境，不过目前大概除了创建cgroups组外什么都不会发生，暂时可以忽略此步骤
PBStage-prehook:
ws-executor在目标环境于Vulcan（或用户指定的，或者root，下略）运行，开始预烘焙钩子。
PBStage-snapshot:
这是一个伪阶段，executor@host会按配置（在可能的环境）创建目标环境的快照。若不可实现则自动忽略，此时dependency阶段失败将按照配置从bootstrap或dependency自己重新开始。
目前我们尚不清楚容器/虚拟机快照能做到哪种地步。
我们尚未设计这个字段retry-policy，其应该在prebake.yml的dependency中。
PBStage-dependency:
理论上，若存在缓存，则ws-executor@host必须等待ws-agent结束，ws-agent发射结束信号时，其确保获取了文件，同步到共享分区并（按配置）检查过。
实际上可能会让依赖自行认领cache，不被认领的cache认为是bake cache从而允许忽略
ws-executor在目标环境于Vulcan，从custom_pre到system到language到custom完成依赖安装动作
用户可以配置可选的custom_*的清除脚本，使得custom+custom_clear是幂等的
（如果不配置且存在不幂等的风险，用户应当自行设置合理的retry-poicy）
PBStage-posthook:
开始后依赖钩子
PBStage-security:
ws-executor@host,ws-executor@env开始按照配置文件设置必要的安全环境，不过目前大概什么都不会发生，暂时可以忽略此步骤
PBStage-readyhook:
开始完成时钩子
PBStage-ready:
完成bake环境变量的注入，标识准备结束，ws-executor@env会告知ws-executor@host可以开始bake了。
这样编排好吗？可能有什么问题或遗漏吗？
