[ English | Deutsch | русский | English (United Kingdom) ]

Veröffentlichungen¶

What is the OpenStack-Ansible release model?¶

OpenStack-Ansible uses the ‚cycle-trailing‘ release model as specified in the OpenStack release model reference.

Wie werden Release-Tags festgelegt?¶

In order to ensure a common understanding of what release versions mean, we use Semantic Versioning 2.0.0 for versioning as a basis. The exception to the rule is for milestone releases during a development cycle, where releases are tagged <MAJOR>.0.0.0b<MILESTONE> where <MAJOR> is the next major release number, and <MILESTONE> is the milestone number.

The OpenStack series names are alphabetical, with each letter matched to a number (e.g., Austin = 1, Bexar = 2, Newton = 14, Pike = 16, etc.). OpenStack-Ansible adopted the same <MAJOR> release numbering as the Nova project to match the overall OpenStack series version numbering.

How frequently does OpenStack-Ansible release?¶

Major releases are done every six months according to the OpenStack release schedule. Each major release is consistent with an OpenStack series.

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.

What version of OpenStack is deployed by OpenStack-Ansible?¶

For each OpenStack-Ansible release, the OpenStack version that is deployed is set to a specific OpenStack git SHA-1 hash (SHA). These are updated after every OpenStack-Ansible release. The intent is to ensure that OpenStack-Ansible users are able to enjoy an updated OpenStack environment with smaller increments of change than the typical upstream service releases allow for as they are usually very infrequent.

This does mean that a stable OpenStack-Ansible deployment will include a version of a service (e.g.: nova-17.0.3dev4) which does not match a tag exactly as you may expect (e.g.: 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.

When does a patch to an OpenStack-Ansible role get into a release?¶

For each OpenStack-Ansible release, the Ansible roles that form that release are set to a specific git SHA-1 hash (SHA). These are updated after every OpenStack-Ansible release.

OpenStack-Ansible frequently does proactive bugfix backports. In order to reduce the risk of these backports introducing any destabilization, OpenStack-Ansible implements a ‚soak‘ period for any patches implemented in the stable branches for roles, but also provides for circumventing this in exceptional circumstances.

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.

The only exception to this process is for the master branch, which intentionally consumes the master branch from all roles between releases so that any changes are immediately integration tested.

Veröffentlichungen