[ English | Indonesia | Deutsch | 日本語 ]

Upgrades

Mit Ausnahme von Object Storage kann das Upgrade von einer Version von OpenStack auf eine andere sehr aufwendig sein. Dieses Kapitel enthält einige Hinweise zu den betrieblichen Aspekten, die Sie bei einem Upgrade für eine OpenStack-Umgebung berücksichtigen sollten.

Überlegungen zur Vorbereitung des Upgrades

Upgrade-Planung

  • Lesen Sie die Release Notes, um mehr über neue, aktualisierte und veraltete Funktionen zu erfahren. Finden Sie Inkompatibilitäten zwischen Versionen.

  • Berücksichtigen Sie die Auswirkungen eines Upgrades auf die Benutzer. Der Upgrade-Prozess unterbricht die Verwaltung Ihrer Umgebung einschließlich des Dashboards. Wenn Sie sich richtig auf das Upgrade vorbereiten, sollten bestehende Instanzen, Netzwerke und Speicher weiterhin funktionieren. In Einzelfällen kann es jedoch zu intermittierenden Netzwerkunterbrechungen kommen.

  • Berücksichtigen Sie den Ansatz für die Aktualisierung Ihrer Umgebung. Sie können ein Upgrade mit operativen Instanzen durchführen, aber das ist ein gefährlicher Ansatz. Sie können die Live-Migration verwenden, um Instanzen während der Durchführung von Upgrades vorübergehend auf andere Compute-Knoten zu verschieben. Sie müssen jedoch die Konsistenz der Datenbank während des gesamten Prozesses sicherstellen, da Ihre Umgebung sonst instabil werden könnte. Vergessen Sie auch nicht, Ihre Benutzer ausreichend zu informieren, einschließlich der Zeit, die sie benötigen, um ihre eigenen Backups durchzuführen.

  • Erwägen Sie, Struktur und Optionen aus den Service-Konfigurationsdateien zu übernehmen und sie mit bestehenden Konfigurationsdateien zu verschmelzen. Die OpenStack Configuration Reference enthält neue, aktualisierte und veraltete Optionen für die meisten Dienste.

  • Wie alle wichtigen System-Upgrades kann auch Ihr Upgrade aus einem oder mehreren Gründen fehlschlagen. Sie können sich auf diese Situation vorbereiten, indem Sie Ihre Umgebung auf die vorherige Version zurücksetzen können, einschließlich Datenbanken, Konfigurationsdateien und Pakete. Wir stellen einen exemplarischen Prozess für das Zurücksetzen Ihrer Umgebung in Zurücksetzen eines fehlgeschlagenen Upgrades vor.

  • Entwickeln Sie ein Upgrade-Verfahren und bewerten Sie es gründlich, indem Sie eine Testumgebung ähnlich Ihrer Produktionsumgebung verwenden.

Vorab-Upgrade-Testumgebung

Der wichtigste Schritt ist die Pre-Upgrade-Prüfung. Wenn Sie unmittelbar nach der Veröffentlichung einer neuen Version ein Upgrade durchführen, können unentdeckte Fehler Ihren Fortschritt behindern. Einige Bereitsteller ziehen es vor, zu warten, bis die erste Punktfreigabe angekündigt wird. Wenn Sie jedoch einen signifikanten Einsatz haben, können Sie die Entwicklung und den Test des Releases verfolgen, um sicherzustellen, dass Fehler für Ihre Anwendungsfälle behoben werden.

Jede OpenStack-Cloud ist unterschiedlich, auch wenn Sie eine nahezu identische Architektur haben, wie in diesem Handbuch beschrieben. Daher müssen Sie weiterhin Upgrades zwischen Versionen in Ihrer Umgebung mit einem ungefähren Klon Ihrer Umgebung testen.

Das heißt jedoch nicht, dass sie die gleiche Größe haben oder identische Hardware wie die Produktionsumgebung verwenden muss. Es ist wichtig, die Hardware und den Umfang der Cloud zu berücksichtigen, die Sie aktualisieren. Die folgenden Tipps können Ihnen helfen, die Kosten zu minimieren:

Verwenden Sie Ihre eigene Cloud

Der einfachste Ort, um mit dem Testen der nächsten Version von OpenStack zu beginnen, ist die Einrichtung einer neuen Umgebung innerhalb Ihrer eigenen Cloud. Dies mag seltsam erscheinen, insbesondere die doppelte Virtualisierung, die beim Betrieb von Compute-Knoten verwendet wird. Aber es ist ein sicherer Weg, um Ihre Konfiguration sehr schnell zu testen.

