展开嵌套资源¶

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

对于许多 UI 使用场景，如果堆栈包含基于堆栈的资源，列出与给定堆栈关联的所有资源通常会消耗大量资源。因此，建议 resource-list 在请求时返回与给定堆栈关联的所有资源。

问题描述¶

目前，resource-list 仅返回给定堆栈的顶级资源，不包括任何嵌套堆栈内的资源。这使得一些使用场景变得困难或次优，因为需要在资源引用链接上进行多次 API 调用。

在删除堆栈时，UI 应该能够向用户呈现与给定堆栈关联的所有资源的列表，以避免因堆栈删除而删除某些资源而产生的困惑。
API 的用户（通过 CLI、curl 或其他方法）希望能够快速轻松地列出和跟踪与堆栈关联的每个资源的状态，无论资源在堆栈层次结构中的位置如何。
OpenStack 仪表板可能会显示来自堆栈的资源的不正确、令人困惑的拓扑结构，因为它不了解嵌套堆栈（例如，服务器组）。

提议的变更¶

建议的实现将向 resource-list API 方法添加一个可选的查询参数

nested_depth: 递归深度，用于限制返回的资源。此参数指示用户希望返回嵌套资源以及父堆栈中的资源。将此参数设置为数字会导致系统限制递归深度。值为 0 没有效果。值为 MAX 会返回所有资源，直到 max_nested_stack_depth。系统将永远不会递归到超过 max_nested_stack_depth，无论参数中传递的值如何。

Heat 服务将看到此参数，并递归遍历所有嵌套堆栈到指定的深度，并展平资源列表数据结构。对于存在于嵌套堆栈中的资源，还将包含包含的嵌套堆栈 ID 和父资源名称。

结果响应数据将如下所示

{"resources":
  [
    {
      "resource_name": "db",
      "links": [...],
      "logical_resource_id": "db",
      "resource_status_reason": "state changed",
      "updated_time": "2014-04-15T18:23:35Z",
      "required_by": ["web_nodes"],
      "resource_status": "CREATE_COMPLETE",
      "physical_resource_id": "4974985c-da78-444b-aeb3-9a80baccdd1a",
      "resource_type": "OS::Trove::Instance"
    },
    {
      "resource_name": "lb",
      "links": [...],
      "logical_resource_id": "lb",
      "resource_status_reason": "state changed",
      "updated_time": "2014-04-15T18:30:52Z",
      "required_by": [],
      "resource_status": "CREATE_COMPLETE",
      "physical_resource_id": "229145",
      "resource_type": "Rackspace::Cloud::LoadBalancer"
    },
    {
      "resource_name": "web_nodes",
      "links": [...],
      "logical_resource_id": "web_nodes",
      "resource_status_reason": "state changed",
      "updated_time": "2014-04-15T18:25:10Z",
      "required_by": ["lb"],
      "resource_status": "CREATE_COMPLETE",
      "physical_resource_id": "c3a46e6f-f999-4f9b-a797-3043031d381a",
      "resource_type": "OS::Heat::ResourceGroup"
    },
    {
      "resource_name": "web_node1",
      "links": [...],
      "logical_resource_id": "web_node1",
      "resource_status_reason": "state changed",
      "updated_time": "2014-04-15T18:25:10Z",
      "required_by": ["lb"],
      "resource_status": "CREATE_COMPLETE",
      "physical_resource_id": "c3a46e6f-f999-4f9b-a797-3043031d3811",
      "resource_type": "Rackspace::Cloud::Server",
      "parent": "web_nodes",
      "nested_stack_id": "1234512345"
    },
    {
      "resource_name": "web_node2",
      "links": [...],
      "logical_resource_id": "web_node2",
      "resource_status_reason": "state changed",
      "updated_time": "2014-04-15T18:25:10Z",
      "required_by": ["lb"],
      "resource_status": "CREATE_COMPLETE",
      "physical_resource_id": "c3a46e6f-f999-4f9b-a797-3043031d3822",
      "resource_type": "Rackspace::Cloud::Server",
      "parent": "web_nodes",
      "nested_stack_id": "1234512345"
    }
  ]
}

这些更改主要位于

heat.engine.service
heat.db
heat.api
python-heatclient

备选方案¶

目前，抽象嵌套堆栈的每个资源在通过 resource-show 查看时都将包含指向嵌套堆栈的链接。这允许用户通过以下方式在客户端实现此功能：

列出堆栈中的所有资源
单独检索每个资源
如果当前资源具有指向嵌套堆栈的链接，则递归该堆栈的资源并将其添加到列表/树中

虽然这提供了更大的灵活性，可以根据用户的特定用例列出嵌套资源，但对于所述用例以及从网络角度来看，效率非常低。本规范无意删除此选项，只是为了提供另一种更有效地满足几个常见用例的替代方案，同时保留现有的链接遍历方法，以供需要更多控制资源层次结构显示用例使用。

实现¶

负责人¶

主要负责人: randall-burt

里程碑¶

完成目标里程碑: Juno-2

工作项¶

更新 DB API 和实现，以接受资源列表的 nested_depth 参数，并在逻辑中使用该参数来追加来自任何嵌套堆栈的资源。
更新引擎以接受然后将 nested_depth 参数传递给 DB API。
更新 API 以接受并将 nested_depth 参数传递给引擎；请尽量不要对 RPC API 进行版本控制。
更新 python-heatclient 以公开新的标志并正确格式化输出
将参数添加到 Heat V1 WADL

依赖项¶

无

展开嵌套资源