[ English | Indonesia | русский | English (United Kingdom) | français | 한국어 (대한민국) | Deutsch ]

Richtlinien für Mitwirkende

Vor dem Absenden des Codes

Bevor Sie vorwärts springen und an Code arbeiten, sollten Sie eine Reihe von Schritten durchführen:

  • Gibt es einen Bug dafür? Kann man Ihren Track verfolgen, wenn jemand anders den gleichen Bug gesehen hat?

  • Sind Sie sicher, dass momentan niemand an diesem Problem arbeitet? Könnte es eine Überprüfung bis zum gleichen Problem geben?

  • Haben Sie überprüft, ob Ihre Anfrage/Funktion in einer anderen Branch nicht gelöst wurde?

Wenn Sie Code einreichen möchten, beachten Sie bitte die folgenden Regeln:

Überprüfungsprozess

Jeder neue Code wird vor dem Zusammenführen in unsere Repositories überprüft.

Wir befolgen die Openstack-Richtlinien für die Code-Überprüfung <https://docs.openstack.org/project-team-guide/review-the-openstack-way.html>`_ Prozess.

Bitte beachten Sie, dass ein Patch von der Community abgelehnt werden kann, wenn sie nicht mit den folgenden Regeln übereinstimmt Allgemeine Richtlinien für die Einreichung von Code.

Arbeiten an Bugfixes

Jeder Bugfix sollte in seiner Commit-Nachricht enthalten sein:

Closes-Bug: #Bugnummer

oder

Related-Bug: #bugnumber

Dabei steht #bugnumber für ein Launchpad-Problem.

Siehe auch den Abschnitt working on bugs in der openstack-Dokumentation.

Arbeiten an neuen Funktionen

Wenn Sie zu einer Rolle bei der Einführung eines OpenStack- oder Infrastrukturdienstes beitragen oder eine bestehende Rolle verbessern möchten, würde das OpenStack-Ansible-Projekt diesen Beitrag und Ihre Unterstützung bei der Wartung begrüßen.

Hier sind ein paar Regeln um loszulegen:

  • Alle großen Hinzufügungen/Löschungen von Features sollten von einem Blueprint/Spec begleitet werden. z.B. Hinzufügen neuer aktiver Agenten zu Neutron, Entwickeln einer neuen Service-Rolle, etc … Siehe auch Einreichen einer Spezifikation.

  • Bevor ein Blueprint/Spec erstellt wird, kann ein entsprechender ‚Wishlist Bug‘ auf dem Launchpad ausgelöst werden. Dieses Problem wird geprüft und es wird eine Entscheidung darüber getroffen, wie groß die Änderung ist und ob die Änderung einen Entwurf/eine Spezifikation rechtfertigt. Beide Funktionen und Fehlerbehebungen erfordern möglicherweise die Erstellung eines Blueprints/einer Spezifikation. Über diese Anforderung werden die Kernüberprüfer abstimmen und auf der Größe und den Auswirkungen der Änderung basieren.

  • Alle Blueprints/Spezifikationen sollten abgestimmt und von Core-Reviewern genehmigt werden, bevor der zugehörige Code zusammengeführt wird. Für weitere Informationen zu Blueprints/Spezifikationen lesen Sie bitte die OpenStack-Dokumentation bezüglich Working on Specifications and Blueprints und unsere eigenen Einreichen einer Spezifikation.

  • Sobald die Blueprint-Arbeit abgeschlossen ist, können die Autoren einen Backport der Blueprint-Arbeit in einen stabilen Branch anfordern. Jeder Backport wird von Fall zu Fall mit vorsichtiger Abwägung beurteilt, basierend darauf, wie sich der Backport auf vorhandene Bereitstellungen auswirkt. Weitere Informationen finden Sie im Abschnitt Rückportierung.

  • Alle neuen OpenStack-Dienste, die Tempest-Tests enthalten, müssen zusammen mit geeigneten Funktionstests, die im Rahmen der Feature-Entwicklung aktiviert wurden, implementiert werden, um sicherzustellen, dass Änderungen an der Codebasis die Service-Funktionalität nicht beeinträchtigen.

  • Feature-Ergänzungen müssen eine Dokumentation enthalten, die einen Verweis auf die OpenStack-Dokumentation über das Feature und seine Funktionsweise enthält. Die Dokumentation sollte dann beschreiben, wie es in OpenStack-Ansible implementiert ist und welche Konfigurationsoptionen es gibt. Siehe auch den Abschnitt Dokumentation und Release Note Richtlinien.

