PTG（Project Team Gathering）は、開発チームが集まり、現在のタスク、ステータス、および計画について話し合うイベントです。 PTGは、数年前に主流のOpenStackサミットからスピンオフしました。
PTGは、ZoomとJitsiMeetを通じて最初にオンラインで開催されました。ただし、会議での画像と音声の組み合わせにより、特に今ではおなじみのIRCチーム会議を背景に、この変更はまったく目立たなくなりました。
3時間のニュートロンセッションは火曜日から金曜日まで実行されました。メインの会議議事録は、OpenStackEtherpadとOpenStackメーリングリストに掲載されています。イベントの議題はNeutron開発者の提案に基づいて作成され、会議のスケジュールはNeutron 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 Neutron
- Dockerの群れ
- Kubernetes
OVNアーキテクチャ
「75語でOVN。
Open Virtual NetworkはOVSプロジェクトによって運営され、元のOVSチームによって開発されました。この決定は、長年の経験に基づいてML2 / OVSコントロールプレーンを再設計する試みです。 OpenStackおよびKubernetesでの使用を目的としています。 OVNは、OpenFlowおよびOVSDBを介して通信するCデーモンを優先して、RabbitMQを介してNeutronAPIサービスと対話するPythonエージェントの概念を放棄した新しいアーキテクチャに基づいて構築されています。」 --Slawek Kaplonsky、Neutron PTL
当初、Neutron OVNドライバーは、Neutronスタジアム（networking-ovn）で別個のプロジェクトとして開発され、リリースではUssuriがメインのNeutronリポジトリに含まれていました。
したがって、このソリューションは、ML2 / OVSの主な問題であるRabbitMQを排除します。これは間違いなくプラスであり、一般に「OVNの設計目標は、かなりの規模で動作できる本番品質の実装を持つことです」。ただし、OVNはML2 / OVSを使用するときに使用できる機能をサポートしていますか？これは完全に真実ではないようであり、PTGに関する議論のトピックの1つになりました。その結果、いくつかのギャップが強調表示されました（完全なリストはプロジェクトページにあります）。まず、開発者は、ルーテッドネットワーク、一部のQoS機能、BGP、およびアベイラビリティーゾーンのサポートがないか不完全であることに気づきました。 OVNチームは上記のすべてを行う準備ができていますが、会議中に、内部の利益がより重要であったため、これは以前は優先事項ではなかったことを認めました。また、ML2 / OVSの開発はもちろん、一時停止しません。つまり、新しいスペースが表示される場合があります。
ただし、私の意見では、OVNの主な問題は、OVNがまだ広く使用されておらず、大規模なインストールでテストされていないことです。さらに、高可用性に関するいくつかの質問があります。
- 主要コンポーネントの1つであるovn-northdは、現在アクティブ/パッシブHAモードのみをサポートしており、アクティブ/アクティブはまだ計画中のみです
- もう1つの中心的なコンポーネントであるovsdb-serverも、アクティブ/パッシブモードのみをサポートします
OVS 2.9以降にovsdbクラスター（Raftアルゴリズムに基づく）のサポートが追加されたため、最後のポイントが実際に古くなっている可能性がありますが、これがOVNおよびOpenStackバージョンでテストされたかどうかは不明です。たとえば、openstack-ansible内の関連するチケットはまだ閉じられていません。
また、OVNがVxLANの代わりにGeneveトンネルを使用することも懸念されます。これは、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へのこの投資を活用してもらいたいと考えています。
現時点では、NeutronOVNドライバーはML2 / OVSと比較してサポートされている機能にギャップがありますが、私たちのチームはこれらのギャップを埋めようとしています。このドライバーはNeutronの将来になると考えているため、デフォルトのNeutronML2バックエンドにします。 DevStack。」
これまでのところ、このニュースに対する反応はかなり肯定的ですが、VxLANからGeneveトンネルへの移行、ML2OVSからML2OVNへの移行方法、およびパフォーマンスとサポートされている機能についてはまだ疑問があります。
新しいEngineFacadeの適用
EngineFacadeは、すべてのOpenStackプロジェクトで使用されるデータベースロジックを統合するsqlalchemy上のフレームワークです。数リリース前にリファクタリングが行われ、いわゆる「新しいEngineFacade」が登場しました。次のステップは、このフレームワークをOpenStackに適合させることでした。
私の意見では、このトピックに関する作業がいくつかのリリースで引き延ばされており、まだ完了していないという事実のために、このトピックはPTGアジェンダに含まれていました。このイベントの発生の理由は、大量の必要な変更、適応プロセスにおけるいくつかの重要な問題、そして私が思うに、モチベーションの欠如、したがって人的資源です。確かに、なぜすでに機能していて、たくさんのバグを出さないものを変更するのですか？この質問に対するかなり詳細な回答は、MikeBayer仕様に概説されています。ここでは、この長いテキストを読む必要がないように、EngineFacadeをサポートするための考慮事項の簡単な要約を示します。
- 古いEngineFacadeは、特定のユースケースに合わせて調整された高レベルのAPIではなく低レベルのAPIを提供するため、これは基本的にファクトリーではなくファクトリです。結果として：
- EngineFacade OpenStack
- , ,
- EngineFacade // : reader writer, , .
シンプルで論理的に聞こえますが、EngineFacadeの適応の問題は何ですか？正直なところ、詳細にはあまり触れませんでしたが、問題の主な原因は、いくつかの複雑なシナリオで、古いEngineFacadeがNeutronで誤用され、機能したこと（！）であるようです。また、新しいEngineFacadeはすべてを正しく実行しようとしていますが、それにもかかわらず、それは動作中のスクリプトを壊します（私の意見では、レガシーコードを操作するときのかなり典型的な問題です）。明らかに、この場合、最初にこれらのスクリプトのロジックを修正する必要があります。
実際、編集するものはそれほど多くなく、パッチは1つだけであり、コアチームはこの問題を共同で解決することに同意しました。もちろん、興味のある人は誰でも分析とレビューを手伝うことができます！
Neutron-lib
いくつかのトピックがneutron-libに捧げられています。まず、Neutronの開発にあまり関わっていない人にとってはどういうことかを思い出させてください。まず、Neutronは単一のプロジェクトではありません。実際、Neutronスタジアムという一般名でOpenStackネットワークのさまざまな領域で動作する複数のリポジトリで構成されており、「neutron」は主要なプロジェクトではありますが、1つにすぎません。残りのプロジェクトは、いわゆる高度なサービス（たとえば、neutron-lbaas、-fwaas、-vpnaas、-dynamic-routingなど）とサードパーティ/ベンダーのプラグイン（たとえば、networking-midonet、-odl、-ovn）です。このリストには、Neutron PTLとコアチームによって開発され、日常的に直接関与しているプロジェクトが含まれています。これを可能にするために、彼らは開発のすべての側面でスタジアム全体で一般的な原則と作業規則が守られていることを保証します-構造、開発、コードスタイル、テスト、文書化など。正直なところ、今日、これは完全に真実ではなく、主な負担は依然としてプロジェクトのメンテナの肩にかかっています。
Neuronu-libが作成される前は、すべてのネットワーキングプロジェクトは、すべての一般的なコード（定数、インターフェイス（抽象基本クラス）、ヘルパー関数など）をneutronメインリポジトリからインポートしていました。中性子のそのようなコードへの変更は、依存するプロジェクトを壊す可能性があります。次に、Ocataリリースでは、この問題を解決するためにneutron-libイニシアチブが開始されました。すべての一般的なコードは別のリポジトリに保存され、バージョン管理される必要があります。より具体的には、目標は次のように策定されました。
- Neutronからサブプロジェクトの依存関係を削除します（つまり、サブプロジェクトのneutronから直接インポートを削除します）
- 適切なneutron-libセクションでコードをリファクタリングするか、次善のパターンアーキテクチャを再設計して、Neutronで宿題をします。
実際、neutron-libはwin-winオプションのように見えます。結果として、メインのNeutronとサードパーティプロジェクトのサービスの両方が黒字になるはずです。何が悪かったのか？
サポートの欠如
貢献者とメンテナ、つまりプロジェクトに取り組む準備ができている人々のサポートなしには、オープンソースプロジェクトは存在できません。Neuronu-libの場合、そのようなボランティアが不足していたため、元のロジックが機能しなくなりました。中性子をインポートする代わりにインポートできるすべての一般的なコードがここに保存されるようにします。メインメンテナのneutron-lib（boden）は、しばらく前にプロジェクトを去りました。PTG中に、すべての一般的なコードをneutron-libに移植するというアイデアを放棄するか、neutron-libコードをneutronに移植するという提案がなされました。この提案は、次の2つの理由で合格しませんでした。
- neutron-libはまだ広く使用されています
- Neuronet-libは、複数のプロジェクトを一度に壊さないように変更できない標準インターフェースを強調するため、ある程度の価値があります
議論の後、neutron-libは変更されませんが、neutronコードの再配置と非推奨のポリシーを更新する必要があります。
もちろん、可能であれば、すべての新しいコードをneutronとneutron-libの間で共有する必要があります。そして、それは私たちに2番目の問題をもたらします。
テストの問題
もう1つの問題は、開発中のテストに関連しています。中性子のパッチの一部が新しい共有コードを導入したり、既存の共有コードを変更したりする場合は、ルールに従ってneutron-libに送信する必要があります。これにより、パッチの中性子部分がこれらのlibの変更に依存するようになります。ただし、neutronパッチは現在neutron-libのリリースバージョンでテストされており、最新リリースで動作することを確認しています。その結果、そのようなパッチはCIのテストに合格しません。
ウィザードのneutron-libコードを使用してすべてのneutronパッチをテストすることにも、いくつかの欠点があります。たとえば、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で個別のチェックを実行できます。しかし、投票できるのはそのうちの1人だけです。タスクの数を2倍にするだけで、OpenStackCIインフラストラクチャに大きな追加の負荷がかかります。
PTGでの議論中に、3つの提案がなされました。
- 「CIの確認」にはneutron-libウィザードを使用します。「GateCI」にはneutron-libリリースバージョンを使用します-ただし、neutronパッチが「CheckCI」チェックに合格して「GateCI」でクラッシュすると、奇妙に見えます
- 何も変更しないでください。neutron-libリリースバージョンでテストを実行することをお勧めします。たとえば、これはOSC（OpenStackClient）に対して実行されるようになりました。
- neutron-libウィザードでテストを実行し、neutron-libリリースでテストするための定期的なタスクを追加します
最終的な解決策：マスターブランチのneutron-libを使用して、「CheckCI」で新しい非投票の問題を作成します。基本的にはすべてそのままですが、neutronとneutron-libの変更を含む機能がマスターブランチにコミットする前にCIを通過することを確認することができます。
この記事がお役に立てば、Neutronがどこに向かっているのか、そしてその理由をよりよく理解するのに役立つことを願っています。
清聴ありがとうございました！