wake-up-neo.com

Die Openstack-Bereitstellung von Landscape schlägt in Configure Availability Zones fehl

Verwenden der aktuellen "OpenStack Beta" -Option von Landscape, um OpenStack in meinem MAAS-Setup bereitzustellen. Ich bin zu 98% fertig, mit 1 Fehler in "Verfügbarkeitszonen konfigurieren". Meine Einstellungen verwendeten KVM, Open vSwitch und ich verwende derzeit Ceph sowohl für die Objekt- als auch für die Blockspeicherung. Wenn ich mir das /var/log/landscape/job-handler-1.log auf der Landscape-Maschine ansehe, werden über 100 Fehler in Bezug auf Folgendes angezeigt:

2015-03-05 21:18:38 INFO root RetryingCall für '_get_nova_info' ist fehlgeschlagen und hat 103 weitere Zeit (en) versucht: 2015-03-05 21:18:38 INFO root Traceback:: Fehlende 4 Nova-Compute-Einheiten
/usr/lib/python2.7/threading.py: 783: __ Bootstrap
/usr/lib/python2.7/threading.py: 810: __ bootstrap_inner
/usr/lib/python2.7/threading.py: 763: run
--- <Ausnahme hier erwischt> ---
/usr/lib/python2.7/dist-packages/twisted/python/threadpool.py: 191: _worker
/usr/lib/python2.7/dist-packages/twisted/python/context.py: 118: callWithContext
/usr/lib/python2.7/dist-packages/twisted/python/context.py: 81: callWithContext
/usr/lib/python2.7/dist-packages/storm/twisted/transact.py: 76: _wrap
/opt/canonical/landscape/canonical/landscape/model/openstack/jobs.py: 751: _get_nova_info


NOTE: Die Zeilennummer in jobs.py ist deaktiviert, da ich einige print-Anweisungen zum Debuggen hinzugefügt habe. Es ist die Aussage in der _get_nova_info () - Funktion in der Nähe von Zeile # 741 (wenn Speicher dient), und ja, ich verwende die neueste Version von landscape ab heute von landscape ppa für trusty.

Also habe ich die Funktion /opt/canonical/landscape/canonical/landscape/model/openstack/jobs.py geändert _ get_nova_info () zum Ausdrucken der Länge der nova_compute_hostnames und ich habe null. Also habe ich das in /opt/canonical/landscape/canonical/landscape/model/openstack/region.py 's get_nova_compute_hostnames () getrieben und das gefunden self.juju_environment.get_computer_ids (). count () war auch zero. Also habe ich self.juju_environment.has_computers () aufgerufen und false erhalten. Dann lief ich self.juju_environment.get_juju_home () und bekam /var/lib/landscape/juju-homes/20 . (Ja, dies ist mein 20. Versuch bei meinem 2. Umbau der Landschaftsbox, ich bin schon eine Weile dabei). Also habe ich juju status das oben erwähnte juju home benutzt und alles sah gut aus. Alle 5 Maschinen und Dienste wurden gestartet, keine ausstehenden oder Fehlerzustände. (einschließlich der 4 Nova-Compute-Knoten) Irgendwelche Ideen? Ich bin etwas neu in Landscape, MAAS, JUJU, & python, daher ist mein Debugging etwas langsam.


PDATE 1:

