PTG直击 | Heat将强化集群资源管理

由OpenStack基金会举办的Project Teams Gathering（以下简称PTG）会议已于9月11-15日在 Denver 举行，共计420名开发者参加，踊跃讨论有关 OpenStack 下一个版本 Queens cycle 的开发工作，积极推动OpenStack各项能力的提升，甚至许多开发工作也在 PTG 过程中实际展开。

Heat是OpenStack的编排引擎，它可以基于文本文件形式的模板启动多个复合云应用程序（这些文件可以被视为代码）。简单来说，Heat为OpenStack用户提供了一种自动创建云组件（如网络、实例、存储设备等）的方法。利用Heat应用程序，开发人员能够在程序中使用模板以实现资源的自动化部署。Heat能够启动应用、创建虚拟机并自动处理整个流程。它还拥有出色的跨平台兼容性，能够与Amazon Web Services业务流程平台Cloud Formation相对接——这意味着用户完全可以将AWS模板引入OpenStack环境当中。

在 PTG 的第三天到第四天，OpenStack基金会组织了 Heat sessions 进行讨论与现场开发。

Rolling upgrade

Etherpad：

https://etherpad.openstack.org/p/heat-rolling-upgrade

目前 Heat 相信已经有 rolling upgrade 的能力，能够在多版本中转移与管理服务。目前在Heat 的 CI 中，也加入了多节点的升级测试（Multi-Node Grenade Tests）。由于此能力的完成度已经到达一定地步，不论是文件与实际功能都有稳定表现，因此也已经向TC 发出请求（https://review.openstack.org/#/c/503145/），希望让Heat 具有rolling upgrade 的标签。后续针对开发，将会持续强化升级前后的测试。

tooz integration

Etherpad：

https://etherpad.openstack.org/p/heat-queens-ptg-tooz-integration

目前OpenStack 有许多讨论是针对Etcd 整合（如同之前在Boston Summit 所分享），整合部分包括如何更新OpenStack 所有服务的DLM，目前整合方式讨论结果为使用tooz，在tooz 与heat 整合上目前还尚未有实际开发，通过一些研究，我们认为tooz 还缺乏以下几点功能：

要能为同一 heat engine 重新要求 lock

提供 API 来确认 heat engine 是否已经取得 lock

tooz 在不同backend下的行为模式会有出入，这对于 backend 转会并不是理想状态

在新版本，我也会针对这几点来确认 Tooz 跟 Heat 的整合还有哪些工作要先达成。

目前 Heat 已经有稳定的 DB 来管理 Locks，因此整合需求并不会如此急迫，但是大量的使用DB作为 DLM（distributed lock manager）已经为 DB带来不少负担。因此长期来看，还是需要转移到 Etcd 等服务，而理想上仍是往 Tooz 方向作为间接首选。

Cluster resource improvement

Etherpad：

https://etherpad.openstack.org/p/heat-queens-ptg-cluster-resource-improvement

越来越多的 Heat 实际应用场景正在变得复杂，像建立 Big Data 平台，建立 Kubernetes平台，建立数据库平台，各种使用场景越来越趋向集群方式。因此，讨论着重于该针对集群式资源提供怎样的管理。

同时解决几个 Magnum 与 Sahara 团队遇到的问题：

大量资源的请求，可能会导致环境服务负担过重的状况，在此状况下需要将资源分类、分群来操作，将原本一次性的操作分成多次进行，避免造成负担。

当 quota 被占满时，先移除不必要的资源以清理quota。后续其他资源就有较高的机会成功执行。

另外几个讨论点，包括讨论是否根据资源来调整执行当中的缓冲时间，是否要建立更多的时间标记来确认目前执行状态是否正确（避免遇到 更新编排后立刻检查编排状况，却取回尚未变更的更新失败状态导致检查回传更新失败）。目前许多 feedback 来自 Magnum 与 TripleO 的实际应用。因此在接下来的版本中势必会多着墨于强化集群资源管理。

A horizon plugin for HOT creation in drag & drop

Etherpad：

https://etherpad.openstack.org/p/horizon-plugin-hot-creation

在前两天的跨组件讨论中，与 Horizon 团队一同讨论如何将 Heat Horizon Plugin 取出成为独立的 Heat 子组件。在此讨论中，我们更深入 Heat 部分，讨论后续可以如何改进。包含建议应该由 Heat 来提供资源信息以简化新介面。另外新的Heat Dashboard 也会改写成为 AngularJS 框架。介面上目前建议是以简洁的界面作为主要设计。并且初步的拖拉介面只需要先引入核心资源（Nova、Cinder、Neutron等），后续再慢慢扩展即可。

Policy in Code （community goal）

Etherpad：

https://etherpad.openstack.org/p/heat-queens-ptg-policy-in-code

如同前两天所参与的讨论，此讨论更深入的探讨 Heat 组件部分该如何加入相关功能。

此部分可以分成三部分，包含如何使用既有框架来达到新设计，如何让 Heat 特有的资源类别认证部分也能够完整接入，还有后续该如何测试新框架。关于如何使用既有框架，开发上虽步骤繁多，但并不复杂，多数环节通过新增参数即可兼容。在资源类别认证部分，则需要将新的开发流程转移成兼容既有流程。包括必须容忍 Policy Not Registered 问题，并且转移成认证成功（假设OS：：Nova：：Server并不在 policy内，就表示他的权限并不需要被否决）以达成兼容。至于后续测试部分，则应该再整合测试内，新增反向测试（测试当权限被否决时是否具有我们期待的行为）。

Federated Keystone and Heat

Etherpad：

https://etherpad.openstack.org/p/heat-queens-ptg-federated-keystone-and-heat

在讨论上，与 Keystone 团队共同研究 auto provision 功能是否能满足 federation 与 trusts 等两个认证功能的兼容状况。方式是在 federation maps 里先建立 与trusts 对应的federation 关系。若能成功，则 Heat 的部分，只需要将流程放入文件即可。 Keystone 部分已经在讨论，会将此场景放入 CI 以确保后续使用。同时若此方式能成功，就能移除掉 Heat 唯一的 Know issue。因此会持续推动此功能，来达到使用场景更完善的地步。

Cross-stack reference

Etherpad：

https://etherpad.openstack.org/p/heat-queens-ptg-cross-stack-reference

在此讨论内，讨论如何将资源信息由一个编排引入到另一个编排。例如 AWS 有 Export 与 Import 的方式将资源由一个编排的输出导入到另一个编排的输入。

在讨论中，我们也认为若有此功能将方便编排脚本的实际使用。不过很有可能在实际中只加入 Import 部分，考虑是既然资源都在同一组件内，应可有权限互相使用。另外考虑若要建立相依性，则会让实现过程更为复杂，因此朝向简单设计作为考量。

Breaking the stack barrier

Etherpad：

https://etherpad.openstack.org/p/heat-queens-ptg-breaking-stack-barrier

讨论如何让多个相依的编排能够在建立时打破编排的范畴，例如一个编排底下可能有相当复杂的结构，甚至建立其他编排。若能够考量将所有编排的相依拓朴视为同一个相依拓朴，相信更能够对应到应用程序的实际拓朴。由于此需求实际范畴抽象，加上目前讨论后似乎较难在现阶段取得实际应用，因此尚未将此功能纳入此阶段开发。

Placeholder

<p style="box-sizing: border-box; margin-top: 0px; margin-bottom: 0px; padding: 0px; word-wrap: break-word; color: rgb(89, 87, 87); font-family: "Microsoft Yahei", "Hiragino Sans GB", "WenQuanYi Micro He