Atualizar:
Mais investigações mostram que os contêineres LXC não estavam recebendo IPs durante a instalação.
Mas se forem deixados por várias horas, os contêineres LXC eventualmente receberão um IP do MAAS.
Então, esta manhã peguei o cluster e mudei-o de um switch Cisco L3 muito caro para um switch Dell L2 barato. Os endereços DHCP são obtidos instantaneamente por todos os contêineres LXC e o instalador Openstack é concluído sem nenhum problema. Provavelmente algum tipo de configuração que precisamos fazer no switch Cisco, mas por enquanto manteremos a rede simples enquanto brincamos com o software em nosso laboratório.
Muito tempo gasto nesta questão um tanto irritante e estranha! Muito obrigado por seus esforços.
Temos uma pilha de máquinas de 5 nós configuradas no MAAS.
Eles sobem e descem perfeitamente, mas a implantação do Openstack Autopilot do Ubuntu falha com:
./cloud-install/commands.log:
http://paste.ubuntu.com/10676002/
machine-0.log:
2015-03-24 16:49:19 ERROR juju.worker runner.go:219 exited "api": unable to connect to "wss://localhost:17070/"
2015-03-24 16:49:22 ERROR juju.rpc server.go:554 error writing response: EOF
2015-03-24 16:49:45 ERROR juju.state.unit unit.go:665 unit apache2/0 cannot get assigned machine: unit "apache2/0" is not assigned to a machine
2015-03-24 16:49:45 ERROR juju.state.unit unit.go:665 unit apache2/0 cannot get assigned machine: unit "apache2/0" is not assigned to a machine
2015-03-24 16:49:50 ERROR juju.state.unit unit.go:665 unit haproxy/0 cannot get assigned machine: unit "haproxy/0" is not assigned to a machine
2015-03-24 16:49:50 ERROR juju.state.unit unit.go:665 unit haproxy/0 cannot get assigned machine: unit "haproxy/0" is not assigned to a machine
-- Mais registros
Da máquina de inicialização juju:
/var/log/juju/all-machines.log
http://paste.ubuntu.com/10724991/
Não consigo entender isso, estou apenas mostrando o abaixo repetidamente até falhar:
machine-0: 2015-04-02 13:50:10 INFO juju.worker runner.go:261 start "api"
machine-0: 2015-04-02 13:50:10 INFO juju.api apiclient.go:252 dialing "wss://localhost:17070/"
machine-0: 2015-04-02 13:50:10 INFO juju.api apiclient.go:260 error dialing "wss://localhost:17070/": websocket.Dial wss://localhost:17070/: dial tcp 127.0.0.1:17070: connection refused
machine-0: 2015-04-02 13:50:10 ERROR juju.worker runner.go:219 exited "api": unable to connect to "wss://localhost:17070/"
machine-0: 2015-04-02 13:50:10 INFO juju.worker runner.go:253 restarting "api" in 3s
Não tenho certeza se isso está relacionado, mas tenho uma implantação funcional em um laboratório diferente e a única diferença que vejo é que no laboratório que não funciona no nó juju boostrap o /var/lib/juju/agents/machine-0/agent.confvalor SECURE_STATESERVER_CONNECTION: "true"está definido e a versão é 1.22.0.
No ambiente de trabalho SECURE_STATESERVER_CONNECTION: "true" está faltando e a versão é 1.21.3.
Responder1
Acrescentarei aqui uma resposta geral que pode ajudar outras pessoas.
Ao encontrar esses problemas, onde não está claro o que está falhando, a sugestão geral é simplificar.
Nesse caso, tente provisionar nós no MAAS diretamente com juju em vez de passar pelo instalador em nuvem. Deve ser muito mais fácil e rápido depurar.
Este URL contém instruções sobre como usar o juju diretamente com o MAAS:https://maas.ubuntu.com/docs1.7/juju-quick-start.html