Erreurs et solutions d'installation d'OpenStack Icehouse - CentOS

J'essaie d'installer OpenStack Icehouse sur CentOS depuis près d'une semaine (depuis que je le fais pour la première fois, il a fallu une semaine pour terminer l'installation et la configuration complètes). Bien que j'aie suivi la documentation officielle, j'ai quand même dû me référer à divers forums, y compris le site de support d'openstack pour résoudre les erreurs qui m'ont bogué pendant le processus d'installation. J'ai donc pensé à capturer toutes ces erreurs et solutions qui ont fonctionné pour moi dans cet article. Vous pouvez sauter pour voir quelques erreurs et solutions que j'ai rencontrées lors de l'installation des services Keystone, Glance et Nova. J'espère que cela pourrait être utile à quelqu'un.

Eh bien, voici quelques autres…

Erreur :neutron-server n'a pas pu démarrer et non log a été écrit -  neutron mort mais le fichier pid existe

# service neutron-server start# service neutron-server statusneutron dead mais le fichier pid existe

Solution :

En règle générale, après avoir installé les services keystone, eye et nova, vous devez créer une base de données correspondante dans MySQL (généralement, les bases de données sont créées manuellement). Mais le service neutron ne l'exige pas, car le service remplira automatiquement la base de données. Cependant, il ne s'est pas comporté de cette façon et j'ai dû exécuter manuellement 'neutron-db-manage ' avant de démarrer 'serveur de neutrons'.

Remarque : Selon la documentation officielle, il est conseillé de démarrer manuellement le serveur de neutrons avant de synchroniser la base de données. Vous devez suivre les étapes ci-dessous uniquement si le service ne démarre pas.

Exécutez les commandes ci-dessous pour configurer les plugins réseau

# openstack-config --set /etc/neutron/neutron.conf PAR DÉFAUT core_plugin neutron.plugins.ml2.plugin.Ml2Plugin# openstack-config --set /etc/neutron/neutron.conf PAR DÉFAUT service_plugins neutron.services. l3_router.l3_router_plugin.L3RouterPlugin

Remplissez maintenant la base de données des neutrons…

# su -s /bin/sh -c "neutron-db-manage --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugin.ini upgrade head" neutron 

 Essayez de démarrer neutron-server. Cela a fonctionné pour moi.
 
ERREUR :le serveur a commis une erreur ou est incapable d'effectuer l'opération demandée. (HTTP 500)
 

 L'erreur ci-dessus s'est produite lorsque j'ai exécuté la commande réseau et démarrage de nova.
 
[root@gcontroller]#nova --debug network-create tg-network --bridge br100 --multi-host T --fixed-range-v4 10.180.14.160/27
 

 Solution : 
Essayez d'exécuter la commande ci-dessous…
 
[root@gcontroller]#nova-manage network créer tg-network --multi_host=T --fixed_range_v4=10.180.14.160/27 --bridge=br100 --num_networks=1 --network_size=256
 
Erreur :NetworkNotCreated :un pont est nécessaire pour créer un réseau
 
[root@gcontroller]# nova-manage network create tg-network --multi_host=T --bridge_interface=br100 --fixed_range_v4=10.180.14.160/27Échec de la commande, veuillez consulter le journal pour plus d'informations
 

 Consultez le journal des erreurs pour plus d'informations…
 
[root@gcontroller]#tailf /var/log/nova/nova-manage.log2015-02-06 18:33:07.656 5080 CRITICAL nova [req-750edab1-9736-4cff-9395-e596f316e596 Aucun Aucun] NetworkNotCreated :un pont est nécessaire pour créer un réseau.
 

 Solution : 
 

 Comme le message d'erreur ci-dessus l'indique, vous devez spécifier le bridge_interface pour créer un réseau. Donc, la commande se déroule comme ci-dessous..Recherchez '–bridge_interface=br100  ‘
 
[root@gcontroller]#nova-manage network créer tg-network --multi_host=T --fixed_range_v4=10.180.14.160/27 --bridge_interface=br100 --num_networks=1 --network_size=256[root@gcontroller ]# nova net-list+--------------------------------------+----- ----+------------------+| identifiant | Étiquette | CIDR |+-------------------------------------------+-------- -+------------------+| 60dfd46a-4649-4758-8b8d-88cc562b9b39 | réseau tg | 10.180.14.160/27 |+-----------------------------------------+---- -----+------------------+
 
