Utilisation de l'option «OpenStack Beta» du paysage actuel pour déployer OpenStack sur ma configuration MAAS. J'arrive à 98% d'achèvement, avec 1 échec sur «Configurer les zones de disponibilité». Mes paramètres utilisaient KVM, Open vSwitch et j'utilise actuellement Ceph pour le stockage d'objets et de blocs. Quand je regarde le /var/log/landscape/job-handler-1.log sur la machine paysage, on voit plus de 100 erreurs sur:
2015-03-05 21:18:38 INFO root RetryingCall pour '_get_nova_info' a échoué, essayant 103 fois de plus: 2015-03-05 21:18:38 INFO root Traceback:: Manquant 4 unités de nova-compute
/ 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
--- < exception interceptée ici> ---
/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
REMARQUE : le numéro de ligne dans jobs.py est désactivé car j'ai ajouté des instructions d'impression pour le débogage. C'est l'assertion dans la fonction _get_nova_info () près de la ligne # 741 (si la mémoire est bonne), et oui j'utilise la dernière version de paysage à partir d'aujourd'hui à partir du paysage ppa pour fidèle.
Donc , j'ai modifié /opt/canonical/landscape/canonical/landscape/model/openstack/jobs.py « s _get_nova_info () fonction d'imprimer la longueur des nova_compute_hostnames et je suis arrivé à zéro . Donc , je chassais que dans /opt/canonical/landscape/canonical/landscape/model/openstack/region.py de » les get_nova_compute_hostnames () et a constaté que self.juju_environment.get_computer_ids (). Count () était aussi nul . J'ai donc ajouté un appel à self.juju_environment.has_computers () et j'ai obtenu false . Ensuite, j'ai couru self.juju_environment.get_juju_home () et j'ai/ var / lib / landscape / juju-homes / 20 . (Oui, c'est ma 20e tentative lors de ma 2e reconstruction de la boîte paysage, j'y suis depuis un certain temps). J'ai donc couru le statut juju en utilisant la maison juju mentionnée ci-dessus et tout allait bien. Les 5 machines et services ont été démarrés, aucun état en attente ou d'erreur. (y compris les 4 nœuds nova-compute) Des idées? Je suis un peu nouveau dans le paysage, MAAS, JUJU et python, donc mon débogage est un peu lent.
MISE À JOUR 1:
Selon la demande, j'ai les 2 journaux (bien que ma maison soit maintenant n ° 23) juju status et broker.log . Je pense que je sais maintenant quel est mon problème par l'extrait de broker.log ci-dessous. (Merci dpb de m'avoir indiqué ici) Ma machine MAAS donne l'adresse DHCP à mon paysage LXC, mais mon paysage LXC n'est pas dans le DNS contrôlé par MAAS car il n'est pas provisionné par MAAS. Par conséquent, les machines provisionnées ne peuvent pas se connecter au serveur paysage par leur nom.
Cela m'amène donc à une question connexe. Existe-t-il un bon moyen pour MAAS de mettre à jour automatiquement le DNS avec des machines qui ne sont pas provisionnées (ou sous contrôle MAAS)? Sinon, je devrai lui donner une adresse IP statique en dehors de ma plage DHCP et définir manuellement le DNS.
2015-03-06 17: 09: 50,665 INFO [MainThread] Le courtier a commencé avec config /etc/landscape/client.conf
2015-03-06 17: 09: 52,382 INFO [MainThread] Début de l'échange urgent de messages avec https: // paysage / message-system .
2015-03-06 17: 09: 52,389 ERREUR [PoolThread-twisted.internet.reactor-1] Erreur de contact avec le serveur sur https: // paysage / système de messages .
Traceback (dernier appel le plus récent):
Fichier "/usr/lib/python2.7/dist-packages/landscape/broker/transport.py", ligne 71, en échange
message_api)
Fichier "/usr/lib/python2.7/ dist-packages / landscape / broker / transport.py ", ligne 45, dans _curl
headers = headers, cainfo = self._pubkey, curl = curl))
Fichier "/usr/lib/python2.7/dist-packages/landscape/lib/fetch.py", ligne 109, en lecture fetch
PyCurlError (e.args [0], e.args 1 )
PyCurlError: erreur 6: pourrait ne résout pas l'hôte: paysage
2015-03-06 17: 09: 52,390 INFO [MainThread] L'échange de messages a échoué.
2015-03-06 17: 09: 52,391 INFO [MainThread] L'échange de messages s'est terminé en 0.01s.
MISE À JOUR 2:
Ma configuration est un peu limitée car je n'ai reçu que 6 machines (5 nœuds et 1 contrôleur) pour montrer les capacités d'OpenStack / Landscape, donc je ne peux pas utiliser une machine dédiée pour le paysage. J'utilisais le paysage-serveur-quickstart dans un LXC sur mon contrôleur MAAS afin que je puisse le souffler rapidement et recommencer à zéro.
J'ai donc fait sauter la configuration du paysage et défini le LXC sur une IP statique, puis modifié le DNS (contrôlé par MAAS) pour avoir l'entrée DNS statique pour mon serveur de paysage. J'ai ensuite installé Landscape Dedicated Server sur le LXC en utilisant la méthode paysage-serveur-quickstart mentionnée ci-dessus.
Après cette réinstallation (principalement pour nettoyer tous mes dégâts de débogage), j'ai finalement pu installer OpenStack en mode paysage. Merci.