Veröffentlichungen¶

Was ist das OSA-Versionsmodell?¶

OpenStack-Ansible (OSA) verwendet das Cycle-Trailing-Release-Modell, wie es im OpenStack Release Model Reference_ spezifiziert ist.

Wie werden Release-Tags festgelegt?¶

Um ein gemeinsames Verständnis der Release-Versionen zu gewährleisten, verwenden wir für die Semantic Versioning 2.0.0_ als Grundlage. Die Ausnahme von der Regel ist für Meilenstein-Releases während eines Entwicklungszyklus, wo Releases mit einem Tag versehen sind <MAJOR>.0.0.0b<MILESTONE> wo <MAJOR> die nächste Hauptversionsnummer ist und <MILESTONE> ist die Meilensteinzahl.

Die Namen der OpenStack-Reihe sind alphabetisch, wobei jeder Buchstabe mit einer Zahl übereinstimmt (z.B.: Austin = 1, Bexar = 2, Newton = 14, Pike = 16 usw.). OSA übernahm die gleiche <MAJOR> Versionsnummerierung wie das Nova-Projekt, um der Versionsnummerierung der OpenStack-Serie zu entsprechen.

Wie oft veröffentlicht OSA?¶

Major Releases werden alle sechs Monate gemäß dem OpenStack Release Schedule durchgeführt. Jede Hauptversion entspricht einer OpenStack-Serie.

Minor/Patch-Releases werden für stabile Filialen am zweiten und letzten Freitag jedes Monats angefordert. Die Releases werden in der Regel innerhalb weniger Tage nach der Anfrage abgeschlossen.

Welche Version von OpenStack wird von OSA bereitgestellt?¶

Für jede OSA-Version wird die OpenStack-Version, die bereitgestellt wird, auf ein bestimmtes OpenStack-git SHA-1 hash_ (SHA) festgelegt. Diese werden nach jeder OSA-Version aktualisiert. Es soll sichergestellt werden, dass OSA-Benutzer eine aktualisierte OpenStack-Umgebung mit kleineren Änderungsschritten nutzen können, als die typischen Upstream-Service-Releases zulassen, da sie in der Regel sehr selten sind.

Dies bedeutet, dass eine stabile OSA-Bereitstellung eine Version eines Dienstes enthält (z.B.: nova-17.0.3dev4), die nicht exakt mit einem Tag übereinstimmt (z.B.: nova-17.0.3).

Wenn Sie den SHA in einen bestimmten SHA/Tag/Zweig ändern möchten oder Ihren eigenen Fork eines OpenStack-Dienstes verwenden möchten, lesen Sie den Abschnitt mit dem Titel Überschreibt den Quellcode anderer Upstream-Projekte im Benutzerhandbuch.

Wann kommt ein Patch für eine OSA-Rolle in ein Release?¶

Für jede OSA-Version werden die Ansible-Rollen, die diese Version bilden, auf einen bestimmten git SHA-1 hash_ (SHA) gesetzt. Diese werden nach jeder OSA-Version aktualisiert.

OSA führt häufig proaktive Bugfix-Backports durch. Um das Risiko zu verringern, dass diese Backports eine Destabilisierung verursachen, implementiert OSA für alle Patches, die in den stabilen Zweigen für Rollen implementiert sind, eine Einweichperiode, aber auch, dass dies in Ausnahmefällen umgangen wird.

Ein Patch, der zu einer Rolle zusammengeführt wurde, wird sofort durch andere Rollentests getestet. So wird sichergestellt, dass jede wichtige Änderung behoben wird. Sobald eine Minor/Patch-Version angefordert wird, erhält der integrierte Build einen SHA Bump-Patch, um den integrierten Build zu aktualisieren und die neuesten verfügbaren Rollen einschließlich des neuen Patches zu verwenden. Dieses neue Set ist für jeden verfügbar, der den Leiter der Stable Branch verwenden möchte und wird in regelmäßigen Tests bis zur nächsten Version getestet. Insgesamt bedeutet dies, dass die Zykluszeit für das Zusammenführen eines Patches zur Freigabe zwischen zwei Wochen und einem Monat liegt.

Wenn es erforderlich ist, einen Rollen-Patch in das nächste Release zu stürzen, kann jeder eine Änderung der ansible-role-requirements.yml-Datei im openstack/openstack-ansible-Repository vorschlagen.

Wir sind davon überzeugt, dass dieser Ansatz sowohl eine angemessene Stabilität als auch einen proaktiven Backport ermöglicht.

Die einzige Ausnahme von dieser Regel ist der master-Zweig, der absichtlich den master-Zweig von allen Rollen zwischen den Releases konsumiert, so dass alle Änderungen sofort einer Integrationsprüfung unterzogen werden.

Veröffentlichungen