Laut der Anfrage habe ich die 2 Logs (obwohl mein Zuhause jetzt # 23 ist) juju status und broker.log . Ich glaube, ich weiß jetzt, was mein Problem ist, wie aus dem folgenden Ausschnitt von broker.log hervorgeht. (Danke, dpb, dass Sie mich dorthin geleitet haben.) Mein MAAS-Computer gibt die DHCP-Adresse an meinen Landscape-LXC weiter, aber mein Landscape-LXC befindet sich nicht im MAAS-kontrollierten DNS, da es nicht von MAAS bereitgestellt wird. Daher können die bereitgestellten Computer keine Verbindung mit dem Landscape-Server über den Namen herstellen.

Das führt mich zu einer verwandten Frage: Gibt es eine gute Möglichkeit, das DNS von MAAS automatisch mit Computern zu aktualisieren, die nicht bereitgestellt sind (oder unter der Kontrolle von MAAS stehen)? Wenn nicht, muss ich ihm eine statische IP außerhalb meines DHCP-Bereichs geben und den DNS manuell einstellen.

2015-03-06 17: 09: 50,665 INFO [MainThread] Broker wurde mit config /etc/landscape/client.conf gestartet
2015-03-06 17: 09: 52,382 INFO [MainThread] Starten des Austauschs dringender Nachrichten mit https: // landscape/message-system .
2015-03-06 17: 09: 52,389 ERROR [PoolThread-twisted.internet.reactor-1] Fehler beim Kontaktieren des Servers unter https: // landscape/message-system .
Traceback (letzter Anruf zuletzt):
Datei "/usr/lib/python2.7/dist-packages/landscape/broker/transport.py", Zeile 71, im Austausch
message_api)
Datei "/usr/lib/python2.7/dist-packages/landscape/broker/transport.py", Zeile 45, in _curl
headers = headers, cainfo = self._pubkey, curl = curl))
Datei "/usr/lib/python2.7/dist-packages/landscape/lib/fetch.py", Zeile 109, in Fetch
Raise PyCurlError (e.args [0], e.args 1 )
PyCurlError: Fehler 6: Host: landscape konnte nicht aufgelöst werden
2015-03-06 17: 09: 52,390 INFO [MainThread] Nachrichtenaustausch fehlgeschlagen.
2015-03-06 17: 09: 52,391 INFO [MainThread] Nachrichtenaustausch in 0,01 Sekunden abgeschlossen.


PDATE 2:

Mein Setup ist etwas eingeschränkt, da ich nur 6 Maschinen (5 Knoten und 1 Controller) erhalten habe, um die Fähigkeiten von OpenStack/Landscape zu demonstrieren, sodass ich keine dedizierte Maschine für Landscape verwenden kann. Ich habe Querformat-Server-Schnellstart in LXC auf meinem MAAS-Controller verwendet, damit ich es schnell wegblasen und von vorne anfangen kann.

also habe ich das Landscape-Setup weggeblasen und den LXC auf eine statische IP eingestellt und dann das DNS (von MAAS gesteuert) so geändert, dass es den statischen DNS-Eintrag für meinen Landscape-Server enthält. Dann habe ich Landscape Dedicated Server mit der oben erwähnten Landscape-Server-Schnellstartmethode auf dem LXC installiert.

Nach dieser Neuinstallation (hauptsächlich um mein Debug-Chaos zu beseitigen) war ich endlich in der Lage, OpenStack quer zu installieren. Vielen Dank.

8
Master5597

Die Nachricht "Missing N nova-compute units" (Fehlende Nova-Recheneinheiten) bezieht sich auf Landscape-Client-Agenten, die wieder in Landscape registriert sind. Überprüfen Sie /var/log/landscape/broker.log auf den fehlenden Einheiten.

AKTUALISIEREN:

Wie Sie richtig erkannt haben, funktioniert es am reibungslosesten, wenn LDS (Landscape Dedicated Server) auf demselben MAAS installiert ist, auf dem sich Ihr Openstack befindet, hauptsächlich aufgrund von Netzwerkrouting und DNS. Es gibt jedoch unzählige Variationen einer gültigen Topologie mit Routen zwischen Netzwerken usw.

Einige Vorschläge für Dinge, die Sie ausprobieren sollten, lesen Sie sie bitte alle durch. Am Ende müssen Sie Ihre Bereitstellungstopologie bestimmen:

  • Stellen Sie für einen Test LDS auf demselben MAAS bereit, auf dem sich Ihr Openstack befindet - nur um zu überprüfen, ob dort etwas funktioniert. Verwenden Sie das Tool openstack-install oder das Bundle landscape-dense-maas mit juju-quickstart, um dies zu vereinfachen.

  • Ihre Kunden müssen in der Lage sein, LDS zu erreichen, wie Sie angegeben haben. Wenn sie über die IP-Adresse an den Ort weiterleiten können, an dem LDS bereitgestellt wird, können Sie die OpenStack-Installation abbrechen, die Apache-Servernameneinstellung ändern und es erneut versuchen. juju set Apache2 servername=IP_ADDRESS. Befolgen Sie danach das juju-Debug-Protokoll, vergewissern Sie sich, dass alles in Ordnung ist, und stellen Sie sicher, dass Sie unter der URL https: // IP_ADDRESS / zur LDS-GUI navigieren können.

4
dpb