Beispielprozess zum Entwickeln einer neuen Rolle

Hier sind die Schritte zum Schreiben der Rolle:

  1. Sie können Rollen überprüfen, die sich gerade in der Entwicklung befinden, indem Sie auf review.openstack.org unser specs repository und die unmerged specs überprüfen. Wenn Sie keine Spezifikation für die Rolle finden, schlagen Sie einen Entwurf/eine Spezifikation vor. Siehe auch Einreichen einer Spezifikation.

  2. Erstellen Sie ein Quell-Repository (z. B. auf Github), um mit der Arbeit an der Rolle zu beginnen.

  3. Generieren Sie die Referenzverzeichnisstruktur für eine Ansible-Rolle, die die erforderliche Teilmenge der dokumentierten Best Practice ist. Sie können Ansible Galaxy Tools verwenden, um dies für Sie zu tun (z.B. ansible-galaxy init). Sie können zusätzlich Verzeichnisse wie docs und examples und tests für Ihre Rolle hinzufügen.

  4. Erzeugen Sie sofort eine meta/main.yml. Diese Datei ist für Ansible wichtig, um sicherzustellen, dass Ihre abhängigen Rollen installiert und verfügbar sind, und bietet anderen die Informationen, die sie benötigen, um den Zweck Ihrer Rolle zu verstehen.

  5. Entwickeln Sie für jede Installationsphase nacheinander Taskdateien, und erstellen Sie nach Bedarf Handler und Vorlagen. Stellen Sie sicher, dass Sie die Handler nach jeder Aufgabe benachrichtigen, die sich auf die Art und Weise der Ausführung des Dienstes auswirkt (z.B. Änderungen der Konfigurationsdatei). Achten Sie auch darauf, dass der Dateibesitz und die Berechtigungen angemessen sind.

    Hinweis

    Füllen Sie die Standardwerte, Bibliotheken und Voraussetzungen für Variablen aus, wenn Sie diese benötigen. Sie können auch gleichzeitig Dokumentation für Ihre Rolle entwickeln.

  6. Fügen Sie der Rolle Tests hinzu. Siehe auch unsere Seite Testen.

  7. Sicherstellen, dass die Rolle den neuesten Standards von OpenStack-Ansible entspricht. Siehe auch unsere Code Regeln Seite.

  8. Stellen Sie sicher, dass die Rolle konvergiert:

    • Implementiere developer_mode, um von einer Git-Quelle in eine virtuelle Python-Umgebung zu wechseln.

    • Stellen Sie die entsprechenden Konfigurationsdateien an den richtigen Stellen bereit.

    • Stellen Sie sicher, dass der Dienst gestartet wird.

    Die Konvergenz kann den Konsum anderer OpenStack-Ansible-Rollen beinhalten (zum Beispiel: galera_server, galera_client, rabbitmq_server), um sicherzustellen, dass die entsprechende Infrastruktur vorhanden ist. Die Wiederverwendung vorhandener Rollen in OpenStack-Ansible oder Ansible Galaxy wird dringend empfohlen.

  9. Sobald die anfängliche Konvergenz funktioniert und die Dienste ausgeführt werden, sollte sich die Rollenentwicklung auf die Implementierung einiger Funktionstests konzentrieren. Siehe auch Verbessere das Testen mit tempest.

  10. Testen Sie die Rolle auf einem neuen Computer mit unseren bereitgestellten Skripts.

  11. Reichen Sie Ihre Rolle zur Überprüfung ein.

  12. Fordern Sie ggf. die OpenStack-Ansible-PTL auf, die Github-Rolle in den Openstack-ansible-Namespace zu importieren (Dies kann nur zu einem frühen Zeitpunkt im Entwicklungszyklus erfolgen und kann auf den nächsten Zyklus verschoben werden).

  13. Arbeiten Sie bei Bedarf an der Integration in das integrierte Repository von openstack-ansible und stellen Sie die Rolle auf einem AIO bereit. Siehe auch Testen einer neuen Rolle mit einem AIO.

