近来刚接触OpenStack不久，遭遇一个小trouble，本文记录一下shooting过程。
在某一个基于OpenStack的云管产品上，本人将Controller（非HA配置）和所有Compute Node都挨个重启了一下（注意，这些机器本应是物理机，但因为资源有限，作为开发机，实际是用虚机进行的部署）之后，发现原先创建的2个instance一个都看不见了，还会报“Unable to retrieve server”的错误。这就是问题。
1. 尝试一：
跑到每个计算节点上运行 virsh list，结果啥也没有。当时以为从Hypervisor上就被删除了，也没在意，只是纳闷为何网页上新建instance的按钮为何一直是灰色。其实，这里思路已经错了。因为 virsh list 确实啥都看不到，原因是instance都没有起来呀。
2. 尝试二：
刚好我此时经过研究，弄明白了如何给OpenStack发API。于是，就给nova_api service发送HTTP request. 如下：
curl -X GET ${OS_COMPUTE_URL}/servers -H "Content-Type: application/json" -H "X-Auth-Token: ${TOKEN}" -s | python -m json.tool结果是，Nova认为那2个instance还在那里。不过俺的思路又错了，俺想的是，这是因为Nova的Mysql数据库里面没有把它们删除掉，所以现在应该去Mysql数据库里删除掉它们就好了。
3. 尝试三：
登上Controller的Mysql数据库，运行一些命令，比如像下面的：
mysql -u nova_api -p -e"use nova_api; show tables;" > /tmp/tables.txt然后我发现，这个所谓的nova_api数据库里几乎没什么table，即使有，里面也没什么有用的信息，怎么回事？
于是，我登上了计算节点的Mysql数据库，发现原来数据是存在这里的：
mysql -u nova -p -e"use nova; show tables;" > /tmp/nova_tables.txt值得注意的是：
1> 计算节点上的数据库叫做nova，里面有大量table和数据；而控制节点上的数据库叫做nova_api，里面信息较少；
2> 如何获得Mysql数据库密码的？去/etc/nova/nova.conf找。
于是，在nova数据库的 instance_actions_events 表中最后的记录的最后的column “details”里面发现了一点线索。details中记录的是log信息，看上去似乎keystone和neutron有点什么问题。
4. 尝试四：
因为在上一步骤中看到了neutron的字样，突然想看看控制节点上有哪些OpenStack的service. 结果在检查的过程中，发现有一个叫做 neutron-server 的service虽然是loaded的，但却是 Failed 的状态。于是重启了一下，再检查该service状态：
systemctl status neutron-server发现此时状态终于变成绿色的active了。再回头去网页上看，发现原先丢失的instance都恢复出来了，也可以继续创建新的instance了。此时又去各个compute节点上执行 virsh list，也能看见insance啦（只要running的就能显示出来）。
原来，root cause就是在所有节点（虚拟的计算节点和控制节点）重启之后，控制节点上的neutron-server服务挂了。这似乎也说明了neutron不那么稳定。
这次trouble shooting本身最终的解决方案比较boring，只是启动一个Fail掉的进程。但是在整个过程中，还是学到了不少东西。