Eine Public Cloud nutzen

Erwägen Sie die Verwendung einer Public Cloud, um die Skalierbarkeitsgrenzen Ihrer Cloud-Controller-Konfiguration zu testen. Die meisten Public Clouds rechnen stundenweise ab, was bedeutet, dass es kostengünstig sein kann, selbst einen Test mit vielen Knoten durchzuführen.

Einen anderen Speicher-Endpunkt auf dem gleichen System erstellen

Wenn Sie mit Ihrer Cloud ein externes Speicher-Plugin oder ein gemeinsam genutztes Dateisystem verwenden, können Sie testen, ob es funktioniert, indem Sie eine zweite Freigabe oder einen zweiten Endpunkt erstellen. So können Sie das System testen, bevor Sie die neue Version Ihrem Speicher anvertrauen.

Beobachten Sie das Netzwerk

Selbst bei kleineren Tests sollten Sie nach überschüssigen Netzwerkpaketen suchen, um festzustellen, ob etwas in der Kommunikation zwischen den Komponenten schrecklich schief läuft.

Um die Testumgebung einzurichten, können Sie eine von mehreren Methoden verwenden:

  • Führen Sie eine vollständige manuelle Installation durch, indem Sie die Installations-Tutorials und Anleitungen für Ihre Plattform verwenden. Überprüfen Sie die endgültigen Konfigurationsdateien und installierten Pakete.

  • Erstellen Sie einen Klon Ihrer automatisierten Konfigurationsinfrastruktur mit geänderten Paket-Repository URLs.

    Ändern Sie die Konfiguration, bis sie funktioniert.

Beide Ansätze sind gültig. Verwenden Sie den Ansatz, der Ihrer Erfahrung entspricht.

Ein Upgrade-Pretestsystem ist hervorragend geeignet, um die Konfiguration zum Laufen zu bringen. Es ist jedoch wichtig zu beachten, dass die historische Nutzung des Systems und Unterschiede in der Benutzerinteraktion den Erfolg von Upgrades beeinflussen können.

Wenn möglich, empfehlen wir Ihnen dringend, Ihre Produktionsdatenbanktabellen zu sichern und das Upgrade in Ihrer Entwicklungsumgebung mit diesen Daten zu testen. Mehrere MySQL-Fehler wurden bei Datenbankmigrationen aufgedeckt, da es leichte Tabellenunterschiede zwischen einer Neuinstallation und Tabellen gibt, die von einer Version zur anderen migriert wurden. Dies hat Auswirkungen auf große reale Datensätze, die Sie bei einem Produktionsausfall nicht erleben möchten.

Künstliche Maßstabstests können nur so weit gehen. Nachdem Ihre Cloud aktualisiert wurde, müssen Sie die Leistungsaspekte Ihrer Cloud sorgfältig beachten.

Upgrade-Level

Upgrade-Level sind eine Funktion, die OpenStack Compute seit der Grizzly-Version hinzugefügt wurde, um eine Versionssperre für die RPC-Kommunikation (Message Queue) zwischen den verschiedenen Compute-Diensten zu ermöglichen.

Diese Funktionalität ist ein wichtiger Bestandteil des Puzzles bei Live-Upgrades und ähnelt konzeptionell der bestehenden API-Versionierung, die es OpenStack-Diensten verschiedener Versionen ermöglicht, problemlos zu kommunizieren.

Ohne Upgrade-Level kann ein X+1 Version Compute Service X Version RPC-Nachrichten empfangen und verstehen, aber er kann nur X+1 Version RPC-Nachrichten senden. Wenn beispielsweise ein nova-conductor-Prozess auf die X+1-Version aktualisiert wurde, dann kann der Conductor-Service Nachrichten von nova-compute-Prozessen der X-Version verstehen, aber diese Compute-Services können die vom Conductor-Service gesendeten Nachrichten nicht verstehen.

Während eines Upgrades können Betreiber Konfigurationsoptionen zu nova.conf hinzufügen, die die Version von RPC-Nachrichten sperren und ein Live-Upgrade der Dienste ohne Unterbrechung durch Versionsinkongruenz ermöglichen. Die Konfigurationsoptionen erlauben die Angabe von RPC-Versionsnummern auf Wunsch, aber auch Release-Namen-Aliase werden unterstützt. Zum Beispiel:

