PTG直击 | 跨项目协作OpenStack核心组件快速升版能力

继首届 PTG 在 Atlanta 成功举办之后，本届 PTG 已于9月11-15日在 Denver 召开，前两天为跨组件，跨团队讨论，后三天为组件团队内讨论与开发。本次全球共有四百二十名开发者齐聚Denver，EasyStack 派出了工程师与开发者共同讨论有关于 Queens cycle 的开发工作。

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

EasyStack 参加 PTG 团队

在跨组件部分主要参与了 Skip Level Upgrade, Interop WG Extentions, Horizon Heat plugin,Application Credentials, Policy in Code working, Tempest plugin 等讨论与开发。

Skip Level Upgrade

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

又称为 Fast forward upgrade, 主要讨论 OpenStack 目前快速升版的状况。由结论来说，基本上整体OpenStack 的核心组件都具有 Fast Forward Upgrade 的能力，特殊状况为 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 版本的目标之一，让多数组件都能够将 policyfile 中的条件，定义在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 提供了更快速与无版本限制的测试。