Erreur :Nécessite une version supérieure de pyparsing – Requirement.parse('pyparsing>=2.0.1')
 
# neutron net-create ext-net --shared --router:external=True (pyparsing 1.5.6 (/usr/lib/python2.6/site-packages), Requirement.parse('pyparsing>=2.0 .1')) L'objet 'Namespace' n'a pas d'attribut 'debug'
 

 Solution : 
 

 Il est clair que vous devez installer une version supérieure de pyparsing. Le moyen le plus simple d'installer n'importe quel module python est d'utiliser 'pip ' ou 'easy_install ‘.
 
parsage py easy_install
 

 Mais vous savez, parfois compiler et installer le module ne fonctionnera que. Dans ce cas, vous pouvez télécharger la dernière version de pyparsing ici.
 
[root@gcontroller pyparsing-2.0.1]# python setup.py buildrunning buildrunning build_pycreating buildcreating build/libcopying pyparsing.py -> build/lib[root@gcontroller pyparsing-2.0.1]# python setup.py installrunning installrunning buildrunning build_pyrunning install_libcopying build/lib/pyparsing.py -> /usr/lib/python2.6/site-packagesbyte-compiling /usr/lib/python2.6/site-packages/pyparsing.py vers pyparsing.pycrunning install_egg_infoWriting /usr/ lib/python2.6/site-packages/pyparsing-2.0.1-py2.6.egg-info
 
Erreur :INFO nova.wsgi [-] Arrêt du serveur WSGI | INFO nova.openstack.common.service [-] SIGTERM capturé, sortant | [Errno 111] Connexion refusée
 

 J'ai eu l'erreur ci-dessus lorsque j'ai exécuté l'une des commandes nova.
 
[root@gcontroller]# nova net-listERROR :[Errno 111] Connexion refusée
 

 Les fichiers journaux sous /var/log/nova a révélé l'erreur ci-dessus.
 
INFO nova.wsgi [-] Arrêt du serveur WSGI.INFO nova.wsgi [-] Le serveur WSGI s'est arrêté.INFO nova.wsgi [-] Le serveur WSGI s'est arrêté.INFO nova.wsgi [-] Le serveur WSGI s'est arrêté. INFO nova.openstack.common.service [-] SIGTERM intercepté, sortie
 

 Solution : 
 

 Chaque fois que vous voyez l'erreur "Connexion refusée", il est clair que l'un des services nécessaires ne fonctionne pas correctement. Après le débogage, j'ai compris que lorsque je démarre 'openstack-nova-metadata-api ', il tue 'openstack-nova-api ' un service. La raison en était que openstack-nova-api exécutait déjà "metadata-api" avec lui et lorsque je démarre "openstack-nova-metadata-api" séparément, cela a tué l'autre service.
 

 Pour résoudre le problème,
 
 
$vi /etc/nova/nova.conf 
 
Recherchez 'enabled_apis  ‘ et sa valeur ‘ec2,osapi_compute,metadata  ‘
 
Supprimer les "métadonnées" de "enabled_apis"
 
Maintenant, vous êtes prêt à démarrer à la fois 'openstack-nova-api ' et 'openstack-nova-metadata-api ‘. Les deux services fonctionneront individuellement.
 
 

 Au cas où, si vous souhaitez démarrer 'metadata-api' avec 'openstack-nova-api', laissez 'enabled_apis' avec des valeurs comme 'ec2, osapi_compute,metadata' et arrêtez 'openstack-nova-metadata-api  ‘ de démarrer pendant le démarrage du système. Pour ce faire, vous pouvez simplement exécuter les commandes ci-dessous :
 
$ chkconfig openstack-nova-metadata-api désactivé$ chkconfig openstack-nova-api activé
 
Erreur :iptables-restore v1.4.6 :mauvaise adresse IP "gcompute"
 

 Ce qui précède s'est produit lorsque j'ai essayé de démarrer nova-network sur mon nœud de calcul. Les fichiers journaux sous /var/log/nova révélé le message ci-dessus.
 

 Solution : 
 
 