[upgrade_levels]
compute=X
conductor=X
scheduler=X

will keep the RPC version locked across the specified services to the RPC version used in X. As all instances of a particular service are upgraded to the newer version, the corresponding line can be removed from nova.conf.

Mit dieser Funktionalität würde man idealerweise die RPC-Version an die OpenStack-Version binden, die von nova-compute nodes aktualisiert wird, um sicherzustellen, dass z.B. X+1-Version nova-compute-Prozesse weiterhin mit X-Version nova-conductor-Prozessen arbeiten, während das Upgrade abgeschlossen ist. Nach Abschluss des Upgrades der nova-compute-Prozesse kann der Betreiber mit dem Upgrade von nova-conductor fortfahren und die Versionssperre für nova-compute in nova.conf entfernen.

Upgrade-Prozess

Dieser Abschnitt beschreibt den Prozess zum Aktualisieren einer grundlegenden OpenStack-Bereitstellung auf der Grundlage der grundlegenden Zweiknotenarchitektur in den Installations-Tutorials und -Anleitungen. Alle Knoten müssen eine unterstützte Distribution von Linux mit einem aktuellen Kernel und den aktuellen Release-Paketen ausführen.

Dienstspezifische Upgrade-Anweisungen

In den folgenden Upgrade-Hinweisen finden Sie Informationen zum Upgrade bestimmter OpenStack-Dienste:

Voraussetzungen

  • Führen Sie vor Beginn des Upgrade-Prozesses eine gewisse Reinigung der Umgebung durch, um einen konsistenten Zustand sicherzustellen. Beispielsweise können Instanzen, die nach dem Löschen nicht vollständig aus dem System entfernt wurden, zu unbestimmtem Verhalten führen.

  • In Umgebungen, die den OpenStack Networking-Dienst (Neutron) verwenden, überprüfen Sie die Release-Version der Datenbank. Zum Beispiel:

    # su -s /bin/sh -c "neutron-db-manage --config-file /etc/neutron/neutron.conf \
      --config-file /etc/neutron/plugins/ml2/ml2_conf.ini current" neutron
    

