Le déploiement de Openstack de Landscape échoue lors de la configuration des zones de disponibilité
Utilisation de l'option "OpenStack Beta" de Landscape actuelle pour déployer OpenStack sur ma configuration MAAS. J'arrive à 98% de réalisation, avec 1 échec sur "Configurer les zones de disponibilité". Mes paramètres utilisaient KVM, Open vSwitch et j'utilise actuellement Ceph pour le stockage des objets et des blocs. Lorsque je regarde le /var/log/landscape/job-handler-1.log sur la machine de paysage, on constate plus de 100 erreurs concernant:
2015-03-05 21:18:38 Echec de la tentative de réessayer root pour '_get_nova_info', tentative de 103 fois plus de temps: 2015-03-05 21:18:38 INFO de trace root:: Il manque 4 unités de calcul nova
/usr/lib/python2.7/threading.py: 783: __ bootstrap
/usr/lib/python2.7/threading.py: 810: __ bootstrap_inner
/usr/lib/python2.7/threading.py: 763: exécuter
--- <<exception prise 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/canonique/paysage/canonique/paysage/modèle/openstack/jobs.py: 751: _get_nova_info
NOTE: 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 le permet), et oui j'utilise la version la plus récente de landscape datée du ppa de landscape pour trusty.
J'ai donc modifié /opt/canonique/paysage/canonique/paysage/modèle/openstack/jobs.py _ get_nova_info () fonction permettant d’imprimer la longueur du nova_compute_hostnames et j’ai zéro . J'ai donc poursuivi cela dans /opt/canonical/landscape/canonical/landscape/model/openstack/region.py get_nova_compute_hostnames () et a constaté que self.juju_environment.get_computer_ids (). count () () était également zéro . J'ai donc ajouté un appel à self.juju_environment.has_computers () () et ai obtenu false . Ensuite, j'ai lancé self.juju_environment.get_juju_home () et obtenu /var/lib/landscape/juju-homes/20 . (Oui, c’est ma 20e tentative lors de ma deuxième reconstruction de la boîte de paysage, je suis dans cette situation depuis un moment). Alors j'ai couru l'état de juju en utilisant la maison de juju mentionnée ci-dessus et tout avait l'air bien. Les 5 machines et services ont tous été démarrés, sans état d’attente ou d’erreur. (y compris les 4 nœuds nova-compute) Des idées? MAAS, JUJU, & python sont quelque peu nouveaux en paysage, donc mon débogage est un peu lent.
UPDATE 1:
Selon la demande, j'ai les 2 journaux (bien que ma maison soit maintenant le numéro 23) statut de juj et broker.log . Je pense que je sais maintenant quel est mon problème d'après l'extrait de broker.log ci-dessous. (Merci dpb de m'avoir pointé là) 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 fourni par MAAS. Par conséquent, les machines provisionnées ne peuvent pas se connecter au serveur en mode paysage par leur nom.
Cela me conduit donc à une question connexe: existe-t-il un bon moyen pour que MAAS mette automatiquement à jour le DNS avec des machines non approvisionnées (ou sous le contrôle de 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] Un courtier a commencé avec config /etc/landscape/client.conf
2015-03-06 17: 09: 52,382 INFO [MainThread] Démarrage d'un échange de messages urgent avec https: // paysage/système de messagerie .
2015-03-06 17: 09: 52,389 ERREUR [PoolThread-twisted.internet.reactor-1] Erreur lors du contact avec le serveur à l'adresse https: // paysage/système de messagerie .
Traceback (dernier appel passé):
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
en-têtes = en-têtes, cainfo = self._pubkey, curl = curl))
Fichier "/usr/lib/python2.7/dist-packages/landscape/lib/fetch.py", ligne 109, à extraire
pose PyCurlError (e.args [0], e.args 1 )
PyCurlError: erreur 6: impossible de résoudre 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] Échange de messages terminé en 0.01s.
UPDATE 2:
Ma configuration est un peu limitée car il ne m’était donné que 6 machines (5 nœuds et 1 contrôleur) pour montrer les capacités d’OpenStack/Landscape, je ne pouvais donc pas utiliser une machine dédiée pour le paysage. J'utilisais le landscape-server-quickstart dans un LXC sur mon contrôleur MAAS afin que je puisse le supprimer rapidement et recommencer à zéro.
donc j'ai vidé la configuration de paysage et réglé le LXC sur une adresse IP statique, puis modifié le DNS (contrôlé par MAAS) pour avoir l'entrée DNS statique de mon serveur de paysage. Ensuite, j'ai installé Landscape Dedicated Server sur le LXC à l'aide de la méthode Landscape-Server-Quickstart mentionnée ci-dessus.
Après cette réinstallation (principalement pour nettoyer tous mes problèmes de débogage), j'ai finalement pu installer OpenStack en mode paysage. Merci.
Le message "N manquantes unités de calcul nova" concerne les agents client paysagers enregistrés dans Paysage, vérifiez /var/log/landscape/broker.log sur les unités manquantes.
MISE À JOUR:
Comme vous l'avez correctement identifié, les choses se passent mieux si LDS (Landscape Dedicated Server) est installé sur le même MAAS où votre openstack vivra, principalement à cause du routage réseau et de DNS. Cependant, il existe d'innombrables variations d'une topologie valide avec des routes entre réseaux, etc.
Quelques suggestions sur les choses à essayer, lisez-les toutes. En fin de compte, vous devrez déterminer votre topologie de déploiement:
Pour un test, déployez LDS sur le même MAAS où votre openstack sera - juste pour vérifier si les choses fonctionnent là-bas. Utilisez l'outil openstack-install , ou le paquet landscape-dense-maas avec juju-quickstart directement pour faciliter cette tâche.
Comme vous l'avez dit, vos clients doivent être en mesure de contacter LDS. S'ils peuvent acheminer par IP vers le lieu de déploiement de LDS, vous pouvez annuler l'installation d'Openstack, modifier votre paramètre de nom de serveur Apache et réessayer.
juju set Apache2 servername=IP_ADDRESS. Après cela, suivez juju debug-log, assurez-vous que tout est correct et que vous pouvez accéder à l'interface graphique de LDS à cette adresse https: // IP_ADDRESS / .