支持外部资源。¶

包含您的 Launchpad 蓝图的 URL

https://blueprints.launchpad.net/heat/+spec/external-resources

问题描述¶

我们没有办法指示 Heat 使用现有的（外部）物理资源 ID。

用例 1：¶

在一段时间内运行堆栈时，用户可能需要对服务器（重建它）进行带外操作。但这会使它与 Heat 的视角不同步。因此，这是一种告诉 Heat “这是新的资源 ID，我现在正在接管它”的机制。在稍后某个阶段（s）他可能希望告诉 Heat 再次接管它 - 通过删除“external_reference”部分。这满足了 TripleO 的需求（并且我们假设许多其他需要对重要的堆栈进行长时间操作的用户），允许 get_attr/get_resource 在他们对外操作资源时继续发挥作用，并让 Heat 保持不变。当用户对它的状态满意时，他们可以将它返回到 Heat 的控制之下。

用例 2：¶

存在一个现有资源，我们希望使用 get_attr 来检索有用的信息，而不是手动执行此操作并通过参数传递信息。

在所有这些情况下，一旦完成，资源可以标记为外部，任何更新或删除都将被忽略（除非用户首先删除“external”信息）。

提议的变更¶

为了实现这一点，用户会将以下内容添加到模板中

resources:
  ...
  res_a:
    type: OS::Nova::Server
    external_id: the-server-id
    properties:
      ...

注意：1. 没有“resource_data 或 Metadata”的位置，因为这些由操作使用，一旦变为外部，这些操作将不再可能。将有一些资源类型，由于缺少资源数据/元数据，将无法从外部变为正常资源。这将尽可能地记录，并且 Heat 开发人员应避免使用 resource_data。

2. 一旦资源具有“external_id”属性，属性将被忽略（但允许存在）。如果删除了“external_id”，资源将使用属性进行更新。

使用 external_id 创建资源。¶

这涵盖了第二个用例。在这里，我们看到存在一个 external_id，逻辑上执行采用和检查（以确保资源实际存在）。

使用 external_id 更新资源。¶

这涵盖了第一个用例。我们覆盖了 Heat 之前写入的 resource_id 并忽略所有属性。这里也会调用检查来确保资源存在。如果 external_id 与现有的 physical_resource_id 不同，则将删除现有的资源。

删除 external_id。¶

要将资源转换为“正常”资源，用户必须从资源中删除“external_id”属性并执行堆栈更新。如果资源需要一些缺失的 resource_data 或元数据，而这些数据缺失（并且无法恢复），则这将失败，并且它将保持为外部资源。

删除具有 external_reference 的资源的堆栈。¶

当存在 external_reference 时，假定删除策略为 RETAIN（不会被删除）。

备选方案¶

用户可以使用当前的 adopt/abandon 机制，但它有一些略有不同的行为。此外，使用 2 次 API 调用切换物理 resource_id 比较困难。

实现¶

负责人¶

主要负责人: asalkeld

里程碑¶

完成目标里程碑: Liberty-2

工作项¶

代码

功能测试。

需要在模板指南中添加文档。

记录限制（需要 resource_data 和元数据的资源）。

依赖项¶

无

添加对外部资源的支持。