Durchführen einer Sicherung

  1. Speichern Sie die Konfigurationsdateien auf allen Knoten. Zum Beispiel:

    # for i in keystone glance nova neutron openstack-dashboard cinder heat ceilometer; \
      do mkdir $i-RELEASE_NAME; \
      done
    # for i in keystone glance nova neutron openstack-dashboard cinder heat ceilometer; \
      do cp -r /etc/$i/* $i-RELEASE_NAME/; \
      done
    

    Bemerkung

    Sie können dieses Beispielskript auf jedem Knoten ändern, um verschiedene Dienste zu verwalten.

  2. Erstellen Sie eine vollständige Datenbanksicherung Ihrer Produktionsdaten. Seit der Kilo-Version werden Datenbank-Downgrades nicht mehr unterstützt, und die Wiederherstellung aus dem Backup ist die einzige verfügbare Methode, um eine frühere Datenbankversion abzurufen.

    # mysqldump -u root -p --opt --add-drop-database --all-databases > RELEASE_NAME-db-backup.sql
    

    Bemerkung

    Erwägen Sie, Ihre SQL-Serverkonfiguration zu aktualisieren, wie in den Installations-Tutorials und Anleitungen beschrieben.

Verwalten von Repositories

Auf allen Knoten:

  1. Entfernen Sie das Repository für die vorherigen Release-Pakete.

  2. Fügen Sie das Repository für die neuen Release-Pakete hinzu.

  3. Aktualisieren Sie die Repository-Datenbank.

Upgrade-Pakete auf jedem Knoten

Abhängig von Ihrer spezifischen Konfiguration kann die Aktualisierung aller Pakete einen Neustart oder eine Unterbrechung der Dienste als Ergänzung zu Ihrer OpenStack-Umgebung bewirken. Wenn Sie beispielsweise das TGT iSCSI-Framework für Block Storage-Volumes verwenden und das Upgrade neue Pakete für diese enthält, kann der Paketmanager die TGT iSCSI-Dienste neu starten und die Konnektivität auf Volumes beeinträchtigen.

Wenn der Paketmanager Sie auffordert, die Konfigurationsdateien zu aktualisieren, lehnen Sie die Änderungen ab. Der Paketmanager fügt neueren Versionen von Konfigurationsdateien ein Suffix hinzu. Erwägen Sie, Inhalte aus diesen Dateien zu überprüfen und zu übernehmen.

Bemerkung

Möglicherweise müssen Sie das Paket ipset explizit installieren, wenn Ihre Distribution es nicht als Abhängigkeit installiert.

Aktualisierungsdienste

Um einen Dienst auf jedem Knoten zu aktualisieren, ändern Sie in der Regel eine oder mehrere Konfigurationsdateien, stoppen den Dienst, synchronisieren das Datenbankschema und starten den Dienst. Einige Dienste erfordern unterschiedliche Schritte. Wir empfehlen, den Betrieb jedes Dienstes zu überprüfen, bevor Sie mit dem nächsten Dienst fortfahren.

Die Reihenfolge, in der Sie die Dienste aktualisieren sollten, und alle Änderungen, die sich aus dem allgemeinen Upgrade-Prozess ergeben, werden im Folgenden beschrieben:

Controller node

  1. Identitätsdienst - Löschen Sie alle abgelaufenen Token, bevor Sie die Datenbank synchronisieren.

  2. Image service [Abbilddienst (glance)]

  3. Rechendienst, einschließlich Netzwerkkomponenten.

  4. Netzwerkdienst (neutron)

  5. Blockspeicherdienst (cinder)

  6. Dashboard - In typischen Umgebungen erfordert die Aktualisierung des Dashboards nur einen Neustart des Apache HTTP-Dienstes.

  7. Orchestrierungsdienst (heat)

  8. Telemetriedienst - In typischen Umgebungen erfordert die Aktualisierung des Telemetriedienstes nur einen Neustart des Dienstes.

  9. Compute Service - Bearbeiten Sie die Konfigurationsdatei und starten Sie den Dienst neu.

  10. Netzwerkdienst - Bearbeiten Sie die Konfigurationsdatei und starten Sie den Dienst neu.

Speicherknoten

  • Blockspeicherdienst - Die Aktualisierung des Blockspeicherdienstes erfordert nur einen Neustart des Dienstes.

Compute-Knoten

  • Netzwerkdienst - Bearbeiten Sie die Konfigurationsdatei und starten Sie den Dienst neu.

Letzte Schritte

Bei allen Distributionen müssen Sie einige abschließende Aufgaben ausführen, um den Upgrade-Prozess abzuschließen.

  1. Verringern Sie die DHCP-Timeouts, indem Sie die Datei /etc/nova/nova.conf auf den Compute-Knoten auf den ursprünglichen Wert für Ihre Umgebung zurücksetzen.

  2. Aktualisieren Sie alle .ini Dateien, um Passwörter und Pipelines entsprechend der OpenStack-Version in Ihrer Umgebung anzupassen.

  3. Nach der Migration sehen die Benutzer unterschiedliche Ergebnisse von openstack image list und glance image-list. Um sicherzustellen, dass Benutzer die gleichen Abbilder in den Listenbefehlen sehen, bearbeiten Sie die Datei /etc/glance/policy.json und die Datei /etc/nova/policy.json so, dass sie "context_is_admin" enthält: "role:admin"`, die den Zugriff auf private Abbilder für Projekte einschränkt.

  4. Überprüfen Sie den ordnungsgemäßen Betrieb Ihrer Umgebung. Benachrichtigen Sie dann Ihre Benutzer, dass ihre Cloud wieder normal funktioniert.

Zurücksetzen eines fehlgeschlagenen Upgrades

Dieser Abschnitt enthält Anleitungen für das Zurücksetzen auf eine frühere Version von OpenStack. Alle Distributionen folgen einem ähnlichen Verfahren.

Warnung

Das Zurücksetzen Ihrer Umgebung sollte die letzte Maßnahme sein, da Sie wahrscheinlich alle seit dem Backup hinzugefügten Daten verlieren werden.

Ein häufiges Szenario ist es, die Produktionsverwaltungsdienste zur Vorbereitung auf ein Upgrade abzuschalten, einen Teil des Upgrade-Prozesses abzuschließen und ein oder mehrere Probleme zu entdecken, die während des Tests nicht aufgetreten sind. Infolgedessen müssen Sie Ihre Umgebung in den ursprünglichen „bekannt guten“ Zustand zurücksetzen. Sie haben auch sichergestellt, dass Sie nach dem Versuch des Upgrade-Prozesses keine Zustandsänderungen vorgenommen haben; keine neuen Instanzen, Netzwerke, Speicherdatenträger usw. Jede dieser neuen Ressourcen befindet sich in einem eingefrorenen Zustand, nachdem die Datenbanken aus dem Backup wiederhergestellt wurden.

In diesem Rahmen müssen Sie diese Schritte ausführen, um Ihre Umgebung erfolgreich zurückzusetzen:

  1. Rollback der Konfigurationsdateien.

  2. Wiederherstellen von Datenbanken aus dem Backup.

  3. Pakete zurücksetzen.

Sie sollten sicherstellen, dass Sie über die erforderlichen Sicherungen verfügen, um diese wiederherzustellen. Das Zurücksetzen von Upgrades ist ein kniffliger Prozess, da Distributionen dazu neigen, viel mehr Aufwand in das Testen von Upgrades zu stecken als Downgrades. Zerrüttete Downgrades erfordern deutlich mehr Aufwand bei der Fehlersuche und -behebung als defekte Upgrades. Nur Sie können die Risiken, ein fehlgeschlagenes Upgrade voranzutreiben, gegen ein Zurückrollen abwägen. Im Allgemeinen sollten Sie das Zurücksetzen als allerletzte Option in Betracht ziehen.

Die folgenden für Ubuntu beschriebenen Schritte haben auf mindestens einer Produktionsumgebung funktioniert, aber sie funktionieren möglicherweise nicht für alle Umgebungen.

Um einen Rollback durchzuführen

  1. Stoppen Sie alle OpenStack-Dienste.

  2. Kopieren Sie den Inhalt der Konfigurations-Backup-Verzeichnisse, die Sie während des Upgrade-Prozesses erstellt haben, zurück in das Verzeichnis /etc/<service>.

  3. Stellen Sie Datenbanken aus der Sicherungsdatei RELEASE_NAME-db-backup.sql wieder her, die Sie mit dem Befehl mysqldump während des Upgrade-Prozesses erstellt haben:

    # mysql -u root -p < RELEASE_NAME-db-backup.sql
    
  4. Downgrade von OpenStack-Paketen.

    Warnung

    Die Herabstufung von Paketen ist bei weitem der komplizierteste Schritt; er ist stark abhängig von der Verteilung und der gesamten Administration des Systems.

    1. Bestimmen Sie, welche OpenStack-Pakete auf Ihrem System installiert sind. Verwenden Sie den Befehl dpkg --get-selections. Filtern Sie nach OpenStack-Paketen, filtern Sie erneut, um Pakete auszulassen, die explizit im Zustand Deinstallieren markiert sind, und speichern Sie die endgültige Ausgabe in einer Datei. Der folgende Befehl umfasst beispielsweise einen Controller-Knoten mit Keystone, glance, nova, neutron und cinder:

      # dpkg --get-selections | grep -e keystone -e glance -e nova -e neutron \
      -e cinder | grep -v deinstall | tee openstack-selections
      cinder-api                                      install
      cinder-common                                   install
      cinder-scheduler                                install
      cinder-volume                                   install
      glance                                          install
      glance-api                                      install
      glance-common                                   install
      glance-registry                                 install
      neutron-common                                  install
      neutron-dhcp-agent                              install
      neutron-l3-agent                                install
      neutron-lbaas-agent                             install
      neutron-metadata-agent                          install
      neutron-plugin-openvswitch                      install
      neutron-plugin-openvswitch-agent                install
      neutron-server                                  install
      nova-api                                        install
      nova-common                                     install
      nova-conductor                                  install
      nova-consoleauth                                install
      nova-novncproxy                                 install
      nova-objectstore                                install
      nova-scheduler                                  install
      python-cinder                                   install
      python-cinderclient                             install
      python-glance                                   install
      python-glanceclient                             install
      python-keystone                                 install
      python-keystoneclient                           install
      python-neutron                                  install
      python-neutronclient                            install
      python-nova                                     install
      python-novaclient                               install
      

      Bemerkung

      Je nach Servertyp können Inhalt und Reihenfolge Ihrer Paketliste von diesem Beispiel abweichen.

    2. Sie können die für die Reversion verfügbaren Paketversionen mit dem Befehl apt-cache policy bestimmen. Zum Beispiel:

      # apt-cache policy nova-common
      
      nova-common:
      Installed: 2:14.0.1-0ubuntu1~cloud0
      Candidate: 2:14.0.1-0ubuntu1~cloud0
      Version table:
      *** 2:14.0.1-0ubuntu1~cloud0 500
            500 http://ubuntu-cloud.archive.canonical.com/ubuntu xenial-updates/newton/main amd64 Packages
            100 /var/lib/dpkg/status
          2:13.1.2-0ubuntu2 500
            500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages
          2:13.0.0-0ubuntu2 500
            500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages
      

      Bemerkung

      Wenn Sie die Release-Repositories entfernt haben, müssen Sie sie zunächst neu installieren und den Befehl apt-get update ausführen.

      Die Befehlsausgabe listet die aktuell installierte Version des Pakets, die neueste Kandidatenversion und alle Versionen zusammen mit dem Repository, das jede Version enthält. Suchen Sie in diesem Fall nach der passenden Release-Version - 2:14.0.1-0ubuntu1~cloud0. Der Prozess der manuellen Kommissionierung durch diese Liste von Paketen ist ziemlich mühsam und fehleranfällig. Sie sollten in Betracht ziehen, ein Skript zu verwenden, um bei diesem Prozess zu helfen. Zum Beispiel:

      # for i in `cut -f 1 openstack-selections | sed 's/neutron/;'`;
        do echo -n $i ;apt-cache policy $i | grep -B 1 RELEASE_NAME |
        grep -v Packages | awk '{print "="$1}';done | tr '\n' ' ' |
        tee openstack-RELEASE_NAME-versions
      cinder-api=2:9.0.0-0ubuntu1~cloud0
      cinder-common=2:9.0.0-0ubuntu1~cloud0
      cinder-scheduler=2:9.0.0-0ubuntu1~cloud0
      cinder-volume=2:9.0.0-0ubuntu1~cloud0
      glance=2:13.0.0-0ubuntu1~cloud0
      glance-api=2:13.0.0-0ubuntu1~cloud0 500
      glance-common=2:13.0.0-0ubuntu1~cloud0 500
      glance-registry=2:13.0.0-0ubuntu1~cloud0 500
      neutron-common=2:9.0.0-0ubuntu1~cloud0
      neutron-dhcp-agent=2:9.0.0-0ubuntu1~cloud0
      neutron-l3-agent=2:9.0.0-0ubuntu1~cloud0
      neutron-lbaas-agent=2:9.0.0-0ubuntu1~cloud0
      neutron-metadata-agent=2:9.0.0-0ubuntu1~cloud0
      neutron-server=2:9.0.0-0ubuntu1~cloud0
      nova-api=2:14.0.1-0ubuntu1~cloud0
      nova-common=2:14.0.1-0ubuntu1~cloud0
      nova-conductor=2:14.0.1-0ubuntu1~cloud0
      nova-consoleauth=2:14.0.1-0ubuntu1~cloud0
      nova-novncproxy=2:14.0.1-0ubuntu1~cloud0
      nova-objectstore=2:14.0.1-0ubuntu1~cloud0
      nova-scheduler=2:14.0.1-0ubuntu1~cloud0
      python-cinder=2:9.0.0-0ubuntu1~cloud0
      python-cinderclient=1:1.9.0-0ubuntu1~cloud0
      python-glance=2:13.0.0-0ubuntu1~cloud0
      python-glanceclient=1:2.5.0-0ubuntu1~cloud0
      python-neutron=2:9.0.0-0ubuntu1~cloud0
      python-neutronclient=1:6.0.0-0ubuntu1~cloud0
      python-nova=2:14.0.1-0ubuntu1~cloud0
      python-novaclient=2:6.0.0-0ubuntu1~cloud0
      python-openstackclient=3.2.0-0ubuntu2~cloud0
      
    3. Verwenden Sie den Befehl apt-get install, um bestimmte Versionen jedes Pakets zu installieren, indem Sie <package-name>=<version> angeben. Das Skript im vorherigen Schritt hat bequem eine Liste von ``Paket=Version``Paaren für Sie erstellt:

      # apt-get install `cat openstack-RELEASE_NAME-versions`
      

      Dieser Schritt schließt den Rollback-Vorgang ab. Sie sollten das Upgrade-Release-Repository entfernen und apt-get update ausführen, um versehentliche Upgrades zu verhindern, bis Sie das Problem lösen, das Sie veranlasst hat, Ihre Umgebung zurückzusetzen.