Beispielprozess zum Hinzufügen eines Features zu einer vorhandenen Rolle

  1. Suchen Sie im OpenStack-Ansible Launchpad-Projekt nach der Feature-Anforderung.

  2. Wenn im Launchpad für Ihre Funktion kein Wunschzettel-Eintrag vorhanden ist, erstellen Sie einen Fehler dafür. Zögern Sie nicht zu fragen, ob eine Spezifikation in dem Fehler benötigt wird.

  3. Das Fehlersuche wird klassifiziert, wenn diese neue Funktion eine Spezifikation erfordert oder nicht.

  4. Arbeiten Sie an den Role-Dateien, folgen Sie unserem Code Regeln.

  5. Fügen Sie ein zusätzliches Rollen-Testszenario hinzu, um sicherzustellen, dass Ihr Code-Pfad getestet wird und funktioniert.

  6. Testen Sie Ihr neues Szenario mit einer neuen Maschine. Siehe auch die Seite Tests lokal ausführen.

  7. Senden Sie den Code zur Überprüfung mit den erforderlichen Dokumentationen und Versionshinweisen ein.

Beispielprozess zum Inkubieren eines neuen ops -Projekts

Ein neues Projekt in openstack-ansible-ops kann jederzeit gestartet werden, ohne Einschränkungen wie das Schreiben einer Spezifikation oder das Erstellen eines Fehlers.

Stattdessen muss der neue Code in einem separaten Ordner des openstack-ansible-ops repo isoliert werden.

Rückportierung

  • Backporting ist definiert als der Vorgang, eine Änderung von einem anderen Branch zu reproduzieren. Unsaubere/gesquashte/modifizierte Cherry-Picks und vollständige Reimplementierungen sind in Ordnung.

  • Backporting wird oft mit dem gleichen Code durchgeführt (via Cherry Picking), aber das ist nicht immer der Fall. Diese Methode wird bevorzugt, wenn der Cherry-Pick eine vollständige Lösung für das angestrebte Problem bietet.

  • Wenn Sie einen Commit von einem Branch zu einem anderen auswählen, sollte die Commit-Nachricht mit allen Dateien geändert werden, die möglicherweise während der Durchführung des Cherry-Pick-Vorgangs in Konflikt standen. Außerdem sollten Cherry-Pick-Commit-Nachrichten den ursprünglichen Commit SHA am Ende der neuen Commit-Nachricht enthalten. Dies kann mit cherry-pick -x gemacht werden. Weitere Informationen finden Sie unter Submitting a change to a branch for review.

  • Jedes Backport-Commit muss immer noch nur ein Problem lösen, wie in den Richtlinien in Allgemeine Richtlinien für die Einreichung von Code.

  • Wenn ein Backport ein gesquaschtes Set von cherry-picked Commits ist, sollten die ursprünglichen SHAs in der Commit-Nachricht referenziert werden und der Grund für das Quetschen der Commits sollte klar erklärt werden.

  • Wenn ein Cherry-Pick in irgendeiner Weise verändert wird, müssen die vorgenommenen Änderungen und die Gründe dafür explizit in der Commit-Nachricht ausgedrückt werden.

  • Refactoring-Arbeiten dürfen nicht in einen freigegebenen Branch zurückportiert werden.

  • Backport-Überprüfungen sollten unter Berücksichtigung der Auswirkungen des Patches auf vorhandene Umgebungen, die von OpenStack-Ansible bereitgestellt werden, durchgeführt werden. Die allgemeinen OpenStack Guidelines for stable branches können als Referenz verwendet werden.