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

Testen

Hinzufügen von Tests zu einer neuen Rolle

Jeder der Rollentests befindet sich in seinem Test/Ordner.

Dieser Ordner enthält mindestens die folgenden Dateien:

  • test.yml (super playbook, das als Test-Router für Unter-Playbooks fungiert)

  • <role name> -overrides.yml. Diese var-Datei wird automatisch von unserem Shell-Skript in unser tests repository geladen.

  • inventory. Ein statisches Inventar für den Rollentest. Es ist möglich, dass einige Rollen mehrere Inventare haben. Siehe zum Beispiel die Neutronrolle mit ihren lxb_inventory, calico_inventory.

  • group_vars und host_vars. In diesen Ordnern werden die zum Testen erforderlichen Dateien überschrieben. Hier überschreiben Sie beispielsweise die IP-Adressen, IP-Bereiche und möglichen Verbindungsdetails.

  • ansible-role-requirements.yml. Dies sollte ziemlich einfach sein: Diese Datei enthält alle zu klonenden Rollen, bevor Sie Ihre Rolle ausführen. Die relativen Playbooks der Rollen müssen in der Datei test.yml aufgeführt sein. Denken Sie jedoch daran, das Rad NICHT neu zu erfinden. Wenn Ihre Rolle beispielsweise Keystone benötigt, müssen Sie kein eigenes Keystone-Installations-Playbook erstellen, da wir ein generisches Keystone-Installations-Playbook im tests repository haben.

  • Fügen Sie nur einen zuul.d-Ordner hinzu, wenn Ihre Rolle in den openstack-ansible-Namespace importiert wird.

Tests einer bestehenden Rolle erweitern

  1. Ändern Sie die tox.ini, um Ihr neues Szenario hinzuzufügen. Bei Bedarf können Sie das Inventar und/oder die Variablendateien überschreiben.

  2. Fügen Sie einen neuen Job ohne Abstimmungen in zuul.d/jobs.yaml hinzu und verbinden Sie ihn in der Projekttestdatei `` zuul.d/project.yaml``.

Verbessere das Testen mit tempest

Sobald die anfängliche Konvergenz funktioniert und die Dienste ausgeführt werden, sollte sich die Rollenentwicklung auf die Implementierung einiger Funktionstests konzentrieren.

Idealerweise sollten die Funktionstests für eine OpenStack-Rolle Tempest zum Ausführen der Funktionstests verwenden. Die idealen Tests, die ausgeführt werden müssen, sind Szenariotests, da sie die Funktionen testen, die der Service in einer Produktionsbereitstellung ausführen soll. In Ermangelung irgendwelcher Szenariotests für den Service besteht eine Fallback-Option darin, stattdessen die Smoketests zu implementieren.

Wenn kein Tempest vorhanden ist, sollten einige andere Funktionstests durchgeführt werden. Für APIs können Sie wahrscheinlich die HTTP-Antwortcodes mit speziell gestalteten Anfragen überprüfen.

Tests lokal ausführen

Linting

Python-Kodierungskonventionen werden mit PEP8 mit den folgenden Konvention-Ausnahmen getestet:

  • F403 - ‚from ansible.module_utils.basic import *‘

Das Testen kann lokal ausgeführt werden, indem Sie Folgendes ausführen:

./run_tests.sh pep8

Bash-Kodierungskonventionen werden unter Verwendung von Bashate mit den folgenden Konvention-Ausnahmen getestet:

  • E003: Einrücken nicht Vielfaches von 4. Wir bevorzugen stattdessen Vielfache von 2 zu verwenden.

  • E006: Zeile länger als 79 Spalten. Viele Skripts werden als Vorlagen bereitgestellt

    und verwenden Sie Jinja Templating, das ist sehr schwer zu erreichen. Es wird immer noch als eine Präferenz betrachtet und sollte ein Ziel sein, die Lesbarkeit im Rahmen des Zumutbaren zu verbessern.

  • E040: Syntaxfehler mit bash -n ermittelt. Wie viele Skripts bereitgestellt werden

    als Vorlagen und verwenden Sie Jinja Templating, wird dies oft scheitern. Dieser Test wird relativ sicher ignoriert, da der Syntaxfehler beim Ausführen des resultierenden Skripts identifiziert wird.

Das Testen kann lokal ausgeführt werden, indem Sie Folgendes ausführen:

./run_tests.sh bashate

Ansible wird mit anisible-lint getestet.

Das Testen kann lokal ausgeführt werden, indem Sie Folgendes ausführen:

./run_tests.sh ansible-lint