Ouvrir /etc/nova/nova.conf et recherchez ‘my_ip ' attribut.
 
Assurez-vous que "my_ip ' contient adresse IP comme valeur et pas le nom d'hôte ou FQDN ou localhost . Dans mon cas, il s'agissait du nom de domaine complet du nœud de calcul. Je l'ai changé en adresse IP.
 
Maintenant, redémarrez openstack-nova-network service et cela devrait fonctionner comme prévu.
 
 
ERREUR :Quota dépassé pour les instances :Demandé 1, mais déjà utilisé 10 instances sur 10 (HTTP 413)
 

 Eh bien, vous devez modifier la limite de quota par défaut pour démarrer la nouvelle instance. Pour afficher les limites de quota par défaut, exécutez la commande ci-dessous.
 
[root@gcontroller]# nova quota-defaults+----------------------------------+------- +| Contingent | Limite |+----------------------------+-------+| instances | 10 || noyaux | 20 || bélier | 51200 || flottant_ips | 10 || ips_fixes | -1 || metadata_items | 128 || fichiers_injectés | 5 || injecté_file_content_bytes | 10240 || chemin_fichier_injecté_octets | 255 || key_pairs | 100 || groupes_de_sécurité | 10 || règles_groupe_sécurité | 20 |+----------------------------+-------+
 

 La commande ci-dessous vous permettra de définir une nouvelle limite de quota.
 
[root@gcontroller]# nova quota-class-update --instances 35 default[root@gcontroller]# nova quota-defaults+-------------------- ---------+-------+| Contingent | Limite |+----------------------------+-------+| instances | 35 || noyaux | 20 || bélier | 51200 || flottant_ips | 10 || ips_fixes | -1 || metadata_items | 128 || fichiers_injectés | 5 || injecté_file_content_bytes | 10240 || chemin_fichier_injecté_octets | 255 || key_pairs | 100 || groupes_de_sécurité | 10 || règles_groupe_sécurité | 20 |+----------------------------+-------+
 
Cirros Image est démarré et actif, mais quel est le nom d'utilisateur et le mot de passe pour se connecter au terminal ?
 

 Si vous avez démarré une instance à l'aide de l'image Cirros (c'est la plus simple pour tester votre configuration) et que vous souhaitez accéder au terminal de la nouvelle instance, connectez-vous en ssh en utilisant le nom d'utilisateur "cirros" et le mot de passe "cubswin :)". 
 
#ssh [email protected]
 
Impossible de se connecter au tableau de bord Openstack
 

 Voyez-vous "Quelque chose s'est mal passé ! Une erreur imprévue s'est produite. Essayez d'actualiser la page" lors de l'accès au tableau de bord d'openstack ?
  

 
 

 Solution : 
 

 Vérifiez si vous avez défini les valeurs appropriées pour les attributs ci-dessous dans '/etc/openstack-dashboard/local_settings ‘
 
OPENSTACK_HOST ="gcontroller.org.in"OPENSTACK_KEYSTONE_URL ="http://%s:5000/v2.0" % OPENSTACK_HOSTOPENSTACK_KEYSTONE_DEFAULT_ROLE ="admin"
 

 Dans mon cas, j'ai dû changer ‘OPENSTACK_KEYSTONE_DEFAULT_ROLE =“_member_ " ‘ à ‘OPENSTACK_KEYSTONE_DEFAULT_ROLE ="administrateur " ‘
 
[error] SuspiciousOperation :en-tête HTTP_HOST non valide (vous devrez peut-être définir ALLOWED_HOSTS)
 

 Solution : 
 

 Vous devez définir ALLOWED_HOSTS  attribut dans '/etc/openstack-dashboard/local_settings ‘. La valeur de ALLOWED_HOSTS doit également contenir l'adresse IP du nœud de contrôleur (le nœud qui exécute le service de tableau de bord).
 
ALLOWED_HOSTS =['10.180.5.50', '10.180.5.49', '10.180.10.132']
 
Et le bonus est là…
 
 Téléchargez l'ebook gratuit sur l'installation d'OpenStack Icehouse ! 
 Téléchargez l'aide-mémoire de l'interface de ligne de commande OpenStack ! - Commandes les plus couramment utilisées