由OpenStack基金会举办的Project Teams Gathering（以下简称PTG）会议已于9月11-15日在 Denver 举行，共计420名开发者参加，踊跃讨论有关 OpenStack 下一个版本 Queens cycle 的开发工作，积极推动OpenStack各项能力的提升，甚至许多开发工作也在 PTG 过程中实际展开。
Heat是OpenStack的编排引擎，它可以基于文本文件形式的模板启动多个复合云应用程序（这些文件可以被视为代码）。简单来说，Heat为OpenStack用户提供了一种自动创建云组件（如网络、实例、存储设备等）的方法。利用Heat应用程序，开发人员能够在程序中使用模板以实现资源的自动化部署。Heat能够启动应用、创建虚拟机并自动处理整个流程。它还拥有出色的跨平台兼容性，能够与Amazon Web Services业务流程平台CloudFormation相对接——这意味着用户完全可以将AWS模板引入OpenStack环境当中。
在 PTG 的第三天到第四天，OpenStack基金会组织了 Heat sessions 进行讨论与现场开发。
EasyStack派出多名工程师参与了本届PTG，并应开源云中文社区邀请做前方报道。EasyStack软件工程师、OpenStack Heat 组件 PTL 林冠宇参与了 Heat sessions。
EasyStack软件工程师、OpenStack Heat 组件 PTL 林冠宇正参与讨论
以下是来自林冠宇带来的会议纪要：
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
Etherpad：
https://etherpad.openstack.org/p/heat-queens-ptg-placeholder
在 get_attr 功能使用上常常会因为编排尚未建立，而无法有效取得信息。导致其他功能（像是list_join）要呼叫 get_attr 时取得无法解析的信息，进而出错。讨论此问题就是要想办法在无法解析时获得一个折衷方式。
讨论后可行方式有二：
● 建立 Placeholder，避开所有可能的解析环节，直到实际能够解析为止。
● 告知错误，直接跳过无法解析的环节，避免该区块的解析。
实际实施中仍需要更多的讨论。目前也会先将所有可能出错的环节列出，方便后续讨论时能够一同解决。
Quota validation for whole template
Etherpad：
https://etherpad.openstack.org/p/heat-queens-ptg-template-quota-validate
此问题在 OpenStack 上存在已久。主因是 OpenStack 的各个服务并没有保留的机制，导致编排时，无法有效的计算未来使用资源的大小是否符合或小于实际可使用资源的大小。例如目前若打算建立100个 Nova 虚机，就算现在看Quota还有101个虚机空间，但在建立过程中，无法担保没有其他需求进入并建立超过2台以上的虚机，进而导致虚机空间不足的问题。
目前较粗略的解决方式是先行通过其他方式检查quota是否符合需求。再建立编排。目前得知有些使用情境，像是计量相关的资源，使用者不希望被这些建立失败的编排收费，进而成为此问题的潜在需求状况。
Tempest plugin repo （community goal）
Etherpad：
https://etherpad.openstack.org/p/heat-queens-ptg-tempest-plugin
在前面与 Tempest 团队讨论后有了大略的进展计划，后续决定将 Heat Tempest plugin 分出，建立成为新的 repo，并且将除了功能测试以外的整合测试都转移到新的组件内。既有的功能测试则转用新组件的程序库作为基础程序来源。
长期来看，会将 Heat 的测试转移使用新的子组件来执行。
另外，应 Interop 的需求，必须在所有测试上新增 Tempest ID，包含其中较难加入的 Gabbi 测试。
Project Goals
Etherpad：
https://etherpad.openstack.org/p/heat-queens-ptg-conti-for-topics
最后讨论总结一周以来团队所接触的工作与开发需求。
建立出必要的开发清单。基本上上述各个主题都衍生成为相关需求。后续会根据这些需求与需要的动作进行追踪。而下次的报告点则会在 Summit 的 Project Update。并期待接触更多的使用者与操作员，让相关需求可以得到更多输入，方便按周追踪相关工作与加入新元素。
再次特别感谢EasyStack的工程师们从 Denver 发回的报道！
阅读推荐：
投稿邮箱：openstackcn@sina.cn
940
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