Ansible Playbook Syntax wird mit Ansible-Playbook getestet.

Das Testen kann lokal ausgeführt werden, indem Sie Folgendes ausführen:

./run_tests.sh ansible-syntax

Ein konsolidierter Satz aller Linttests kann lokal ausgeführt werden, indem Folgendes ausgeführt wird:

./run_tests.sh linters

Dokumentation bauen

Die Dokumentation wird in reStructuredText (RST) erstellt und mit Sphinx in HTML übersetzt.

Die Dokumentation kann lokal erstellt werden, indem Folgendes ausgeführt wird:

./run_tests.sh docs

Das OpenStack-Ansible-integrierte Repository verfügt außerdem über einen zusätzlichen Dokumentationserstellungsprozess, um das Bereitstellungshandbuch zu erstellen.

Dieses Handbuch kann lokal erstellt werden, indem Sie Folgendes ausführen:

./run_tests.sh deploy-guide

Versionshinweise erstellen

Release-Notes werden mit dem the reno tool generiert und mit Sphinx in HTML übersetzt.

Versionshinweise können lokal erstellt werden, indem Sie Folgendes ausführen:

./run_tests.sh releasenotes

Bemerkung

Das Build-Argument Releasenotes testet nur festgeschriebene Änderungen. Stellen Sie sicher, dass Ihre lokalen Änderungen festgeschrieben sind, bevor Sie den Releasenotes Build ausführen.

Rollenfunktions- oder Szenariotests

Führen Sie zum Ausführen eines Funktionstests der Rolle Folgendes aus:

./run_tests.sh functional

Einige Rollen haben zusätzliche Tests, wie Neutron, definiert in tox.ini.

Um einen Funktionstest namens „calico“ auszuführen, führen Sie Folgendes aus:

./run_tests.sh calico

