ironic state information

参考：

http://blog.csdn.net/zhonglinzhang/article/details/74202562

http://blog.csdn.net/wanghuiict/article/details/52757359

http://blog.csdn.net/dingdingwolf/article/details/47272913

状态

@ ENROLL: ironic知道节点存在，并没有进一步的action，一旦一个节点拥有driver和properties，通过manage API调用使节点过度到VERIFYING

@ VERIFYING: ironic验证是否可以通过分配的drivers（例如，电源状态管理）和证书管理节点

@ MANAGEABLE: 用driver和证书验证通过可以管理节点，电源power off可选的,从MANAGEABLE节点过度到

 

• MANAGEABLE(从CLEANING)通过clean API调用
• MANAGEABLE(从INSPECTING)通过inspect API调用
• AVAILABLE(从CLEANING)通过provide API调用

 

@ INSPECTING:根据硬件属性变更来更新硬件属性，来反应当前硬件的状态，失败则过度到INSPECTFAIL

 

@ CLEANING:清理以准备步入AVAILABLE,正确成功的CLEANING包括任务：

 

• 擦除驱动器
• 固件完整性验证
• 验证节点传入属性是否与实际硬件配置匹配
• booting到一个长时间运行的deploy ramdisk

 

 

当一个节点为CLEANING状态，意味着节点执行带外清理步骤，或者准备环境（建立PXE配置文件， 配置DHCP等）来boot randisk

 

@ CLEANWAIT:与CLEANING不同是conductor等待boot ramdisk, 在带内清理步骤,处于CLEANWAIT状态的节点可以被abort API调用中断

 

@ AVAILABLE:处于AVAILABLE状态的是已经被清理，重新配置的，准备好的可以用来provisioned,处于AVALIABLE状态节点可以过度：

 

• ACTIVE(从DEPLOYING)通过active API调用
• MANABGEABLE通过manage API调用

@ DEPLOYING:主要包括一系列短任务：

 

• 设置适当的BIOS配置
• 驱动器分区，生成文件系统
• 创建一些子系统需要的附加资源（网络配置等）
  
  

@ DEPLOYWAIT:已经DEPLOYED的，不同的是conductor等待boot ramdisk，或执行部分需要带内运行的部署工作（例如：安装bootloader，当没有使用iscsi写image到disk）,处于DEPLOYWAIT状态的节点可以被deleted API调用中断

@ ACTIVE:一句话就是可以正常使用的了！

 

部署流程：

 

1. 部署物理机的请求通过 Nova API 进入Nova；
2. Nova Scheduler 根据请求参数中的信息（指定的镜像和硬件模板等）选择合适的物理节点；通过flavor中extra_spec（比如cpu_arch, baremetal:deploy_kerner_id, baremmetal:deploy_ramdisk_id）
3. Nova 创建一个 spawn 任务，并调用 Ironic API 部署物理节点，Ironic 将此次任务中所需要的硬件资源保留，并更新数据库；
4. Ironic 与 OpenStack 的其他服务交互，从 Glance 服务获取部署物理节点所需的镜像资源，并调用 Neutron 服务为物理机创建网路端口；
5. Ironic 开始部署物理节点，PXE driver 准备 tftp bootloader，IPMI driver 设置物理机启动模式并将机器上电；
6. 物理机启动后，通过 DHCP 获得 Ironic Conductor 的地址并尝试通过 tftp 协议从 Conductor 获取镜像，Conductor 将部署镜像部署到物理节点上后，通过 iSCSI 协议将物理节点的硬盘暴露出来，随后写入用户镜像，成功部署用户镜像后，物理节点的部署就完成了。