直击PTG|OpenStack组件将获得更好的测试环境

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

PTG 是 OpenStack 基金会针对开源贡献者组织的新的活动，每隔6个月（每年的第一季度与第三季度）举办一次。目的是在新版本发布周期的初始阶段，将项目团队成员聚集在一起讨论新版本的特性，快速迭代解决复杂问题的方案，针对关键问题制定处理优先级。该会议使开发者们能够建立在未来六个月并肩作战的信任关系。PTG由原来的OpenStack Design Summit 拆分而来，上一届PTG于2017年2月20-24日在亚特兰大举行。

EasyStack派出多名工程师参与了本届PTG，并应开源云中文社区邀请做前方报道。

EasyStack社区总监兼OpenStack基金会独立董事郭长波（中）、EasyStack研发工程师刘瀚檄（左）、EasyStack软件工程师、OpenStack Heat 组件 PTL 林冠宇（右）

PTG前面两天为跨组件、跨团队讨论，后面三天为组件团队内讨论与开发。跨组件部分主要包括 Skip Level Upgrade， Interop WG Extentions， Horizon Heat plugin， Application Credentials， Policy in Code working， Tempest plugin 等讨论与开发。

聚餐&讨论

以下是来自EasyStack工程师们带来的会议纪要：

Skip Level Upgrade

（ https://etherpad.openstack.org/p/queens-PTG-skip-level-upgrades ）

又称为 Fast forward upgrade （快速升级）， 主要讨论 OpenStack 目前快速升级的状况。从讨论结果看，基本上整体OpenStack 的核心组件均已具备快速升级能力，特殊状况为 Nova， 因为 Nova 的 Upgrade流程要求必须以一次release 作为一个 Upgrade 单位。除此之外值得注意的是 OpenStack 已具备相当良好的 SQL 更新能力，在多个版本同时更新下几乎不会有问题。同时在 OpenStack 多架构设计下不需要考虑 Rabbit MQ 的更新问题。综合以上优势在讨论离线跨版本更新时，不会有问题。至于在 live skip level upgrade， 鉴于实际运营环境较少实施，风险也较大，讨论中并未将此案例作为核心讨论。

Interop AddOns

（https://etherpad.openstack.org/p/InteropDenver2017PTG_AddOns）

又称 Interop AddOns。主要针对核心以外的组件，给予企业环境 Interop 测试，并提供 AddOns 标签。不但不会破坏原先 Interop 的核心标签，更额外提供了认证其他组件的能力。

讨论决定，在明年年初，就会推出第一版本的 AddOns， 包含两个可认证目标 Heat 跟 Designate 。由于此两个项目是除了核心组件外，最为成熟的项目，因此列入优先纳入考虑。在测试中，只要环境是建立于原生的 Mitaka 到 Master 版本并支持原生API，相信都会通过 AddOns 测试。至于在版本下限上，目前是支持到 Mitaka。要等到后续 Interop 团队选择升级后才会往上提升。在 Heat 的测试上，主要要求原生的 API 测试（兼容到 Mitaka 的 API），还有一个基本的情境测试。

Horizon Heat plugin

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

此讨论中，主要针对目前 Heat Dashboard 分离 Horizon 的可能性。还有分离的流程与后续测试方法。决议上，针对分离流程暂定为半年。目标为先将 Heat Dashboard 分离成为 Heat 的子组件。并套用原先的 Horizon CI 测试。等到稳定后，再将新功能推入。过程中会同时引入 Heat 与 Horizon 团队共同加入管理。直到双方都认可稳定，并且 CI 也稳定进行后，会在后续讨论如何继续开发。目前协助此开发的团队来自 NTT ，对于 Drag & Drop 的介面也提供了基本的操作展示。后续稳定后的开发也会由核心资源的 Drag & Drop 建立等功能开始。

Application Credentials

（https://etherpad.openstack.org/p/queens-PTG-vmbm）

此讨论是继续之前在 Boston Summit 时的讨论（https://etherpad.openstack.org/p/pike-forum-cloud-applications）。

我们已经正式将 application support 正式加入 OpenStack 的方针中。也讨论如何让虚机或裸机上的应用程序能够使用或呼叫OpenStack 的各种服务，在这个讨论上，几项结论，包含我们后续会提供给应用程序的认证信息，将会允许该程序使用OpenStack的各种服务，但是不包含KeyStone Token 服务或相关的权限管理服务。同时该认证信息将会限制于提供者所限定的服务范畴。比如 Heat 提供给裸机一个应用程序的认证信息，让裸机内的应用程序能够呼叫OpenStack 的各种服务，Heat同时已经先将此认证信息限定为只能操作 Nova 与 Swift。因此该应用程序只能操作同组件下的 Nova 与 Swift 资源。目前这项功能还在开发中，但是相信为 Keystone 团队的首要任务之一。

Policy in Code working

（https://etherpad.openstack.org/p/policy-queens-ptg）

此为 OpenStack Queens 版本的目标之一，让多数组件都能够将 policy file 中的条件，定义在python 程序码内，以提供更好的在线管理。目前已经有几个组件（Nova、Keystone）完成此项任务。通过程序码内定义，若平台本身并没有任何其他的 Policy Rule 需求，甚至可以将 Policy File 完全移除。另外若有任何希望改写 Policy Rule 的部分，则只需要在 Policy 档案内，将想要覆盖的 Rule 写上即可。因此在转移过程中，并不需要作任何的舍弃宣告，因为新旧机制是并行的。目前 Keystone 团队也正在实现让新的机制能够产生舍弃宣告，让 Policy 也有机会更新，转换或舍弃。

Tempest plugin

（https://etherpad.openstack.org/p/tempest-separate-plugin）

此为 OpenStack Queens 版本的目标之一，该目标是让组件能够建立更好的测试环境。并能自我管理测试。主要工作则为分离既有的测试，然后生成新的组件，并将该组件建立成各个组件的 Tempest plugin。通过以上工作可以让测试更加快速与方便。假设使用者希望测试 Heat ，则再也不需要整个 Heat 组件，然后满足整个组件的需求后才能执行测试。新的 Tempest Plugin 提供了更快速与无版本限制的测试。

再次特别感谢EasyStack工程师们从 Denver 发回的报道！

阅读推荐：

OpenStack能拯救混合云吗？

容器管理：如何防止容器蔓延与成本蔓延

投稿邮箱：[e-mail]