Testen einer neuen Rolle mit einem AIO

  1. Schließen Sie Ihre Rolle auf dem Bereitstellungshost ein. Siehe auch Hinzufügen neuer oder übergeordneter Rollen in Ihrer OpenStack-Ansible-Installation.

  2. Führen Sie eine andere Host-Vorbereitung durch (z. B. die Tasks, die von der bootstrap-aio.yml-Playbook ausgeführt werden). Dies umfasst alle Vorbereitungsaufgaben, die für Ihren Service spezifisch sind.

  3. Generieren Sie Dateien, um Ihren Dienst in das Ansible-Inventar aufzunehmen, indem Sie Dateien env.d und conf.d zur Verwendung auf Ihrem Bereitstellungs-Host verwenden.

    Hinweis

    Sie können Beispielen aus anderen Rollen folgen und die entsprechenden Änderungen vornehmen, um sicherzustellen, dass Gruppenbezeichnungen in den Dateien env.d und conf.d konsistent sind.

    Hinweis

    Eine Beschreibung dieser Arbeit finden Sie in Grundlegendes zu Host-Gruppen (conf.d-Struktur) und Container-Gruppen verstehen (Struktur env.d).

  4. Erstellen Sie ggf. geheime Schlüssel, wie im folgenden Abschnitt beschrieben Configure Service Credentials. Sie können Ihre Schlüssel an eine vorhandene user_secrets.yml-Datei anhängen oder eine neue Datei zum openstack_deploy-Verzeichnis hinzufügen, um sie zu enthalten. Geben Sie Überschreibungen für alle anderen Variablen an, die Sie zu diesem Zeitpunkt benötigen, entweder in user_variables.yml oder in einer anderen Datei.

    Siehe auch unsere Überschreiben der Standardkonfiguration Seite.

    Alle für die Funktion erforderlichen Geheimnisse müssen in der Datei etc/openstack_deploy/user_secrets.yml zur Wiederverwendung durch andere Benutzer vermerkt sein.

  5. Wenn Ihr Dienst von der Quelle installiert wird oder auf Python-Paketen basiert, die von der Quelle installiert werden müssen, geben Sie ein Repository für den Quellcode jeder Anforderung an, indem Sie unter playbooks/defaults/repo_packages im Ordner eine Datei zum Deploy-Host hinzufügen OpenStack-Ansible-Quell-Repository und Befolgen des Musters der Dateien, die sich derzeit in diesem Verzeichnis befinden. Sie könnten auch einfach einen Eintrag zu einer vorhandenen Datei hinzufügen. Stellen Sie sicher, dass Sie das repo-build.yml-Playbook später ausführen, damit die Wheels für Ihre Pakete in die Repository-Infrastruktur eingebunden werden.

  6. Nehmen Sie alle erforderlichen Anpassungen an der Load-Balancer-Konfiguration vor (z.B. ändern Sie inventory/group_vars/all/haproxy.yml im OpenStack-Ansible-Quellenrepository auf Ihrem Bereitstellungshost), damit Ihr Dienst über einen Load Balancer erreicht werden kann Wählen Sie die Option haproxy-install.yml, um die Änderungen zu übernehmen. Bitte beachten Sie, dass Sie auch die Variable haproxy_extra_services verwenden können, wenn Sie Ihren Service nicht als Standard für alle Benutzer bereitstellen möchten.

  7. Stellen Sie eine Service-Installations-Playbook-Datei für Ihre Rolle zusammen. Dies kann auch aus jedem vorhandenen Dienst-Playbook modelliert werden, das ähnliche Abhängigkeiten zu Ihrem Dienst aufweist (Datenbank, Messaging, Speichertreiber, Containerbereitstellungspunkte usw.). Ein gängiger Platz zum Speichern von Playbook-Dateien in einer Galaxy-Rolle befindet sich in einem examples-Verzeichnis außerhalb des Stamms der Rolle. Wenn das Playbook zur Installation eines OpenStack-Dienstes gedacht ist, nennen Sie es os<service> -install.yml und zielen Sie auf die entsprechende Gruppe ab, die in der Service-Datei env.d definiert ist. Es ist von entscheidender Bedeutung, dass die Implementierung des Service optional ist und dass der Deployer die Bereitstellung über die Population eines Hosts in der entsprechenden Hostgruppe aktivieren muss. Wenn die Hostgruppe keine Hosts hat, überspringt Ansible automatisch die Aufgaben des Playbooks.

  8. Alle Variablen, die von anderen Rollen benötigt werden, um sich mit der neuen Rolle zu verbinden, oder von der neuen Rolle, um eine Verbindung zu anderen Rollen herzustellen, sollten in inventory/group_vars implementiert werden. Die Gruppen-Vars sind im Wesentlichen der Leim, den Playbooks verwenden, um sicherzustellen, dass allen Rollen die entsprechenden Informationen gegeben werden. Wenn Gruppenvars implementiert werden, sollte es ein Mindestsatz sein, um das Ziel der Integration der neuen Rolle in den integrierten Build zu erreichen.

  9. Die Dokumentation muss in der Rolle hinzugefügt werden, um zu beschreiben, wie der neue Service in einer integrierten Umgebung implementiert wird. Dieser Inhalt muss den folgenden Regeln entsprechen Dokumentation und Release Note Richtlinien. Bis die Rolle ein integriertes Funktionstest implementiert hat (siehe auch den Paragraphen Rollenentwicklungsreife), muss die Dokumentation klarstellen, dass die Serviceeinbindung in OpenStack-Ansible experimentell ist und nicht vollständig von OpenStack-Ansible in einem integrierten Build getestet wird. Alternativ kann eine User Story erstellt werden.

  10. Eine Feature-Release-Notiz muss hinzugefügt werden, um die neue Serviceverfügbarkeit anzukündigen und für weitere Details auf die Rollendokumentation zu verweisen. Dieser Inhalt muss den folgenden Regeln entsprechen Dokumentation und Release Note Richtlinien.

  11. Es muss möglich sein, einen funktionalen, integrierten Test auszuführen, der eine Bereitstellung auf die gleiche Weise wie eine Produktionsumgebung ausführt. Der Test muss eine Reihe von Funktionstests mit Tempest ausführen. Dies ist der letzte erforderliche Schritt, bevor ein Service die experimentelle Warnung aus der Dokumentation entfernen kann.

Hinweis

Wenn Sie sich daran halten, die zusätzlichen Bereitstellungsanforderungen Ihrer Rolle (geheime und var-Dateien, HAProxy-XML-Fragmente, Repo-Paketdateien usw.) in ihren eigenen Dateien zu isolieren, können Sie diese zusätzlichen Schritte beim Testen Ihrer Rolle einfach automatisieren.

Integriertes Repo-Funktions- oder Szenariotest

Um den integrierten Repo zu testen, folgen Sie dem Deployment Guide

Alternativ können Sie den aio guide lesen, oder führen Sie sogar das Gate-Wrapper-Skript mit dem Namen scripts/gate-check-commit.sh, wie unten beschrieben, aus.

Die automatisierten OpenStack Infrastructure-Tests

Es sollte keinen Unterschied zwischen dem Ausführen von Tests in der Openstack-Infrastruktur und dem lokalen Ausführen geben.

