Aktualisieren:
Weitere Untersuchungen zeigen, dass die LXC-Container während der Installation keine IPs erhielten.
Wenn man die LXC-Container jedoch mehrere Stunden liegen lässt, erhalten sie schließlich eine IP vom MAAS.
Also habe ich heute Morgen den Cluster genommen und ihn von einem sehr teuren L3 Cisco-Switch auf einen billigen L2 Dell-Switch verschoben. DHCP-Adressen werden sofort von allen LXC-Containern abgerufen und das OpenStack-Installationsprogramm wurde ohne Probleme abgeschlossen. Wahrscheinlich müssen wir eine Art Konfigurationseinstellung am Cisco-Switch vornehmen, aber vorerst halten wir das Netzwerk einfach, während wir in unserem Labor mit der Software herumspielen.
Ich habe viel Zeit mit diesem ziemlich ärgerlichen und seltsamen Problem verbracht! Vielen Dank für Ihre Bemühungen.
Wir haben einen 5-Knoten-Stapel von Maschinen, die in MAAS konfiguriert sind.
Sie werden problemlos hoch- und heruntergefahren, die Bereitstellung von Ubuntus OpenStack Autopilot schlägt jedoch mit folgendem Fehler fehl:
./cloud-install/commands.log:
http://paste.ubuntu.com/10676002/
machine-0.log:
2015-03-24 16:49:19 ERROR juju.worker runner.go:219 exited "api": unable to connect to "wss://localhost:17070/"
2015-03-24 16:49:22 ERROR juju.rpc server.go:554 error writing response: EOF
2015-03-24 16:49:45 ERROR juju.state.unit unit.go:665 unit apache2/0 cannot get assigned machine: unit "apache2/0" is not assigned to a machine
2015-03-24 16:49:45 ERROR juju.state.unit unit.go:665 unit apache2/0 cannot get assigned machine: unit "apache2/0" is not assigned to a machine
2015-03-24 16:49:50 ERROR juju.state.unit unit.go:665 unit haproxy/0 cannot get assigned machine: unit "haproxy/0" is not assigned to a machine
2015-03-24 16:49:50 ERROR juju.state.unit unit.go:665 unit haproxy/0 cannot get assigned machine: unit "haproxy/0" is not assigned to a machine
-- Weitere Protokolle
Von der Juju-Bootstrap-Maschine:
/var/log/juju/all-machines.log
http://paste.ubuntu.com/10724991/
Ich komme nicht dahinter, es wird einfach immer wieder das Folgende angezeigt, bis es fehlschlägt:
machine-0: 2015-04-02 13:50:10 INFO juju.worker runner.go:261 start "api"
machine-0: 2015-04-02 13:50:10 INFO juju.api apiclient.go:252 dialing "wss://localhost:17070/"
machine-0: 2015-04-02 13:50:10 INFO juju.api apiclient.go:260 error dialing "wss://localhost:17070/": websocket.Dial wss://localhost:17070/: dial tcp 127.0.0.1:17070: connection refused
machine-0: 2015-04-02 13:50:10 ERROR juju.worker runner.go:219 exited "api": unable to connect to "wss://localhost:17070/"
machine-0: 2015-04-02 13:50:10 INFO juju.worker runner.go:253 restarting "api" in 3s
Ich bin nicht sicher, ob dies damit zusammenhängt, aber ich habe eine funktionierende Bereitstellung in einem anderen Labor und der einzige Unterschied, den ich sehe, besteht darin, dass im nicht funktionierenden Labor auf dem Juju-Boostrap-Knoten /var/lib/juju/agents/machine-0/agent.confder Wert SECURE_STATESERVER_CONNECTION: "true"festgelegt ist und die Version lautet 1.22.0.
Auf der Arbeitsumgebung SECURE_STATESERVER_CONNECTION: "true" fehlt und die Version ist 1.21.3.
Antwort1
Ich werde hier eine allgemeine Antwort hinzufügen, die anderen helfen könnte.
Wenn bei solchen Problemen nicht klar ist, woran es liegt, empfiehlt es sich im Allgemeinen, es einfach zu halten.
Versuchen Sie in diesem Fall, Knoten in MAAS direkt mit Juju bereitzustellen, anstatt den Cloud-Installer zu verwenden. Das Debuggen sollte viel einfacher und schneller sein.
Unter dieser URL finden Sie Anweisungen zur direkten Verwendung von Juju mit MAAS:https://maas.ubuntu.com/docs1.7/juju-quick-start.html