Juju / MAAS no vSphere para testar o OpenStack

Question

Eu tenho a configuração abaixo em meu laboratório vSphere para testar a implantação do Openstack com o juju.

1. O servidor MAAS vm tem 2 interfaces [uma tem acesso à internet usando proxy e outra interna 192.168 n / w para dhcp e dns] (versão de lançamento)
2. Os nós MAAS têm uma interface em 192.168 n / w. (liberação quantal)
3. Ter um Espelho local de quantal para o nó MAAS para inicialização de pxe.

Eu sou capaz de fazer o bootstrap do meu ambiente juju e um nó no servidor MAAS tem Alocado para isso. Como o WOL não está disponível no vSphere vms, inicializei essa VM específica (node3.juju.local) manualmente.

Após a inicialização do pxe estar concluída.

Minhas Observações

• Não é possível obter o status juju no servidor MAAS. ficar preso aqui

  2013-10-22 06:18:27 INFO juju.state open.go: 68 estado de abertura; endereços mongo: ["node3.juju.local: 37017"]; entidade ""

• Por isso, efetuei login na máquina node3.juju.local .

• últimas linhas de /var/log/cloud-init-output.log

  2013-10-21 13:04:56 DEBUG juju.state open.go: 88 falha na conexão, tentará novamente: discar tpp 127.0.0.1:37017: conexão recusada

  2013-10-21 13:04:57 DEBUG juju.state open.go: 88 falha na conexão, tentará novamente: discar tpp 127.0.0.1:37017: conexão recusada

  2013-10-21 13:04:57 ERRO juju.agent agent.go: 470 falha ao inicializar estado: não há servidores acessíveis

  2013-10-21 13:04:57 ERRO juju supercommand.go: 282 servidores não alcançáveis

  * 2013-10-21 13: 04: 57,960 - util.py [AVISO]: Falha ao executar / var / lib / cloud / instance / scripts / runcmd [1] 2013-10-21 13: 04: 57,962 - cc_scripts_user.py [AVISO]: Falha ao executar o script de módulo-user (scripts em / var / lib / cloud / instance / scripts) *

  2013-10-21 13: 04: 57,963 - util.py [AVISO]: A execução de scripts-user () falhou

  Cloud-init v. 0.7 concluído em seg, 21 out 2013 13:04:57 +0000. Datasource DataSourceMAAS [http://192.168.124.10/MAAS/metadata/]. Até 1532,83 segundos

  Cloud-init v. 0.7 executando 'init-local' em seg, 21 out 2013 15:53:08 +0000. Até 3,88 segundos.

• É claro que o MongoDB não está iniciado. Verifiquei isso passando pelo script runcmd (cloud-init) e cloud-init-output.log

• A versão do Mongod instalada 2.0.6 e o mongod não tinham opções abaixo opções de SSL:

  - sslOnNormalPorts usam ssl em portas configuradas

  - sslPEMKeyFile arg Arquivo PEM para ssl

  - sslPEMKeyPassword arg Senha do arquivo PEM

• que é mencionado no script runcmd (cloud-init)

  * exec / usr / bin / mongod --auth - dbpath = / var / lib / juju / db --sslOnNormalPorts --sslPEMKeyFile '/var/lib/juju/server.pem' --sslPEMKeyPassword ignorado - bind_ip 0.0.0.0 --port 37017 --noprealloc --syslog --smallfiles *

1. Qual poderia ser o problema? se o nó maas não tem acesso à internet é o problema?

2. Minha configuração do juju + LXC raring funciona bem, então copiei os binários mongo necessários da máquina para a máquina node3.juju.local e reiniciei o servidor, desta vez o mongod começou, mas o status do juju não dar o erro abaixo (DNS, nslookup todos são adequados)

   2013-10-22 06:18:27 INFO juju.state open.go: 68 estado de abertura; endereços mongo: ["node3.juju.local: 37017"]; entidade ""

   2013-10-22 06:28:27 ERRO juju supercommand.go: 282 Não é possível conectar-se ao ambiente "maas".

   Por favor, verifique suas credenciais ou use 'juju bootstrap' para criar um novo ambiente.

   Detalhes do erro:

   não há servidores acessíveis

Answer 1

Eu tive o mesmo problema em um ambiente muito similar (rodando o Juju e o MAAS no VSphere). Primeiro, também achei que o problema era o MongoDB, então atualizei a versão no nó de bootstrap. Mas o que resolveu o problema é ter as configurações de DNS corretas no nó em que você está executando o juju-core porque ele está usando FQDNs ao se conectar a nós. Portanto, verifique se é possível efetuar ping no nó de inicialização usando o FQDN.

    

Answer 2

Como isein disse, seu problema pode estar relacionado à resolução de DNS para este domínio específico que não está acontecendo em seu servidor MAAS.

Para testar isso, você pode colocar uma linha em primeiro lugar dentro do seu arquivo / etc / hosts:

nameserver <IP address you are using for managing DHCP/DNS on MAAS>

Consegui resolver o mesmo problema que o seu por esse meio. Para obter esta modificação permanente, você pode adicionar esta linha em "/etc/resolvconf/resolv.conf.d/head"

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver <IP>

Este arquivo será usado na inicialização pelo resolvconf para construir seu arquivo / etc / hosts.