Openstack Autopilot échoue lors du déploiement de Landscape
Mise à jour:
Une enquête plus approfondie montre que les conteneurs LXC n'obtenaient pas d'adresses IP lors de l'installation.
Mais s'ils sont laissés pendant plusieurs heures, les conteneurs LXC obtiennent finalement une IP du MAAS.
Donc ce matin, j'ai pris le cluster et l'ai déplacé d'un commutateur Cisco L3 très cher vers un commutateur Dell L2 bon marché. Les adresses DHCP sont obtenues instantanément par tous les conteneurs LXC et le programme d'installation d'Openstack terminé sans aucun accroc. Probablement une sorte de paramètre de configuration que nous devons effectuer sur le commutateur Cisco, mais pour le moment, nous garderons le réseau simple pendant que nous jouerons avec le logiciel dans notre laboratoire.
Beaucoup de temps consacré à cette question plutôt irritante et étrange! Merci beaucoup pour vos efforts.
Nous avons une pile de 5 nœuds de machines qui sont configurées dans MAAS.
Ils montent et descendent très bien, mais le déploiement du pilote automatique Openstack d'Ubuntu échoue avec:
./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
- Plus de journaux
Depuis la machine juju bootstrap:
/var/log/juju/all-machines.log
http://paste.ubuntu.com/10724991/
Je ne peux pas comprendre cela, cela montre encore et encore ce qui suit jusqu'à ce qu'il échoue:
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
Je ne sais pas si cela est lié mais j'ai un déploiement fonctionnel dans un autre laboratoire et la seule différence que je vois est que dans le laboratoire non fonctionnel sur le nœud juju boostrap dans /var/lib/juju/agents/machine-0/agent.conf la valeur SECURE_STATESERVER_CONNECTION: "true" est défini et la version est 1.22.0.
Sur l'environnement de travail SECURE_STATESERVER_CONNECTION: "true" est manquant et la version est 1.21.3.
J'ajouterai ici une réponse générale qui pourrait aider les autres.
Lorsque vous rencontrez de tels problèmes, où il n'est pas clair ce qui échoue, la suggestion générale est d'aller simple.
Dans ce cas, essayez de provisionner les nœuds dans MAAS directement avec juju au lieu de passer par le programme d'installation du cloud. Il devrait être beaucoup plus facile et plus rapide à déboguer.
Cette URL contient des instructions sur l'utilisation directe de juju avec MAAS: https://maas.ubuntu.com/docs1.7/juju-quick-start.html