Reorg AutoScalingGroup 实现¶

包含您的 Launchpad 蓝图的 URL

https://blueprints.launchpad.net/heat/+spec/reorg-asg-code

本文档描述了 AutoScalingGroup 实现的重组，涉及以下资源类型：

AWS::AutoScaling::LaunchConfiguration

AWS::AutoScaling::AutoScalingGroup

AWS::AutoScaling::ScalingPolicy

OS::Heat::InstanceGroup

OS::Heat::AutoScalingGroup

OS::Heat::ScalingPolicy

OS::Heat::ResourceGroup

目标是：1) 重组类层次结构；2) 将源代码拆分并移动到子目录中，以更好地反映资源的命名空间；3) 使未来对每个资源类型的增强更容易。

问题描述¶

当前资源组和伸缩组的类层次结构如下所示：

CooldownMixin
 |
 | StackResource
 |   |
 |   +--> ResourceGroup [OS::Heat::ResourceGroup]
 |   |
 |   +--> InstanceGroup [OS::Heat::InstanceGroup]
 |         |
 +---------+--> AutoScalingGroup [AWS::AutoScaling::AutoScalingGroup]
 |                |
 |                +--> AutoScalingResourceGroup [OS::Heat:AutoScalingGroup]
 |
 | SignalResponder
 |   |
 +---+--> ScalingPolicy [AWS::AutoScaling::ScalingPolicy]
            |
            +--> AutoScalingPolicy [OS::Heat::ScalingPolicy]

除了这个层次结构，还有位于 heat.scaling.template 等模块中的实用函数。

正如现有蓝图指出的，这个设计的一个问题与命名空间有关：

https://blueprints.launchpad.net/heat/+spec/resource-package-reorg

另一个问题是，将所有类都实现在一个文件中，使得实现难以理解或改进。例如，将 InstanceGroup 作为 ResourceGroup 的子类可能更有意义。再例如，将 AutoScalingResourceGroup 作为 InstanceGroup 的子类没有太大意义，因为子类对其他资源类型作为其成员更加开放。

提议的变更¶

重组类层次结构

提议的更改是重组类层次结构，如下所示：

CooldownMixin
 |                           StackResource
 |                                  |
 |                            ResourceGroup
 |                       [OS::Heat::ResourceGroup]
 |                                  |
 |              +-------------------+---------------+
 |              |                                   |
 +-->    AutoScalingGroup                      InstanceGroup
 | [OS::Heat::AutoScalingGroup]          [OS::Heat::InstanceGroup]
 |                                                  |
 |                                                  |
 +---------------------------------------> AWSAutoScalingGroup
 |                                 [AWS::AutoScaling:AutoScalingGroup]
 |
 |                 SignalResponder
 |                        |
 +----------------------->|
                          |
              +-------------------------------+
              |                               |
      AWSAutoScalingPolicy             AutoScalingPolicy
 [AWS::AutoScaling::ScalingPolicy]  [OS::Heat::ScalingPolicy]

此更改将破坏 OpenStack 和 AWS 实现之间的子类关系。

对于实用/辅助类，例如 CooldownMixin，第一步是将它们分离成独立的类，然后根据需要进一步重构为实用函数。

重新定位源文件

AWS 版本将被重新定位到 heat/engine/resources/aws 子目录中，包括 LaunchConfiguration 实现。OpenStack 版本将被重新定位到 heat/engine/resources/openstack 子目录中。

共享父类 ResourceGroup 将保留在 heat/engine/resources 中，而 CooldownMixin 类将被重新定位到 heat/scaling 子目录中。模块和类的最终布局如下所示：

heat/engine/resources/
  |
  +-- resource_group.py  [ResourceGroup]
  +-- instance_group.py [InstanceGroup]
  |
  +-- aws/
  |    |
  |    +--- autoscaling_group.py [AWSAutoScalingGroup]
  |    +--- scaling_policy.py [AWSAutoScalingPolicy]
  |    +--- launch_config.py [LaunchConfiguration]
  |
  +-- openstack/
       |
       +-- autoscaling_group.py [AutoScalingGroup]
       +-- scaling_policy.py [AutoScalingPolicy]

heat/scaling/
  |
  +-- cooldown.py [CooldownMixin]
  +-- (possibily other shared utility classes)

这种重新排序是可选的。在完成清理工作后，我们将确定是否确实需要重新排序。

备选方案¶

由于这是一个纯粹的实现层面的更改，一个经验法则是“我们不破坏用户环境”。

我们可以让 AWS AutoScalingPolicy 扩展 Heat AutoScalingPolicy。但是，这意味着对 Heat 实现的任何未来更改都必须非常小心，以防这些更改破坏 AWS 版本与其 Amazon 规范的兼容性。

同样适用于两种版本的 AutoScalingGroup。希望我们可以将公共代码提取到 ResourceGroup 级别以最大限度地减少代码重复。但是，这两个类之间的子类关系从长远来看不是一个好的设计。AWS 版本的目的是密切遵循 Amazon 的开发，而 Heat 版本的目的是更多地关注 OpenStack 环境下的用户需求。因此，目前的想法是拆分实现，即使这意味着一些代码重复。

实现¶

负责人¶

主要负责人: Qiming

可能还有其他贡献者有兴趣提供帮助。

里程碑¶

完成目标里程碑: Kilo-1

工作项¶

将公共代码提取到父类
拆分资源 AWS 版本和 OS 版本
修改测试用例

依赖项¶

不会引入对其他库的新依赖。

这项工作可能会干扰与 AutoScalingGroup 相关的几个正在进行的工作。以下工作将需要基于此更改进行重新调整：

https://review.openstack.org/110379 伸缩组缩减插件
https://review.openstack.org/105644 LaunchConfiguration bdm
https://review.openstack.org/105907 平衡跨 AZ 的 ScalingGroup

重组 AutoScalingGroup 实现