PTG（项目团队聚会）是开发团队开会讨论当前任务，状态和计划的活动。 PTG是几年前从主流OpenStack峰会上剥离出来的。
PTG首先通过Zoom和Jitsi Meet在线举行。但是，会议中图像和声音的结合使这种变化完全不明显，特别是在现在熟悉的IRC团队会议的背景下。
为时三小时的中子会议于星期二至星期五举行。主要会议纪要发布在OpenStack Etherpad和OpenStack邮件列表上。该活动的议程是根据中子开发商的提议制定的，会议时间表由中子Slawek Kaplonski团队的主席PTL（项目组负责人）制定。
在本文中，我将讨论3个我认为值得关注的主题，并且需要一些解释。
OVN
在此PTG上有很多关于OVN的讨论，这并不奇怪，因为大多数核心团队成员都代表OVN的主要贡献者RedHat。
什么是OVN？
- 适用于Open vSwitch（OVS）的开源L2 / L3网络虚拟化：
- 逻辑开关
- 逻辑IPv4和IPv6路由器
- L2 / L3 / L4 ACL（安全组）
- 多个隧道覆盖图（Geneve，STT和VXLAN）
- 逻辑负载均衡器
- 基于TOR的逻辑物理L2网关
- 基于软件的逻辑物理L2 / L3网关
- 在与OVS相同的平台上工作：
- 的Linux
- 货柜
- DPDK
- 整合：
- OpenStack中子
- Docker群
- Kubernetes
OVN架构
“ OVN 75字。
开放式虚拟网络由OVS项目运营，并由原始的OVS团队开发。该决定是基于多年经验重新设计ML2 / OVS控制平面的尝试。它旨在与OpenStack和Kubernetes一起使用。 OVN建立在新的体系结构之上，该体系结构放弃了Python代理通过RabbitMQ与Neutron API服务进行交互的概念，而支持通过OpenFlow和OVSDB进行通信的C守护程序。” -中子PTL Slawek Kaplonsky。
最初，Neutron OVN驱动程序是在Neutron体育场内的一个单独项目-网络-ovn开发的，而在Ussuri版本中，Usuri已包含在主要的Neutron存储库中。
因此，该解决方案消除了ML2 / OVS的主要问题-RabbitMQ，这无疑是一个加分项，并且通常来说“ OVN的设计目标是拥有可以大规模运行的生产质量的实现”。但是，OVN是否支持使用ML2 / OVS时可用的功能？似乎这并非完全正确，这已成为PTG讨论的主题之一。结果，突出显示了几个空白（项目页面上提供了完整列表）。首先，开发人员注意到对路由网络，某些QoS功能，BGP和可用区的缺少或不完全支持。尽管OVN团队已准备好进行上述所有操作，但他们在会议上承认，这以前不是他们的优先考虑-因为内部利益更为重要。另外，ML2 / OVS的开发当然是不会暂停，这意味着可能会出现新的空格。
但是，我认为OVN的主要问题在于它尚未得到广泛使用，并且尚未在大型安装上进行过测试。此外，还有一些有关高可用性的问题：
- ovn-northd是主要组件之一，目前仅支持主动/被动HA模式，目前仅计划主动/主动
- 另一个中央组件ovsdb-server也仅支持主动/被动模式
最后一点可能实际上已经过时了，因为自OVS 2.9起增加了对ovsdb群集（基于Raft算法的支持）的支持，但是尚不清楚是否在OVN和OpenStack版本中对此进行了测试。例如，openstack-ansible中的关联票证尚未关闭。
同样值得关注的是，OVN使用Geneve隧道而不是VxLAN，这会影响MTU设置（Geneve标头大于VxLAN）并支持硬件加速隧道处理。
尽管如此，该项目正在迅速获得发展势头，似乎OVN应该在几个版本中成为基本的Neutron插件。此外，在PTG期间，核心团队开发人员同意使OVN成为DevStack的默认插件。
这些变化将导致什么：
- OpenStack Neutron CI,
- ML2/OVS ( )
- Neutron CI , ML2/Linuxbridge ML2/OVS – ,
- , core OVN
关于最后一点，Neutron PTL发表了以下信息：“ Neutron团队认为OVN和Neutron OVN驱动程序是建立在现代架构之上的，该架构为更简单，更有效的解决方案提供了更好的基础。我们看到对kubernetes-ovn的参与有所增加，从而导致了核心OVN社区的扩展，我们也希望OpenStack也能利用Kubernetes对OVN的这项投资。
目前，与ML2 / OVS相比，Neutron OVN驱动程序在支持的功能方面存在差距，但是，我们的团队正在努力缩小这些差距，我们认为该驱动程序将成为Neutron的未来，因此，我们希望使其成为默认的Neutron ML2后端。 DevStack。”
到目前为止，尽管仍然存在从VxLAN到Geneve隧道的过渡，如何从ML2 OVS迁移到ML2 OVN以及性能和支持功能方面的疑问，对此消息的反应还是相当积极的。
新EngineFacade的应用
EngineFacade是sqlalchemy之上的框架，该框架集成了所有OpenStack项目中使用的数据库逻辑。在数个版本之前，它经过了重构，从而导致了所谓的“新EngineFacade”的出现。下一步是使该框架适应OpenStack。
我认为，该主题已包括在PTG议程中，因为有关该主题的工作已经拖延了多个版本，并且尚未完成。事件发展的原因是大量必要的变化，适应过程中的一些不平凡的问题，而且在我看来，缺乏动力，因此缺乏人力资源。真的，为什么要更改一些已经起作用并且甚至没有发出很多bug的东西？Mike Bayer规范中概述了对该问题的相当详细的答案。在这里，我将尝试简要介绍支持EngineFacade的注意事项，以便您不必阅读以下较长的文字：
- 旧的EngineFacade提供的是低级API，而不是针对特定用例量身定制的高级API，因此，这实质上是工厂，而不是外观。结果是：
- EngineFacade OpenStack
- , ,
- EngineFacade // : reader writer, , .
听起来很简单且合乎逻辑，那么EngineFacade适配的问题是什么？老实说，我并没有详细介绍细节，但似乎造成问题的主要原因是，在某些复杂的情况下，旧的EngineFacade在Neutron中被误用并且可以正常工作（！）。但是，它破坏了工作脚本（在我看来，这是使用遗留代码时的一个非常典型的问题）。显然，在这种情况下，您必须首先更正这些脚本的逻辑。
实际上，编辑的内容不多，只有一个补丁，核心团队同意共同解决此问题。当然，任何有兴趣的人都可以帮助进行分析和审查！
中子库
中子-lib有几个主题。首先，让我提醒您，对于那些不大量参与Neutron开发的人来说，这意味着什么。首先，Neutron并不是一个单一的项目-实际上，它由多个存储库组成，这些存储库在通用名称Neutron Stadium下以OpenStack网络的不同区域工作，“ neutron”只是一个，尽管是一个大型项目。其余项目是所谓的高级服务（例如，neutron-lbaas，-fwaas，-vpnaas，-dynamic-routing等）和第三方/供应商插件（例如，networking-midonet，-odl，-ovn）。该列表包括由Neutron PTL和核心团队开发的项目，这些项目每天都直接参与其中。为了做到这一点，他们确保整个体育馆在开发的各个方面都遵循通用的工作原则和规则-结构，开发，代码风格，测试，文档编制等。老实说，今天这还不完全正确，主要的负担仍然落在项目维护者的肩上。
在创建neutron-lib之前，所有网络项目都从neutron主存储库导入了所有通用代码-常量，接口（抽象基类），辅助函数等。中子中对此类代码的任何更改都可能破坏相关项目。然后，在Ocata版本中，启动了neutron-lib计划来解决此问题：现在，所有通用代码都应存储在单独的存储库中，并应进行版本控制。具体而言，目标制定如下：
- 从中子中删除子项目的依赖项（即，从子项目中的中子中删除直接导入）
- 通过重构代码或在适当的neutron-lib部分中重新设计次优模式架构，在Neutron中完成作业
实际上，neutron-lib看起来是一个双赢的选择：因此，主要的Neutron和第三方项目的服务都应该处于亏损状态。什么地方出了错？
缺乏支持
没有贡献者和维护者的支持，任何开放源代码项目都不可能存在，这些人准备投入时间来从事项目。对于中子库，缺乏这样的志愿者，结果，原始逻辑停止了工作，即 这样所有通用代码都存储在这里，可以导入而不用导入中子。主要维护者neutron-lib（boden）前一段时间离开了该项目。在PTG期间，有人提出了放弃将所有通用代码移植到中子库的想法，甚至放弃将中子库的代码移植回中子的想法。该提案未通过的原因有两个：
- 中子库仍被广泛使用
- neutron-lib具有一些价值，因为它突出显示了无法更改的标准接口，从而不会一次破坏多个项目
讨论之后，neutron-lib保持不变，但是中子代码重定位和弃用策略需要更新。
当然，如果可能的话，所有新代码都应在中子和中子库之间共享。这把我们带到了第二个问题。
测试问题
另一个问题与开发期间的测试有关。如果neutron补丁的一部分引入了新的或更改了现有的共享代码，则应按照规则将其发送到neutron-lib。这使得贴片的中子部分依赖于这些lib变化。但是，目前正在neutron-lib发行版上测试neutron补丁，以验证它们是否与最新发行版一起使用。结果，此类修补程序将无法通过CI中的测试。
使用向导中的neutron-lib代码测试所有中子补丁也有一些缺点。例如，不能保证neutron向导将与最终用户使用的最新neutron-lib版本一起使用。
以下是解决此问题的方法（感谢Bence Romsics的出色总结）：
- , , neutron-lib , neutron .
- , :
- , “foo” neutron-lib, . neutron , “_foo” TODO , , neutron-lib.
- neutron-lib , neutron, _foo “import _foo” “from neutron-lib import foo”.
- 另外，您可以使用向导和最新的neutron-lib版本在CI上运行单独的检查。但是只有其中一个可以投票。简单地将任务数量加倍将给OpenStack CI基础架构带来巨大的额外负担。
在PTG的讨论中，提出了三个建议：
- 使用neutron-lib向导进行“检查CI”；对“ Gate CI”使用neutron-lib发行版本-但是，如果中子补丁通过“ Check CI”检查并在“ Gate CI”上崩溃，它将看起来很奇怪
- 请勿进行任何更改：最好在neutron-lib发行版上运行测试。例如，现在已为OSC（OpenStackClient）完成
- 使用neutron-lib向导运行测试，并使用neutron-lib版本添加定期任务以进行测试
最终解决方案：使用master分支中的neutron-lib在“ Check CI”中创建一个新的无投票权问题。基本上，一切都保持原样，但是可以在将其提交到master分支之前检查包含中子和中子库变化的功能是否通过CI。
希望本文对您有所帮助，并帮助您更好地了解Neutron的发展方向和方向。
感谢您的关注！