Openstack Autopilot échoue lors du déploiement de Landscape

Mise à jour:

Une enquête plus approfondie montre que les conteneurs LXC ne recevaient pas d'adresses IP lors de l'installation.

Mais si on les laisse pendant plusieurs heures, les conteneurs LXC finissent par obtenir une adresse IP du MAAS.

Ce matin, j’ai donc pris le cluster et l’a transféré d’un commutateur Cisco L3 très coûteux à un commutateur Dell L2 bon marché. Les adresses DHCP sont obtenues instantanément par tous les conteneurs LXC et le programme d'installation Openstack est terminé sans aucun accroc. Il est probablement nécessaire de définir un paramètre de configuration sur le commutateur Cisco, mais pour le moment, nous allons simplifier le réseau tout en jouant avec les logiciels de notre laboratoire.

Nous avons passé beaucoup de temps sur cette question plutôt irritante et étrange! Merci beaucoup pour vos efforts.

Nous avons une pile de machines à 5 nœuds configurée 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

De la machine d'amorçage juju:

/var/log/juju/all-machines.log

http://paste.ubuntu.com/10724991/

Je ne peux pas comprendre cela, il montre juste le dessous encore et encore 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 mon déploiement fonctionne dans un laboratoire différent et la seule différence que je vois est que, dans le laboratoire qui ne fonctionne pas, sur le nœud juju boostrap, /var/lib/juju/agents/machine-0/agent.confla valeur SECURE_STATESERVER_CONNECTION: "true"est définie et la version 1.22.0.

Sur l'environnement de travail SECURE_STATESERVER_CONNECTION: "true" est manquant et la version est 1.21.3.

— Leon Roy
source

Il a abandonné après avoir atteint le délai d'attente. Pouvez-vous vérifier si, pendant le déploiement, si les nœuds principaux sont sous tension et s'ils semblent installer des éléments? Mieux encore, essayez de conduire MAAS directement avec juju en premier et de voir que cela fonctionne: maas.ubuntu.com/docs1.7/juju-quick-start.html Il est également beaucoup plus facile de déboguer.

— Andreas Hasenack

D'après ce que j'ai compris, l'un des nœuds est sous tension et Juju y est déployé. Plusieurs LXC sont créés sur ce nœud et Juju tente de déployer le paysage sur ceux-ci. Il semble rester en place quelque part et ne parvient jamais au stade où il commence à s’alimenter sur d’autres nœuds MAAS. Je crois que cela se produit lorsque vous cliquez sur Installer dans l'assistant de pilote automatique Paysage.

— Leon Roy

Essayez de récupérer les journaux de l'unité dans / var / log / juju / à partir du nœud d'amorçage et des conteneurs (je pense que le répertoire du nœud d'amorçage contient également les journaux des conteneurs) et de les mettre à disposition quelque part, ou de les inspecter. Lorsque l'installation échoue avec un délai d'expiration à ce stade précoce, il s'agit généralement d'un problème lié au réseau.

— Andreas Hasenack

salut andreas, en parcourant all-machines.log et lxc-monitord.log, je ne suis pas au courant du problème. Tout aperçu des journaux fournis serait apprécié.

— Leon Roy

Êtes-vous sûr que la pâte 10715336 provient de tout-machines.log? Je suggère de coller tous les journaux de / var / log / juju /. Vous pouvez également essayer de provisionner des nœuds dans MAAS directement avec juju au lieu de passer par l'installateur cloud. Il devrait être plus facile de déboguer si le problème persiste ( maas.ubuntu.com/docs1.7/juju-quick-start.html ).

— Andreas Hasenack

Je vais ajouter une réponse générale ici qui pourrait aider les autres.

Lorsque nous rencontrons de tels problèmes, où l’on ne sait pas ce qui ne va pas, la suggestion générale est de faire simple.

Dans ce cas, essayez de provisionner des nœuds dans MAAS directement avec juju au lieu de passer par l'installateur cloud. Il devrait être beaucoup plus facile et rapide de déboguer.

Cette URL contient des instructions sur l'utilisation de juju avec MAAS directement: https://maas.ubuntu.com/docs1.7/juju-quick-start.html

— Andreas Hasenack
source