Die Tests in der Openstack-Infrastruktur werden durch Jobs ausgelöst, die in jedem Repo zuul.d-Ordner definiert sind.

Siehe auch zuul user guide.

Aus Zuverlässigkeitsgründen sind jedoch einige Variablen definiert, die auf die OpenStack-Infra-Pypi- und Paketspiegel verweisen.

Der integrierte Repo-Funktionstest verwendet das Skript scripts/gate-check-commit.sh, das Argumente von der zuul run-Playbook-Definition empfängt.

Obwohl dieses Skript hauptsächlich für die Verwendung in OpenStack-CI entwickelt und verwaltet wird, kann es in anderen Umgebungen verwendet werden.

Rollenentwicklungsreife

Eine Rolle kann vollständig ausgereift sein, auch wenn sie nicht in das Repository openstack-ansible integriert ist. Die Reife hängt von den Teststufen ab.

Eine Rolle kann in einer der vier Reifegrade sein:

  • Vollständig

  • Inkubiert

  • Nicht gepflegt

  • Ruhestand

Hier sind eine Reihe von Regeln, die Reifegrade definieren:

  • Eine Rolle kann jederzeit zurückgezogen werden, wenn sie nicht mehr relevant ist.

  • Eine Rolle kann für maximal 2 Zyklen Inkubiert werden.

  • Eine Rolle Incubated, die den Funktionstest besteht, wird auf den Status Complete hochgestuft und kann nicht in den Status Incubated zurückkehren.

  • Eine Incubated -Rolle, die im sechsmonatigen Zeitrahmen keinen Funktionstest implementiert hat, wird nicht gepflegt.

  • Eine Rolle im Complete` Status kann zu` Unmaintained` degradiert werden. Status, gemäß dem Reifegradherabstufungsverfahren.

Maturity-Downgrade-Verfahren

Wenn eine Rolle zwei Wochen lang keine Periodik oder einen Gate-Test ausgeführt hat, sollte ein Fehler gemeldet werden und eine Nachricht an die Mailing-Liste gesendet werden, die auf den Fehler verweist.

Das nächste Community-Meeting sollte sich mit der Abwertung von Rollen befassen, und wenn kein Contributor die Rolle korrigiert, werden periodische Tests deaktiviert und die Rolle wechselt in den Status nicht gewartet.

Reife-Matrix

Alle OpenStack-Ansible-Rollen haben nicht den gleichen Reifegrad und Test.

Hier ist ein Dashboard des aktuellen Status der Rollen:

Active roles

Role name Created during cycle Maturity level Included into openstack-ansible by default Supports Ubuntu Supports CentOS Supports OpenSUSE
ansible-hardening Liberty Complete
apt_package_pinning Mitaka Complete
ceph_client Newton Incubated
galera_client Mitaka Complete
galera_server Mitaka Complete
haproxy_server Newton Incubated
lxc_container_create Mitaka Complete
lxc_hosts Mitaka Complete
memcached_server Mitaka Complete
openstack_hosts Mitaka Complete
openstack_openrc Mitaka Complete
os_almanach Queens Complete
os_aodh Mitaka Complete
os_barbican Ocata Complete
os_ceilometer Mitaka Complete
os_cinder Mitaka Complete
os_cloudkitty Ocata Incubated
os_congress Unknown Unknown
os_designate Mitaka Complete
os_glance Mitaka Complete
os_gnocchi Newton Complete
os_heat Mitaka Complete
os_horizon Mitaka Complete
os_ironic Mitaka Complete
os_keystone Mitaka Complete
os_magnum Newton Complete
os_manila Stein Incubated
os_masakari Stein Incubated
os_molteniron Pike Incubated
os_monasca Ocata Unmaintained
os_monasca-agent Ocata Unmaintained
os_monasca-ui Ocata Unmaintained
os_neutron Mitaka Complete
os_nova Mitaka Complete
os_octavia Pike Complete
os_panko Rocky Inclubated
os_rally Newton Complete
os_sahara Newton Complete
os_searchlight Queens Complete
os_swift Mitaka Complete
os_tacker Queens Complete
os_tempest Mitaka Complete
os_trove Ocata Complete
os_watcher Queens Incubated
os_zaqar Queens Complete
pip_install Mitaka Complete
plugins Mitaka Complete
rabbitmq_server Mitaka Complete
repo_build Mitaka Complete
repo_server Mitaka Complete
rsyslog_client Mitaka Complete
rsyslog_server Mitaka Complete

Retired roles

Role name Created during cycle Retired during cycle
openstack-ansible-security Liberty Pike
pip_lock_down Liberty Newton