Heat 支持查询 Autoscaling Group 虚拟机列表

标签：heat   autoscaling   instance   

引言

OpenStack Mailing List 中有这么一份邮件，内容如下：

[Openstack] heat autoscaling group instance relationships
I‘m trying to figure out how to determine all instances that were created as part of a given autoscaling group. I want to take a given autoscalinggroup and list all of its instances. So far I can‘t figure out how to dothis. The instances themselves have a tag called "AutoScalingGroupName"( mystack-MyServerGroup-f3r72ifsj2jq for example ) but the value of thatdoesn‘t seem to map to anything. A resource-show on the autoscaling groupdoesn‘t seem to show any identifier that maps to the autoscaling groupname.

Any ideas on how I can do this? Thanks!

该邮件大体的意思是，如何通过 Heat API 获取 Autoscaling Group 里的虚拟机列表。

一.需求

以 Heat 推荐的 Autoscaling Group 的 HOT 模板为例子，采用该模板创建 Stack 后，查询该 Stack 包含的 resource 如下，可知 asg 即为 AutoScalingGroup resource。
查询 Nova 发现 Autoscaling Group 旗下有两台虚拟机。继续查询 asg 详情，并无任何和虚拟机相关的信息，而事实上，Autoscaling Group 作为一群虚拟机的集合，用户非常希望能获取 Autoscaling Group 下虚拟机的数量，虚拟机的m名称等等。如果 Heat 未提供该 API，那么用户只能通过 Nova API 查询相关的虚拟机，这对用户来说，无疑增加了操作的复杂程度。

二.关于 nested_stack

在讲解 nested_stack 之前，先问读者一个问题：请问刚刚一共创建了多少个 stack？
一个！明明只有一个嘛！它的名字就叫 fuck ！......貌似言之有理，再查询数据库看看，奇葩出现了，咋跑出了四个 stack，而且四个 stack 的名字均以 fuck 开头，有着几分相似和某些规律。再看看 owner_id 和 id 的关系：
1. stack-list 查询到的 stack, 其 owner_id 均未 NULL。
2. nested_stack 的 owner_id 为父 stack 的 id。

这个四个 stack 的关系如下图所示




看，熟悉的虚拟机现身了。从上不难发现另外一条规律，nested_stack 的 id 和父 stack 的某个 resource id 完全一致。事实上，Heat 有以下资源支持 nested_stack：
OS::Heat::InstanceGroup
OS::Heat::ResourceGroup
OS::Heat::AutoScalingGroup
AWS::AutoScaling::AutoScalingGroup。
对于初步了解 heat 的同学来说，nested_stack 比较陌生晦涩，更多的资料请移步wiki：https://wiki.openstack.org/wiki/Heat/NestedStacks。

三. 解决方案

我们可以按照以上方法查询 Autoscaling Group 下得虚拟机信息，但是频繁的 CLI 查询操作繁琐、效率低下，用户体验极差。最好的方式是查询 Autoscaling Group 资源时，可返回其旗下的虚拟机列表。如下

核心代码为

完整的代码请见：
https://github.com/DeliangFan/heat/commit/63d35793c47784b4ff0e980a0148eaf96139c853

Heat 支持查询 Autoscaling Group 虚拟机列表

标签：heat   autoscaling   instance   

原文地址：http://blog.csdn.net/wsfdl/article/details/44943033