web-dev-qa-db-fra.com

Juju / MAAS dans vSphere pour tester OpenStack

J'ai la configuration ci-dessous dans mon laboratoire vSphere pour tester le déploiement d'Openstack avec juju.

  1. Le serveur MAAS vm possède 2 interfaces [une avec accès Internet via proxy et une autre interne 192.168 n/w pour dhcp et dns] (version raring)
  2. Les nœuds MAAS ont une interface en 192.168 n/w. (libération quantique)
  3. Avoir un miroir local de quantique pour que le nœud MAAS démarre avec pxe.

Je peux bootstrap mon environnement juju et un nœud sous le serveur MAAS ont obtenu alloué pour cela. Parce que WOL n'est pas disponible dans vSphere vms, j'ai démarré ce VM (node3.juju.local) spécifique manuellement.

Une fois le démarrage du pxe terminé.

Mes observations

  • Impossible d'obtenir le statut juj sur le serveur MAAS. rester coincé ici

    22/10/2013 06:18:27 INFO juju.state open.go: 68 état d'ouverture; adresses mongo: ["node3.juju.local: 37017"]; entité ""

  • J'ai donc connecté à la machine node3.juju.local .

  • dernières lignes de / var/log/cloud-init-output.log

    21/10/2013 13:04:56 DEBUG juju.state open.go: 88 connexion a échoué, réessayera: composez tcp 127.0.0.1:37017: connexion refusée

    2013-10-21 13:04:57 DEBUG juju.state open.go: 88 connexion a échoué, réessayera: composez tcp 127.0.0.1:37017: connexion refusée

    21/10/2013 13:04:57 ERREUR juju.agent agent.go: 470 n'a pas réussi à initialiser l'état: aucun serveur accessible

    21/10/2013 13:04:57 ERREUR juju supercommand.go: 282 aucun serveur accessible

    * 2013-10-21 13: 04: 57,960 - util.py [AVERTISSEMENT]: Échec de l'exécution de/var/lib/cloud/instance/scripts/runcmd [1] 2013-10-21 13: 04: 57,962 - cc_scripts_user.py [AVERTISSEMENT]: Échec de l'exécution du module scripts-user (scripts dans/var/lib/cloud/instance/scripts) *

    21/10/2013 13: 04: 57,963 - util.py [AVERTISSEMENT]: Échec de l'exécution de scripts-user ()

    Cloud-init v. 0.7 terminé le lun.21 oct.2013 13:04:57 +0000. Datasource DataSourceMAAS [http://192.168.124.10/MAAS/metadata/]. Jusqu'à 1532,83 secondes

    Cloud-init v. 0.7 exécutant 'init-local' le lundi 21 octobre 2013 15:53:08 +0000. Jusqu'à 3,88 secondes.

  • Il est clair que MongoDB n'est pas démarré J'ai vérifié cela en passant par runcmd (cloud-init) script et cloud-init-output.log

  • La version Mongod installée 2.0.6 et mongod n'avait pas d'options ci-dessous Options SSL:

    - sslOnNormalPorts utilise SSL sur les ports configurés

    - sslPEMKeyFile arg Fichier PEM pour ssl

    - sslPEMKeyPassword arg Mot de passe du fichier PEM

  • qui est mentionné dans runcmd script (cloud-init)

    * exec/usr/bin/mongod --auth --dbpath =/var/lib/juju/db --sslOnNormalPorts --sslPEMKeyFile '/var/lib/juju/server.pem' --sslPEMKeyPassword ignoré --bind_ip 0.0. 0.0 --port 37017 --noprealloc --syslog --smallfiles *

  1. Quel pourrait être le problème? si le nœud maas n'a pas accès à Internet est le problème?

  2. Ma configuration raring juju + LXC fonctionne bien, j'ai donc copié les binaires mongo requis de cette machine sur la machine node3.juju.local et redémarré le serveur cette fois mongod a commencé mais le statut juju n'a pas donné l'erreur ci-dessous (DNS, nslookup tous sont corrects)

    22/10/2013 06:18:27 INFO juju.state open.go: 68 état d'ouverture; adresses mongo: ["node3.juju.local: 37017"]; entité ""

    22/10/2013 06:28:27 ERREUR juju supercommand.go: 282 Impossible de se connecter à l'environnement "maas".

    Veuillez vérifier vos informations d'identification ou utiliser 'juju bootstrap' pour créer un nouvel environnement.

    Détails de l'erreur:

    aucun serveur accessible

jujumaasmongodb
3
jkraj

J'ai eu le même problème dans un environnement très similaire (exécutant Juju et MAAS dans VSphere). J'ai d'abord pensé que le problème était MongoDB, j'ai donc mis à jour la version sur le nœud bootstrap. Mais ce qui a résolu le problème, c'est d'avoir les bons paramètres DNS sur le nœud sur lequel vous exécutez le juju-core. car il utilise des noms de domaine complets lors de la connexion aux nœuds. Assurez-vous donc que vous pouvez envoyer une requête ping au nœud bootstrap à l'aide du nom de domaine complet).

3
isein

Comme l'a dit isein, votre problème peut être lié à la résolution DNS pour ce domaine spécifique qui ne se produit pas sur votre serveur MAAS.

Afin de tester cela, vous pouvez mettre une ligne à la première place dans votre fichier/etc/hosts:

nameserver <IP address you are using for managing DHCP/DNS on MAAS>

J'ai réussi à résoudre le même problème que le vôtre par ce moyen. Pour obtenir cette modification permanente, vous pouvez ajouter cette ligne dans "/etc/resolvconf/resolv.conf.d/head"

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver <IP>

Ce fichier sera utilisé au démarrage par resolvconf pour construire votre fichier/etc/hosts.

0
Julien Leloup