本节书摘来自华章出版社《OpenStack实战指南》一 书中的第1章，第1.9节，作者：黄 凯 毛伟杰 顾骏杰 ，更多章节内容可以访问云栖社区“华章计算机”公众号查看。
1.9 OpenStack非核心项目介绍
1.9.1 Ironic项目介绍
Ironic为OpenStack的孵化项目之一，如果说OpenStack Nova管理的是虚拟机的生命周期，那么Ironic就是为了管理物理机的生命周期。它提供了一系列管理物理机的API接口，可以对“裸”操作系统的物理机进行管理，从物理机上架安装操作系统到物理机下架维修。我们可以像管理虚拟机一样地管理物理机，创建一个nova-compute物理节点不再需要人工部署，只需告诉Ironic，然后自动化地从镜像模板中加载操作系统到nova-compute安装完成即可。OpenStack管理虚拟机已经非常成熟，通过Nova我们可以快速自动化地创建虚拟机。但是在这之前需要搭建物理环境，需要人工地管理多台设备，OpenStack并没有提供物理环境的管理，我们依然需要解决这些基础环境的搭建问题，由此Ironic应运而生，解决物理机的添加、删除、电源管理、操作系统部署等问题。Ironic让OpenStack不仅停留在软件层面解决云计算问题。供应商可以对应自己的服务器开发Ironic插件。到目前为止，Ironic还处于实验阶段，它的目标是成为物理机管理的成熟解决方案。
提到Ironic项目，就不得不说Nova项目中的baremetal驱动。baremetal是Nova中的后端驱动，它与libvirt驱动、XenAPI驱动、VMware驱动一样，只不过它用来管理没有虚拟化的硬件，主要通过PXE和IPMI进行控制管理。这是一个可插拔式的插件，有了它，配置和管理服务器的硬件就可以使用Heat或salt-cloud来完成。baremetal并不能直接使用，还需要额外的环境准备，如要预先配置IPMI、配置DHCP服务、开启PXE等。Grizzy版本中已经含有baremetal驱动，但这仍然是实验性质。
在Nova中，baremetal的概念最早是由USC/ISI和NTT-Docomo提出的。USC/ISI是研究超算的教育机构，而NTT-Docomo是一家日本公司。物理机与虚拟机管理有许多类似的地方，但又有一些差异。最早设想为通过Nova统一管理，但在开发中，物理机与虚拟机的差异导致baremetal不得不从Nova中剥离，因为：
baremetal驱动有自己的数据库，在Nova一个项目中有两套数据库不合适。
物理机和虚拟机存储的数据信息不同，将两个有差异的实体放在同一个API中获取信息，在设计和使用上都比较别扭。
物理机和虚拟机的操作有差异，如discovery、hardware RAID configuration、firmware updates、burn-in等操作。物理机和虚拟机不能简单同质化。
社区经过讨论，决定将baremetal从Nova中剥离出来，命名为Ironic，主要用来实现对物理机的裸机管理。
下面来了解一下baremetal和Ironic在执行创建时的区别。
下面是通过PXE部署硬件物理机的步骤，如图1-26所示。
1）通过“nova boot”命令创建物理机，nova-api组件处理命令并将创建消息发送到消息队列中。
2）nova-scheduler接收到消息队列中的消息，判断是否为baremetal节点，如果是，则将调度后的主机节点信息及创建消息放入消息队列。
3）nova-compute监听消息队列发现创建消息并处理，调用baremetal驱动，通过实现spawn()方法来调用创建。
4）nova-compute查询baremetal数据库，获取节点信息。
5）Neutron负责设置网络相关信息。
6）nova-compute开始从Glance获取镜像。
7）nova-compute激活bootloader。
8）通过IPMI开启物理机电源。
9）通过PXE加载bootloader，暴露iSCSI，通过nova-baremetal-deploy-helper将镜像中的信息写入服务器。
10）重新启动服务器，加载操作系统。
11）更新数据库中物理机的信息状态。
12）更新Nova中的instance状态信息。
Ironic的部署流程与baremetal类似，如图1-27所示。
1）通过nova boot命令创建物理机，nova-api组件处理命令，并将创建消息发送到消息队列中。
2）nova-scheduler接收到消息队列中的消息，判断是否为baremetal节点，如果是，则将调度后的主机节点信息及创建消息放入消息队列。
3）nova-compute监听消息队列发现创建消息并处理，调用baremetal驱动，通过实现spawn()方法来调用创建。
4）nova-compute通过Ironic API获取硬件注册信息。
5）Neutron负责设置网络相关信息。
6）nova-compute开始从Glance获取镜像。
7）nova-compute通过Ironic API发送部署请求。
8）Ironic API与Ironic Conductor组件交互并激活bootloader。
9）通过IPMI开启物理机电源。
10）通过PXE加载bootloader，暴露iSCSI，通过nova-baremetal-deploy-helper将镜像中的信息写入服务器。
11）重新启动服务器，加载操作系统。
可以看到，Ironic对于硬件的异构问题主要是通过多个后端驱动的结合来解决的，如图1-28所示。
图1-28中的接口介绍如下。
Deploy Interface：实现把镜像部署到物理机中。
Power Interface：实现对物理机电源的管理。
Console Interface：实现通过硬件直接得到物理机Console（控制台）。
Vendor Interface：厂商自定义行为。
因为Ironic项目结构与大部分的OpenStack结构类似，所以是标准的OpenStack项目。目前，由于项目时间较短，因此并不是很成熟，但是从Ironic想解决的问题以及社区的支持来看，Ironic有希望在未来的几个版本内成为核心项目。
Ironic的安装
下面介绍一下Ironic的安装流程。
1）通过git clone获取最新的DevStack。获取链接地址为：
git://github.com/openstack-dev/devstack.git2）进入devstack目录修改localrc文件，添加如下内容：
# Enable Ironic API and Ironic Conductor
enable_service ir-api
enable_service ir-cond
# 使用Neutron代替nova-network，Ironic只支持Neutron
disable_service n-net
enable_service q-svc
enable_service q-agt
enable_service q-dhcp
enable_service q-l3
enable_service q-meta
enable_service neutron
enable_service q-lbaas
#按需要替换password
ADMIN_PASSWORD=password
MYSQL_PASSWORD=password
RABBIT_PASSWORD=password
SERVICE_PASSWORD=password3）运行stack.sh脚本。命令如下：
./stack.sh
接下来就是等待Ironic安装完成了。Ironic API地址为http://:6385。
1.9.2 Tempest项目介绍
Tempest为OpenStack的功能测试、集成测试项目，它被设计为可在各种不同项目中使用。在OpenStack核心项目中的单元测试代码中经常可以看到它的身影，在一些孵化项目中也会使用Tempest去测试。它可以验证代码的正确性，已经成为OpenStack项目中不可或缺的组成部分。
Tempest框架主要基于unittest2和nose来实现，它通过调用OpenStack API来测试功能，响应验证。测试的主要风格是按照pyunit来确定的，同时使用了testtools和testresources等多个测试工具库，可以说相当强大。
使用Tempest测试一个OpenStack环境，先要在各个OpenStack项目的配置文件中设置Tempest，在etc/文件夹下有一个tempest.conf.sample供参考使用。设置完成后，就可以直接通过“nosetests tempest”命令运行所有测试案例，也可以指定执行某个测试类库中的测试用例。
Tempest主要用于以下几个测试：
API测试
命令行测试
复杂场景测试
压力测试
第三方API测试
每一项都对应Tempest中的一个目录，每个目录中包含不同类型的测试。README.rst中记录着每个目录的作用，以及良好的测试示例及测试规则。
Tempest目录结构如下：
1）api：API的测试集。
2）cli：OpenStack的命令行工具测试集。
3）common：一些公共的工具类和函数。
4）scenario：对OpenStack的常用场景进行测试，包括基本的启动虚拟机、挂载volume和网络配置等。
5）services：Tempest实现的OpenStack API Client，主要是避免官方Client中含有Bug。
6）stress：压力测试集，利用多进程（multiprocessing）同时对OpenStack发起请求进行测试。
7）thirdparty：EC2等第三方兼容API测试集。
8）whitebox：白盒测试集。
1.?API测试
API测试是验证OpenStack的API。它不应该利用现有的OpenStack Python客户端实现，而是应该使用Tempest组件来实现。同时测试XML和JSON格式的请求。脱离官方客户端，可以让我们传递无效或非法的JSON和XML请求来查看这些请求结果，以验证API的健壮性。API测试应由项目开发者自己来完成，比如对项目进行功能性测试，或者使用某些单元测试框架。
2.?命令行测试
命令行测试使用OpenStack的命令行与OpenStack中的项目组件进行交互。命令行测试中，单元测试是有点困难的，因为不像服务器测试，它没有实现访问服务器的代码。Tempest运行于一个部署好的OpenStack环境，这样就合乎逻辑了，可以在服务器上直接执行命令行。
3.?复杂场景测试
复杂场景测试是通过各种复杂的OpenStack调用流程来测试OpenStack功能。它由一系列经典场景组成，需要多个OpenStack项目支持来完成这一系列测试。场景测试可以使用OpenStack Python客户端。
4.?压力测试
压力测试主要设计为测试OpenStack在高工作负载中运行时会出现什么问题。多种工具可以帮助检测OpenStack在高负载时出现的问题，如追溯日志。
5.?第三方API测试
许多OpenStack项目支持第三方API，如Nova支持EC2的API。Tempest验证第三方API，必须独立于OpenStack正常的测试流程。第三方API测试应该独立于OpenStack本身的逻辑。
