[ English | Indonesia | Deutsch | 日本語 ]
Arbeiten mit Plänen¶
Die gute Nachricht: OpenStack hat eine beispiellose Transparenz, wenn es darum geht, Informationen darüber bereitzustellen, was auf uns zukommt. Die schlechte Nachricht: Jedes Release bewegt sich sehr schnell. Der Zweck dieses Anhangs ist es, einige der nützlichen Seiten hervorzuheben, die zu verfolgen sind, und eine fundierte Vermutung darüber anzustellen, was in der nächsten Version und vielleicht auch darüber hinaus auftaucht.
OpenStack folgt einem sechsmonatigen Release-Zyklus, der in der Regel im April/Mai und Oktober/November eines jeden Jahres erscheint. Zu Beginn eines jeden Zyklus versammelt sich die Community an einem einzigen Ort zu einem Project Teams Gathering (PTG). Im PTG werden die Features für die kommenden Releases diskutiert, priorisiert und geplant. Die folgende Abbildung zeigt einen exemplarischen Release-Zyklus mit Datumsangaben für Meilenstein-Releases, Code Freeze und String Freeze Datumsangaben sowie ein Beispiel dafür, wann der Summit stattfindet. Meilensteine sind Zwischenfreigaben innerhalb des Zyklus, die als Pakete zum Herunterladen und Testen zur Verfügung stehen. Das Einfrieren von Code stoppt das Hinzufügen neuer Funktionen zur Version. Das Einfrieren von Zeichenketten stoppt die Änderung von Zeichenketten im Quellcode.
Informationen, die Ihnen zur Verfügung stehen¶
Es gibt mehrere gute Informationsquellen, die Sie verwenden können, um Ihre OpenStack-Entwicklungswünsche zu verfolgen.
Beeinflussung der Roadmap¶
OpenStack begrüßt Ihre Ideen (und Beiträge) und schätzt das Feedback von Anwendern der Software aus der Praxis sehr. Indem Sie ein wenig über den Prozess lernen, der die Entwicklung von Funktionen antreibt, können Sie teilnehmen und vielleicht die gewünschten Ergänzungen erhalten.
Feature-Anfragen beginnen in der Regel ihr Leben in Etherpad, einem kollaborativen Bearbeitungswerkzeug, mit dem Koordinierungsnotizen bei einer funktionsbezogenen Design-Gipfel-Sitzung gemacht werden. Dies führt dann zur Erstellung eines Blueprints auf der Launchpad-Seite für das jeweilige Projekt, mit dem das Feature formeller beschrieben wird. Die Blueprints werden dann von den Mitgliedern des Projektteams genehmigt, und die Entwicklung kann beginnen.
Daher ist der schnellste Weg, Ihre Feature-Anfrage zur Prüfung zu stellen, ein Etherpad mit Ihren Ideen zu erstellen und im PTG eine Sitzung vorzuschlagen. Wenn der PTG bereits gehalten wurde, können Sie auch direkt eine Blueprint erstellen. Lesen Sie diesen Blogbeitrag über die Arbeit mit Blueprints aus der Perspektive von Victoria Martínez, einer Praktikantin für Entwickler.
Die Roadmap für das nächste Release, wie sie entwickelt wird, ist unter Releases zu finden.
Um die potenziellen Funktionen für zukünftige Versionen zu ermitteln oder um die zuvor implementierten Funktionen zu betrachten, werfen Sie einen Blick auf die vorhandenen Blueprints wie OpenStack Compute (nova) Blueprints, OpenStack Identity (keystone) Blueprints und Release Notes.
Neben dem Direct-to-Blueprint-Pfad gibt es noch einen weiteren sehr angesehenen Mechanismus, der die Entwicklungs-Roadmap beeinflusst: die Benutzerbefragung. Sie finden es unter OpenStack User Survey und können Details zu Ihren Implementierungen und Anforderungen angeben, standardmäßig anonym. In jedem Zyklus analysiert das Benutzerkomitee die Ergebnisse und erstellt einen Bericht, einschließlich spezifischer Informationen für den technischen Ausschuss und die Projektteamleiter.
Zu beachtende Aspekte¶
Sie möchten ein Auge auf die Bereiche werfen, die sich in OpenStack verbessern. Der beste Weg, Roadmaps für jedes Projekt zu „sehen“, besteht darin, sich die Blueprints anzusehen, die für die Arbeit an Meilenstein-Releases genehmigt werden. Sie können auch von PTL-Webinaren lernen, die zweimal im Jahr die OpenStack-Summites verfolgen.
Verbesserungen der Treiberqualität¶
Ein wichtiger Qualitätsschub hat sich bei Treibern und Plugins in den Bereichen Block Storage, Compute und Networking ergeben. Insbesondere Entwickler von Compute- und Netzwerktreibern, die proprietäre oder Hardwareprodukte benötigen, müssen nun ein automatisiertes externes Testsystem für den Einsatz im Entwicklungsprozess bereitstellen.
Einfachere Upgrades¶
Eines der gefragtesten Features seit Beginn von OpenStack (für andere Komponenten als Object Storage, das dazu neigt, „nur zu funktionieren“): einfachere Upgrades. In allen aktuellen Versionen wird die interne Messaging-Kommunikation versioniert, was bedeutet, dass Dienste theoretisch auf rückwärtskompatibles Verhalten zurückfallen können. Dies ermöglicht es Ihnen, spätere Versionen einiger Komponenten auszuführen, während Sie ältere Versionen anderer Komponenten beibehalten.
Darüber hinaus werden nun Datenbankmigrationen mit dem Turbo Hipster Tool getestet. Dieses Tool testet die Leistung der Datenbankmigration auf Kopien von realen Benutzerdatenbanken.
Diese Änderungen haben den ersten richtigen OpenStack-Upgrade-Leitfaden erleichtert, der in Upgrades zu finden ist, und werden in der nächsten Version weiter verbessert.
Verwerfung des Nova-Netzwerks¶
Mit der Einführung des vollständigen softwaredefinierten Netzwerkstacks von OpenStack Networking (Neutron) in der Folsom-Version hat sich der Entwicklungsaufwand für den anfänglichen Netzwerkcode, der Teil der Compute-Komponente bleibt, allmählich verringert. Während viele von ihnen immer noch Nova-Netzwerk in der Produktion verwenden, gibt es einen langfristigen Plan, den Code zugunsten des flexibleren und vollwertigeren OpenStack-Netzwerks zu entfernen.
Es wurde versucht, das Nova-Netzwerk während der Havanna-Version zu verwerfen, was aufgrund fehlender gleichwertiger Funktionen (wie dem in diesem Leitfaden erwähnten FlatDHCP-Multi-Host-Hochverfügbarkeitsmodus), des Fehlens eines Migrationspfades zwischen Versionen, unzureichender Tests und der Einfachheit bei Verwendung für die einfacheren Anwendungsfälle des traditionell unterstützten Nova-Netzwerkes abgebrochen wurde. Obwohl erhebliche Anstrengungen unternommen wurden, um diesen Bedenken entgegenzuwirken, wurde das Nova-Netzwerk in der Juno-Version nicht veraltet. Darüber hinaus haben in begrenztem Umfang Patches für Nova-Netzwerk wieder begonnen, akzeptiert zu werden, wie z.B. das Hinzufügen einer Funktion für die Einstellungen pro Netzwerk und die SR-IOV-Unterstützung in Juno.
Dies gibt Ihnen einen wichtigen Entscheidungspunkt bei der Gestaltung Ihrer Cloud. OpenStack Networking ist robust genug, um mit einer kleinen Anzahl von Einschränkungen verwendet zu werden (Performance-Probleme in einigen Szenarien, nur grundlegende Hochverfügbarkeit von Layer-3-Systemen) und bietet viel mehr Funktionen als Nova-Netzwerk. Wenn Sie jedoch nicht über die komplexeren Anwendungsfälle verfügen, die von vollständigeren, softwaredefinierten Netzwerkfunktionen profitieren können, oder wenn Sie sich mit den neuen Konzepten nicht wohl fühlen, kann nova-network für die nächsten 12 Monate weiterhin eine brauchbare Option sein.
Wenn Sie eine bestehende Cloud haben und ein Upgrade von nova-network auf OpenStack Networking durchführen möchten, sollten Sie die Option haben, das Upgrade um diesen Zeitraum zu verschieben. Jede Version von OpenStack bringt jedoch bedeutende neue Innovationen mit sich, und unabhängig von der Verwendung der Netzwerkmethodik ist es wahrscheinlich am besten, die Planung für ein Upgrade innerhalb eines angemessenen Zeitraums nach jeder Version zu beginnen.
Wie bereits erwähnt, gibt es derzeit keine Möglichkeit, sauber vom ``Nova-Netzwerk``zum Neutron zu migrieren. Wir empfehlen Ihnen, eine Migration im Auge zu behalten und zu berücksichtigen, was dieser Prozess beinhalten könnte, wenn ein geeigneter Migrationspfad freigegeben wird.
Distributed Virtual Router (DVR)¶
Eine der langjährigen Beschwerden rund um OpenStack Networking war die mangelnde Hochverfügbarkeit der Layer-3-Komponenten. Mit der Juno-Version wurde der Distributed Virtual Router (DVR) eingeführt, der dieses Problem lösen soll.
Erste Anzeichen deuten darauf hin, dass sie dies für eine Reihe von Szenarien gut tut, wie z.B. die Verwendung des ML2-Plugins mit Open vSwitch, einem flachen externen Netzwerk und VXLAN-Mieternetzen. Es scheint jedoch, dass es Probleme mit der Verwendung von VLANs, IPv6, Floating IPs, Szenarien mit hohem Nord-Süd-Verkehr und einer großen Anzahl von Compute-Knoten gibt. Es wird erwartet, dass sich diese mit dem nächsten Release deutlich verbessern werden, aber Fehlerberichte zu bestimmten Themen sind sehr wünschenswert.
Austausch des Open vSwitch Plugins durch Modular Layer 2¶
Das Modular Layer 2 Plug-in ist ein Framework, das es OpenStack Networking ermöglicht, die Vielfalt der Layer-2-Netzwerktechnologien in komplexen Rechenzentren gleichzeitig zu nutzen. Es arbeitet derzeit mit den bestehenden Open vSwitch-, Linux Bridge- und Hyper-V L2-Agenten und soll die monolithischen Plug-Ins dieser L2-Agenten ersetzen und verwerfen.
Neue API-Versionen¶
Die dritte Version der Compute API wurde während der Release-Zyklen von Havanna und Icehouse ausführlich diskutiert und bearbeitet. Aktuelle Diskussionen deuten darauf hin, dass die V2-API für viele Releases bestehen bleiben wird, und die nächste Iteration der API wird v2.1 genannt und hat ähnliche Eigenschaften wie die bestehende v2.0 und nicht wie eine völlig neue v3-API. Dies ist ein guter Zeitpunkt, um alle APIs zu evaluieren und Kommentare abzugeben, während die APIs der nächsten Generation definiert werden. Eine neue Arbeitsgruppe wurde speziell gebildet, um die OpenStack-APIs zu verbessern und Designrichtlinien zu erstellen, denen Sie gerne beitreten können.
OpenStack auf OpenStack (TripleO)¶
Dieses Projekt verbessert sich weiter und Sie können es für den Einsatz auf der grünen Wiese in Betracht ziehen, obwohl es nach den neuesten Ergebnissen der Benutzerbefragung nach wie vor eine breite Akzeptanz findet.
Datenverarbeitungsdienst für OpenStack (Sahara)¶
Als begehrte Antwort auf große Datenprobleme hat ein engagiertes Team bei einem Hadoop-as-a-Service Projekt gute Fortschritte gemacht.
Bare Metal Deployment (ironic)¶
Der Bare-Metal-Einsatz wurde allgemein gelobt, und die Entwicklung geht weiter. Die Juno-Version brachte das OpenStack Bare-Metal-Laufwerk in das Compute-Projekt ein, und es wurde versucht, den vorhandenen Bare-Metal-Treiber in Kilo zu verwerfen. Wenn Sie ein aktueller Benutzer des Bare-Metal-Treibers sind, ist ein besonderer Plan zu folgen: Den Bare-Metal-Treiber verwerfen
Datenbank als Dienst (trove)¶
Die OpenStack-Community hat seit einiger Zeit ein Datenbank-as-a-Service-Tool in Entwicklung, und wir haben die erste integrierte Version davon in Icehouse gesehen. Seit seinem Release war es in der Lage, Datenbankserver direkt nach dem Auspacken hochverfügbar einzusetzen, wobei zunächst nur MySQL unterstützt wurde. Juno führte die Unterstützung für Mongo (einschließlich Clustering), PostgreSQL und Couchbase ein, zusätzlich zu den Replikationsfunktionen für MySQL. In Kilo wurde eine erweiterte Clustering-Funktionalität sowie eine bessere Integration mit anderen OpenStack-Komponenten wie Networking bereitgestellt.
Message Service (zaqar) [Nachrichtendienst (zaqar)]¶
Ein Dienst zum Bereitstellen von Warteschlangen von Nachrichten und Benachrichtigungen wurde freigegeben.
DNS Dienst (designate)¶
Ein seit langem angeforderter Dienst, der die Möglichkeit bietet, DNS-Einträge zu manipulieren, die mit OpenStack-Ressourcen verknüpft sind, hat folgendes gesammelt. Das Designate-Projekt wurde ebenfalls freigegeben.
Verbesserungen des Schedulers¶
Sowohl Compute als auch Block Storage verlassen sich auf Scheduler, um festzulegen, wo virtuelle Maschinen oder Volumes platziert werden sollen. In Havanna wurde der Compute Scheduler deutlich verbessert, während in Icehouse der Scheduler im Block Storage einen Schub erhielt. Weiter unten auf der Strecke begann eine Anstrengung diesen Zyklus, der darauf abzielt, einen ganzheitlichen Planer zu schaffen, der beides abdeckt. Einige der Arbeiten, die in Kilo durchgeführt wurden, finden Sie unter dem Gantt-Projekt.
Verbesserungen bei der Blockspeicherung¶
Block Storage gilt als ein stabiles Projekt mit einer breiten Akzeptanz und einer langen Erfolgsgeschichte von Qualitätsfaktoren. Das Team hat auf den Summits viele Arbeitsbereiche diskutiert, darunter bessere Fehlerberichte, automatisierte Erkennung und Thin Provisioning-Funktionen.
Auf dem Weg zu einem Python SDK¶
Obwohl viele erfolgreich die verschiedenen Python-*Client-Codes als effektives SDK für die Interaktion mit OpenStack verwenden, nimmt die Konsistenz zwischen den Projekten und der Verfügbarkeit der Dokumentation zu. Um dies zu bekämpfen, hat ein Bemühung, die Erfahrung zu verbessern, begonnen. Projektübergreifende Entwicklungsbemühungen in OpenStack haben eine wechselnde Historie, wie z.B. das Unified Client Project mit mehreren Fehlstarts. Die ersten Anzeichen für das SDK-Projekt sind jedoch vielversprechend, und wir erwarten Ergebnisse während des Juno-Zyklus.
