web-dev-qa-db-fra.com

hook a échoué: "shared-db-relation-modified" lors de l'utilisation d'OpenStack dans le même système que Juju / MAAS

J'ai essayé d'installer OpenStack sur 14.04 en utilisant une machine. J'ai réussi à obtenir l'installation de MAAS et JUJU avec deux machines, une machine à MAAS et un autre noeud sur lequel j'essaye de configurer Openstack. J'ai lu que c'était faisable, mais j'ai des problèmes, essentiellement après avoir lu ceci https://help.ubuntu.com/community/UbuntuCloudInfrastructure et en fouillant sur Internet, j'ai découvert que nova-volume est obsolète j'ai donc essayé d'utiliser cendres à la place.

J'ai utilisé ces commandes:

juju deploy mysql --to 0
juju deploy rabbitmq-server --to 0
juju deploy --config=openstack.cfg keystone --to 0
juju deploy --config=openstack.cfg nova-cloud-controller --to 0
juju deploy --config=openstack.cfg cinder --to 0
juju deploy nova-compute --to 0
juju deploy glance --to 0
juju deploy openstack-dashboard --to 0

juju add-relation keystone mysql

juju add-relation nova-cloud-controller mysql
juju add-relation nova-cloud-controller rabbitmq-server
juju add-relation nova-cloud-controller glance
juju add-relation nova-cloud-controller keystone

juju add-relation cinder nova-cloud-controller
juju add-relation cinder mysql
juju add-relation cinder rabbitmq-server
juju add-relation cinder keystone

juju add-relation nova-compute mysql
juju add-relation nova-compute:amqp rabbitmq-server:amqp
juju add-relation nova-compute glance
juju add-relation nova-compute nova-cloud-controller

juju add-relation glance mysql
juju add-relation glance keystone

juju add-relation openstack-dashboard keystone

juju expose openstack-dashboard
juju expose nova-cloud-controller

Comme vous pouvez le voir, j'ai utilisé --to 0 pour dire que je les veux tous sur le même noeud. Je peux tout commencer, mais après avoir mis en corrélation toutes les relations, j'obtiens cette erreur:

hook failed: "shared-db-relation-changed"

J'ai aussi dans l'un des journaux un message d'erreur disant l'accès refusé pour cet utilisateur et cette adresse IP.

Je crois que le problème est que juju dit aux autres services que l'adresse IP est 192.168.2.101 mais ensuite mysql configure les utilisateurs avec 127.0.0.1, ce qui signifie qu'ils ne peuvent pas se connecter.

Des idées?

Autres choses:

  • Espérons que cela va être utilisé pour un cloud privé au travail, avec une demi-douzaine d'instances.
  • Je ne veux pas utiliser devstack car tout le monde dit que ce n'est pas pour la production.
4
Tim Perry

L'utilisation de l'indicateur --to sans la conteneurisation est une très mauvaise idée. Nous avons comparé ce "Hulk Smashing". Fondamentalement, vous superposez une tonne de services qui s’attendent tous à posséder la machine.

Alors, que pouvez-vous faire pour obtenir l’isolation tout en conservant le tout sur une seule machine? La conteneurisation!

Le drapeau --to a une finesse qui vous permet de co-localiser sans risque de collision catastrophique. --to prend en charge une syntaxe telle que --to lxc:0 et --to kvm:0, qui placera le service dans des conteneurs sur la machine répertoriée. Presque tous les attributs du déploiement OpenStack peuvent être placés en toute sécurité dans des conteneurs LXC (ou KVM), à l'exception de Ceph et de nova-compute. Nova-compute car il va lui-même fournir des machines virtuelles (et KVM à l'intérieur de LXC est bizarre) et Ceph car il doit posséder des disques. Vous pouvez faire un déploiement OpenStack sans Ceph pour que ce ne soit pas un problème et que vous puissiez imbriquer KVM pour que nova-compute sur KVM afin de créer des KVM (ou LXC) devrait fonctionner.

Pour le moment, tout est une question de performance et vous ne tirerez pas grand chose de tout cela de cette configuration. Cela devrait cependant suffire pour piloter le processus.

7
Marco Ceppi