Error en el enlace: "relación-db-compartida-cambiada" cuando se usa OpenStack en el mismo sistema que Juju/MAAS

Error en el enlace: "relación-db-compartida-cambiada" cuando se usa OpenStack en el mismo sistema que Juju/MAAS

He estado intentando configurar OpenStack en 14.04 usando una máquina. Logré configurar MAAS y arrancar JUJU con dos máquinas, una máquina para MAAS y otro nodo en el que estoy intentando configurar OpenStack. He leído que se puede hacer pero estoy teniendo problemas, básicamente después de leer esto.https://help.ubuntu.com/community/UbuntuCloudInfrastructurey investigando en Internet descubrí que nova-volume está en desuso, así que he intentado usar cinder en su lugar.

He estado usando estos comandos:

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

Como puede ver, solía --to 0decir que los quiero todos en el mismo nodo. Puedo empezar todo pero después de vincular todas las relaciones aparece este error:

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

También en uno de los registros aparece un mensaje de error que dice acceso denegado para ese usuario y esa ip.

Creo que el problema es que juju les está diciendo a los otros servicios que la IP es 192.168.2.101 pero luego mysql configura a los usuarios con 127.0.0.1, lo que significa que no pueden conectarse.

¿Algunas ideas?

Otras cosas:

  • Con suerte, esto se utilizará para una nube privada en el trabajo, con media docena de instancias aproximadamente.
  • No quiero usar devstack porque todo el mundo sigue diciendo que no es para producción.

Respuesta1

Usar --tobandera sin contenerización es una muy mala idea. Hemos comparado esto con "Hulk Smashing". Básicamente, estás superponiendo un montón de servicios que esperan ser dueños de la máquina.

Entonces, ¿qué se puede hacer para lograr el aislamiento y seguir manteniendo todo en una sola máquina? ¡Contenedorización!

La --tobandera tiene una delicadeza que le permite realizar una ubicación conjunta sin la posibilidad de colisiones catastróficas. --toadmite una sintaxis como --to lxc:0y --to kvm:0que colocará el servicio en contenedores en la máquina enumerada. Casi todos los accesos en la implementación de OpenStack se pueden colocar de forma segura en contenedores LXC (o KVM), con la excepción de Ceph y nova-compute. Nova-compute porque en sí mismo aprovisionará VM (y KVM dentro de LXC es extraño) y Ceph porque necesita poseer discos. Puede realizar una implementación de OpenStack sin Ceph, por lo que eso no es un problema y puede anidar KVM para que nova-compute en KVM para crear KVM (o LXC) debería funcionar.

En este punto, todo es cuestión de rendimiento y realmente no obtendrás mucho de eso con esta configuración. Sin embargo, debería ser suficiente para poner a prueba el proceso.

información relacionada