gancho falhou: "shared-db-relation-changed" ao usar OpenStack no mesmo sistema que Juju/MAAS

gancho falhou: "shared-db-relation-changed" ao usar OpenStack no mesmo sistema que Juju/MAAS

Tenho tentado configurar o OpenStack no 14.04 usando uma máquina. Consegui configurar o MAAS e inicializar o JUJU com duas máquinas, uma máquina para MAAS e outro nó no qual estou tentando configurar o openstack. Eu li que isso pode ser feito, mas estou tendo problemas, basicamente depois de ler istohttps://help.ubuntu.com/community/UbuntuCloudInfraestruturae pesquisando na internet descobri que o nova-volume está obsoleto, então estou tentando usar o cinder.

Tenho usado estes 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, eu costumava --to 0dizer que quero todos eles no mesmo nó. Posso começar tudo, mas depois de vincular todas as relações, recebo este erro:

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

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

Acredito que o problema é que 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 ideia?

Outras coisas:

  • Esperamos que isso seja usado para uma nuvem privada no trabalho, com cerca de meia dúzia de instâncias.
  • Não quero usar o devstack porque todo mundo diz que isso não é para produção.

Responder1

Usar --tosinalizador sem conteinerização é uma péssima ideia. Nós comparamos este "Hulk Smashing". Basicamente, você está sobrepondo uma tonelada de serviços uns sobre os outros e todos esperam possuir a máquina.

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

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

Neste ponto, é tudo uma questão de desempenho e você não conseguirá muito disso com esta configuração. Deveria, no entanto, ser suficiente para pilotar o processo.

informação relacionada