hook failed: “shared-db-relation-changed” ao usar o OpenStack no mesmo sistema que o Juju / MAAS

Question

Eu tenho tentado configurar o OpenStack no 14.04 usando uma máquina. Eu consegui arranjar a configuração do MAAS e o JUJU com duas máquinas, uma com o MAAS e outro com o qual estou tentando instalar o openstack. Eu li isso pode ser feito, mas eu estou tendo problemas, basicamente depois de ler este link e cavando em torno da internet, descobri que A nova-volume está obsoleta, então tenho tentado usar o cinder.

Eu tenho usado esses 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 você pode ver, usei --to 0 para dizer que quero todos eles no mesmo nó. Eu posso começar tudo, mas depois de ligar todas as relações eu recebo este erro:

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

Eu também em um dos logs uma mensagem de erro dizendo acesso negado para aquele usuário e esse ip.

Eu acredito que o problema é que o juju está dizendo aos outros serviços que o IP é 192.168.2.101, mas o mysql configura os usuários com 127.0.0.1, o que significa que eles não podem se conectar.

Alguma idéia?

Outras coisas:

• Esperamos que isso seja usado em uma nuvem privada no trabalho, com meia dúzia de instâncias.
• Eu não quero usar o devstack, pois todo mundo continua dizendo que não é para produção.

Answer 1

Usar --to flag sem conteinerização é uma péssima ideia. Nós comparamos este "Hulk Smashing". Basicamente, você está colocando uma tonelada de serviços em cima uns dos outros que todos esperam possuir a máquina.

Então, o que você pode fazer para obter isolamento e ainda manter tudo em uma máquina? Containerização!

O sinalizador --to tem uma sutileza sobre ele, o que permite fazer co-localização sem o potencial de colisões catastróficas. --to suporta uma sintaxe como --to lxc:0 e --to kvm:0 , que colocará o serviço em contêineres na máquina listada. Quase todos os charms da implantação do OpenStack podem ser colocados com segurança em contêineres LXC (ou KVM), com exceção de Ceph e nova-compute. Nova-compute porque ele por si só provisionará as VMs (e o KVM dentro do LXC é estranho) e o Ceph porque precisa possuir discos. Você pode fazer uma implantação do OpenStack sem o Ceph, então isso não é um problema e você pode aninhar o KVM para que o novo cálculo no KVM para criar KVMs (ou LXC) funcione.

Neste ponto, é tudo sobre performance e você não vai conseguir muito com essa configuração. Deve, no entanto, ser suficiente para pilotar o processo.