PTG (Project Team Gathering) ist eine Veranstaltung, bei der sich Entwicklungsteams treffen, um aktuelle Aufgaben, Status und Pläne zu besprechen. Vor einigen Jahren trennte sich die PTG vom Mainstream-OpenStack-Gipfel.
Die PTG wurde erstmals online über Zoom und Jitsi Meet abgehalten. Die Kombination von Bild und Ton in der Besprechung machte diese Änderung jedoch völlig unbemerkt, insbesondere vor dem Hintergrund der jetzt bekannten IRC-Teambesprechungen.
Die dreistündigen Neutronensitzungen dauerten von Dienstag bis Freitag. Die Hauptprotokolle der Besprechung werden auf OpenStack Etherpad und in der OpenStack-Mailingliste veröffentlicht. Die Tagesordnung der Veranstaltung wurde auf der Grundlage der Vorschläge der Neutron-Entwickler erstellt, und der Zeitplan für die Besprechung wurde von ihrem Vorsitzenden, PTL (Projektteamleiter) des Neutron Slawek Kaplonski-Teams, erstellt.
In diesem Artikel werde ich über 3 Themen sprechen, die meiner Meinung nach Beachtung verdienen und eine kleine Erklärung erfordern.
OVN
In dieser PTG wurde viel über OVN gesprochen, was nicht verwunderlich ist, da die meisten Mitglieder des Kernteams RedHat vertreten, den Hauptverantwortlichen für OVN.
Was ist OVN?
- Open Source L2 / L3-Netzwerkvirtualisierung für Open vSwitch (OVS):
- Logikschalter
- Logische IPv4- und IPv6-Router
- L2 / L3 / L4-ACLs (Sicherheitsgruppen)
- Mehrere Tunnelüberlagerungen (Geneve, STT und VXLAN)
- Logische Load Balancer
- TOR-basierte logisch-physikalische L2-Gateways
- Softwarebasierte logisch-physische L2 / L3-Gateways
- Funktioniert auf denselben Plattformen wie OVS:
- Linux
- Behälter
- DPDK
- Integration mit:
- OpenStack Neutron
- Hafenschwarm
- Kubernetes
OVN-Architektur
„OVN in 75 Worten.
Das Open Virtual Network wird vom OVS-Projekt betrieben und vom ursprünglichen OVS-Team entwickelt. Diese Entscheidung ist ein Versuch, die ML2 / OVS-Steuerebene auf der Grundlage jahrelanger Erfahrung neu zu gestalten. Es ist für die Verwendung mit OpenStack und Kubernetes vorgesehen. OVN basiert auf einer neuen Architektur, die das Konzept der Interaktion von Python-Agenten mit dem Neutron-API-Dienst über RabbitMQ zugunsten von C-Dämonen, die über OpenFlow und OVSDB kommunizieren, aufgegeben hat. “ - Slawek Kaplonsky, Neutron PTL.
Ursprünglich wurde der Neutron OVN-Treiber als separates Projekt im Neutron-Stadion entwickelt - Networking-Ovn - und in der Version wurde Ussuri in das Haupt-Neutron-Repository aufgenommen.
Somit beseitigt diese Lösung das Hauptproblem von ML2 / OVS - RabbitMQ, das zweifellos ein Plus darstellt, und im Allgemeinen besteht das Entwurfsziel von OVN darin, eine Implementierung in Produktionsqualität zu haben, die in erheblichem Umfang betrieben werden kann. Unterstützt OVN jedoch die bei Verwendung von ML2 / OVS verfügbaren Funktionen? Es scheint, dass dies nicht ganz stimmt, was zu einem der Diskussionsthemen der PTG wurde. Infolgedessen wurden mehrere Lücken hervorgehoben (eine vollständige Liste finden Sie auf der Projektseite). Zunächst stellten die Entwickler fest, dass geroutete Netzwerke, einige QoS-Funktionen, BGP und Verfügbarkeitszonen nicht oder nur unvollständig unterstützt werden. Obwohl das OVN-Team bereit ist, all das zu tun, gaben sie während des Treffens zu, dass dies für sie zuvor keine Priorität gewesen war - da interne Interessen wichtiger waren. Darüber hinaus ist die Entwicklung von ML2 / OVS natürlichpausiert nicht, was bedeutet, dass möglicherweise neue Leerzeichen angezeigt werden.
Meiner Meinung nach besteht das Hauptproblem bei OVN jedoch darin, dass es noch nicht weit verbreitet ist und nicht an großen Installationen getestet wurde. Darüber hinaus gibt es einige Fragen zur Hochverfügbarkeit:
- Eine der Hauptkomponenten, ovn-northd, unterstützt derzeit nur den Aktiv / Passiv-HA-Modus, Aktiv / Aktiv ist noch nur in den Plänen
- Eine weitere zentrale Komponente, ovsdb-server, unterstützt ebenfalls nur den Aktiv / Passiv-Modus
Es ist möglich, dass der letzte Punkt tatsächlich veraltet ist, da seit OVS 2.9 die Unterstützung für den ovsdb-Cluster (basierend auf dem Raft-Algorithmus) hinzugefügt wurde. Es ist jedoch nicht klar, ob dies in der Version mit OVN und OpenStack getestet wurde. Beispielsweise wurde das zugehörige Ticket in openstack-ansible noch nicht geschlossen.
Besorgniserregend ist auch, dass OVN Geneve-Tunnel anstelle von VxLANs verwendet, was sich auf die MTU-Einstellungen (Geneve-Header sind größer als VxLANs) und die Unterstützung der hardwarebeschleunigten Tunnelverarbeitung auswirkt.
Wie dem auch sei, das Projekt gewinnt schnell an Dynamik und es scheint, dass OVN in einigen Releases ein grundlegendes Neutron-Plugin werden sollte. Während der PTG stimmten die Entwickler des Kernteams zu, OVN zum Standard-Plugin für DevStack zu machen.
Wohin diese Änderungen führen werden:
- OpenStack Neutron CI,
- ML2/OVS ( )
- Neutron CI , ML2/Linuxbridge ML2/OVS – ,
- , core OVN
In Bezug auf den letzten Punkt hat Neutron PTL die folgende Meldung veröffentlicht: „Das Neutron-Team ist der Ansicht, dass OVN und der Neutron OVN-Treiber auf einer modernen Architektur basieren, die eine bessere Grundlage für eine einfachere und effizientere Lösung bietet. Wir sehen ein verstärktes Engagement in kubernetes-ovn, was zu einer Erweiterung der OVN-Kerngemeinschaft führt, und wir möchten, dass OpenStack diese Investition in OVN auch von Kubernetes nutzt.
Derzeit weist der Neutron OVN-Treiber im Vergleich zu ML2 / OVS Lücken in der unterstützten Funktionalität auf. Unser Team versucht jedoch, diese Lücken zu schließen. Wir glauben, dass dieser Treiber die Zukunft für Neutron sein wird, und möchten ihn daher zum Standard-Neutron ML2-Backend machen DevStack. "
Bisher ist die Reaktion auf diese Nachricht eher positiv, obwohl immer noch Zweifel am Übergang von VxLAN zu Geneve-Tunneln, an der Migration von ML2 OVS zu ML2 OVN sowie an der Leistung und den unterstützten Funktionen bestehen.
Anwendung der neuen EngineFacade
EngineFacade ist ein Framework über sqlalchemy, das die Datenbanklogik integriert, die in allen OpenStack-Projekten verwendet wird. Vor einigen Releases wurde ein Refactoring durchgeführt, das zum Erscheinen der sogenannten „neuen EngineFacade“ führte. Der nächste Schritt bestand darin, dieses Framework an OpenStack anzupassen.
Meiner Meinung nach wurde dieses Thema in die PTG-Agenda aufgenommen, da sich die Arbeit daran für mehrere Veröffentlichungen hinzog und noch nicht abgeschlossen war. Die Gründe für diese Entwicklung der Ereignisse sind eine Vielzahl notwendiger Änderungen, einige nicht triviale Probleme im Anpassungsprozess und meines Erachtens ein Mangel an Motivation und damit an Humanressourcen. Warum sollte man etwas ändern, das bereits funktioniert und nicht einmal eine Reihe von Fehlern auslöst? Eine ziemlich detaillierte Antwort auf diese Frage finden Sie in der Mike Bayer-Spezifikation. Hier werde ich versuchen, eine kurze Zusammenfassung der Überlegungen zur Unterstützung von EngineFacade zu geben, damit Sie diesen langen Text nicht lesen müssen:
- Die alte EngineFacade bietet Low-Level-APIs anstelle von High-Level-APIs, die auf einen bestimmten Anwendungsfall zugeschnitten sind. Dies ist also im Wesentlichen eine Fabrik und keine Fassade. Ergebend:
- EngineFacade OpenStack
- , ,
- EngineFacade // : reader writer, , .
Klingt einfach und logisch. Was ist dann das Problem mit der EngineFacade-Anpassung? Um ehrlich zu sein, habe ich nicht viel auf die Details eingegangen, aber es scheint, dass die Hauptursache für die Probleme darin besteht, dass in einigen komplexen Szenarien die alte EngineFacade in Neutron missbraucht wurde und funktioniert hat (!), Und die neue EngineFacade versucht, alles richtig zu machen, aber Trotzdem werden funktionierende Skripte beschädigt (meiner Meinung nach ein ziemlich typisches Problem bei der Arbeit mit Legacy-Code). In diesem Fall müssen Sie natürlich zuerst die Logik dieser Skripte korrigieren.
Tatsächlich bleibt nicht mehr so viel zu bearbeiten - nur ein Patch, und das Kernteam stimmte zu, dieses Problem gemeinsam zu lösen. Natürlich kann jeder Interessierte bei der Analyse und Überprüfung helfen!
Neutron-lib
Mehrere Themen wurden der Neutronen-Lib gewidmet. Lassen Sie mich zunächst daran erinnern, was es für diejenigen ist, die nicht stark an der Entwicklung von Neutronen beteiligt sind. Erstens ist Neutron kein einzelnes Projekt - es besteht aus mehreren Repositories, die in verschiedenen Bereichen des OpenStack-Netzwerks unter dem allgemeinen Namen Neutron Stadium arbeiten, und „Neutron“ ist nur eines, wenn auch ein großes Projekt. Der Rest der Projekte sind die sogenannten Advanced Services (z. B. Neutronen-LBAAS, -Fwaas, -VPNAAS, -Dynamic-Routing usw.) und Plugins von Drittanbietern / Anbietern (z. B. Networking-Midonet, -odl, -ovn). Diese Liste enthält Projekte, die von Neutron PTL und dem Kernteam entwickelt wurden und täglich direkt daran beteiligt sind. Um dies zu ermöglichen, stellen sie sicher, dass die allgemeinen Grundsätze und Arbeitsregeln im gesamten Stadion in allen Aspekten der Entwicklung eingehalten werden - Struktur,Entwicklung, Codestil, Testen, Dokumentieren usw. Um ehrlich zu sein, ist dies heute nicht ganz richtig, und die Hauptlast liegt immer noch auf den Schultern des Projekts der Instandhalter.
Bevor neutron-lib erstellt wurde, importierten alle Netzwerkprojekte den gesamten gängigen Code - Konstanten, Schnittstellen (abstrakte Basisklassen), Hilfsfunktionen und mehr - aus dem Neutronen-Hauptrepository. Änderungen an diesem Code in Neutronen können abhängige Projekte beschädigen. In der Ocata-Version wurde dann die Neutron-lib-Initiative gestartet, um dieses Problem zu lösen: Der gesamte gängige Code sollte jetzt in einem separaten Repository gespeichert und versioniert werden. Insbesondere wurden die Ziele wie folgt formuliert:
- Entfernen Sie die Abhängigkeit von Teilprojekten von Neutronen (d. H. Entfernen Sie direkte Importe von Neutronen in Teilprojekten).
- Machen Sie Ihre Hausaufgaben in Neutron, indem Sie den Code umgestalten oder die suboptimale Musterarchitektur in den entsprechenden neutron-lib-Abschnitten neu gestalten
Tatsächlich sieht neutron-lib wie eine Win-Win-Option aus: Sowohl das Haupt-Neutron als auch die Dienste von Projekten von Drittanbietern sollten daher schwarze Zahlen schreiben. Was schief gelaufen ist?
Fehlende Unterstützung
Kein Open-Source-Projekt kann ohne die Unterstützung von Mitwirkenden und Betreuern existieren - Menschen, die bereit sind, ihre Zeit in die Arbeit an einem Projekt zu investieren. Für neutron-lib fehlten solche Freiwilligen, und infolgedessen funktionierte die ursprüngliche Logik nicht mehr, d. H. Damit wird hier der gesamte gemeinsame Code gespeichert, der importiert werden kann, anstatt Neutronen zu importieren. Der Hauptbetreuer neutron-lib (boden) hat das Projekt vor einiger Zeit verlassen. Während der PTG wurde vorgeschlagen, die Idee aufzugeben, den gesamten gängigen Code auf Neutron-Lib zu portieren oder sogar den Neutron-Lib-Code zurück auf Neutron zu portieren. Dieser Vorschlag wurde aus zwei Gründen nicht angenommen:
- Neutronen-Lib ist immer noch weit verbreitet
- neutron-lib hat einen gewissen Wert, da es Standardschnittstellen hervorhebt, die nicht geändert werden können, um nicht mehrere Projekte gleichzeitig zu beschädigen
Nach der Diskussion bleibt neutron-lib unverändert, aber die Neutronencode-Verschiebungs- und Verfallsrichtlinie muss aktualisiert werden.
Natürlich sollte der gesamte neue Code nach Möglichkeit zwischen Neutron und Neutron-Lib geteilt werden. Und das bringt uns zum zweiten Problem.
Testproblem
Ein weiteres Problem betrifft das Testen während der Entwicklung. Wenn ein Teil eines Patches in Neutron neuen Code einführt oder vorhandenen gemeinsam genutzten Code ändert, sollte er durch Regeln an neutron-lib gesendet werden. Dies macht den Neutronenteil des Patches abhängig von diesen lib-Änderungen. Die Neutronen-Patches werden derzeit jedoch auf der Release-Version von neutron-lib getestet, um zu überprüfen, ob sie mit der neuesten Version funktionieren. Infolgedessen bestehen solche Patches keine Tests in CI.
Das Testen aller Neutronen-Patches mit Neutronen-Lib-Code aus dem Assistenten hat auch einige Nachteile. Beispielsweise gibt es keine Garantie dafür, dass der Neutronenassistent mit der neuesten neutron-lib-Version funktioniert, die Endbenutzer verwenden.
Hier sind die Möglichkeiten, um dieses Problem zu beheben (danke an Bence Romsics für die hervorragende Zusammenfassung):
- , , neutron-lib , neutron .
- , :
- , “foo” neutron-lib, . neutron , “_foo” TODO , , neutron-lib.
- neutron-lib , neutron, _foo “import _foo” “from neutron-lib import foo”.
- Darüber hinaus können Sie CI sowohl mit dem Assistenten als auch mit der neuesten Version von neutron-lib separat prüfen. Aber nur einer von ihnen kann wählen. Durch einfaches Verdoppeln der Anzahl der Aufgaben wird die OpenStack CI-Infrastruktur erheblich zusätzlich belastet.
Während der Diskussion in der PTG wurden drei Vorschläge gemacht:
- Verwenden Sie den Neutronen-Lib-Assistenten für "CI überprüfen". Verwenden Sie die Neutron-Lib-Release-Version für "Gate CI". Wenn der Neutronen-Patch jedoch die "Check CI" -Prüfungen besteht und auf "Gate CI" abstürzt, sieht es seltsam aus
- Ändern Sie nichts: Am besten führen Sie Tests mit der neutron-lib-Release-Version durch. Dies wird jetzt beispielsweise für OSC (OpenStackClient) durchgeführt.
- Führen Sie Tests mit dem Neutron-Lib-Assistenten aus und fügen Sie eine regelmäßige Aufgabe für Tests mit der Neutron-Lib-Version hinzu
Endgültige Lösung: Erstellen Sie mit neutron-lib aus dem Hauptzweig ein neues nicht stimmberechtigtes Problem in „Check CI“. Grundsätzlich bleibt alles so, wie es ist, aber es wird möglich sein zu überprüfen, ob eine Funktion, die Änderungen in Neutron und Neutronen-Lib enthält, CI durchläuft, bevor sie an den Hauptzweig übergeben wird.
Ich hoffe, dieser Artikel war hilfreich und hat Ihnen geholfen, besser zu verstehen, wohin und warum Neutron unterwegs ist.
Vielen Dank für Ihre Aufmerksamkeit!