StackDefinition 类¶

https://blueprints.launchpad.net/heat/+spec/stack-definition

将堆栈定义的所有数据（包括模板、参数值、资源属性和引用 ID）封装在一个类中，并在内置函数中使用该类，而不是 Stack 对象本身。

问题描述¶

将 Stack 对象传递给 Template.parse()（进而传递给 Function 对象）以提供访问定义堆栈所需数据的能力，由此产生了一些问题。

主要问题在于，在执行单个资源的收敛检查时使用的所谓“轻量级堆栈”实际上并不轻量级。特别是，为了使正在检查的资源使用另一个资源的属性或资源 ID，我们为堆栈中的每个资源创建一个 heat.engine.resource.Resource 对象。即使我们实际需要的值通过 RPC 传递，并且 Resource 对象的数据并未从数据库加载，也没有使用其任何代码，也会发生这种情况。消除从数据库加载数据减少了 10% 的内存使用量，并且在图遍历过程中不创建 O(n^2) Resource 对象可能会进一步节省内存。

此外，以这种方式使用 Stack 对象使得确定第三方模板插件及其相关 Function 的接口的稳定部分变得极其不清楚。开发人员不知道需要在不同版本之间保留 Stack 接口的哪些方面，插件开发人员不知道可以依赖什么。Stack 类提供的许多潜在操作实际上可能在收敛架构中效率低下，或者将来可能会变得如此。

提议的变更¶

创建一个新的 StackDefinition 类来封装定义堆栈所需的数据。将此对象传递给 Template.parse()，以代替 Stack 对象。

当通过 StackDefinition 访问资源时，返回仅包含相关数据的 ResourceProxy 对象。

从本质上讲，初始 API 将包括 HOT 或 Cfn 模板插件中的内置函数当前使用的 Stack 和 Resource 类中的所有部分。将维护现有接口，以便在使用此功能子集的插件无需进行任何代码更改。这包括

模板
- 环境
  - 参数值
资源
- 名称
- 状态
- 操作
- 属性
- 引用 ID
- DB ID
- UUID
父级（facade）资源
- 元数据
- 模板

在收敛时检查资源时，只有存在直接依赖关系的其他资源才会有可用的代理，并且只有当前资源（如 function.dep_attrs() 函数返回）所需的属性才会有可用值。

除非上述明确提及，否则 StackDefinition 中将无法获得任何其他数据。这可能会破坏第三方模板插件，但由于当前稳定 API 的表面积不确定，因此很难确定破坏的程度。然而，任何依赖于超出提议 API 之外行为的内容可能效率极低，并且在 Heat 上游中未经测试。总而言之，值得在开发周期的早期容忍这种破坏，以便转向保证稳定的 API。第三方模板插件开发人员有机会就此规范提出请求。

API 的未来更改（超出 Pike）需要一个弃用期。

备选方案¶

就这样接受现状？

实现¶

负责人¶

主要负责人: zaneb

里程碑¶

完成目标里程碑: pike-1

工作项¶

将收敛记录的关于图遍历后节点的数据封装在 NodeData 类中。
教导 Resource 生成自己的 NodeData。
创建一个 ParentResourceProxy 来封装关于 facade 资源的数据，并可能独立于父堆栈加载它。
将 Stack 的模板和其他数据移动到 StackDefinition 类中，并将对该数据的任何请求代理给它。
在处理遗留路径中的每个 Resource 之后更新 NodeData。
将 StackDefinition 传递给 Template.parse()，以代替 Stack。

依赖项¶

无

StackDefinition 类