Atualização:
Mais investigações mostram que os contêineres LXC não estavam recebendo IPs durante a instalação.
Mas se ficarem por várias horas, os contêineres LXC acabam recebendo um IP do MAAS.
Então, esta manhã, peguei o Cluster e movi-o de um switch L3 Cisco 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 um único engate. Provavelmente algum tipo de definição de configuração que precisamos fazer no switch Cisco, mas por enquanto manteremos a rede simples enquanto jogamos com o software em nosso laboratório.
Muito tempo gasto nesta questão bastante irritante e estranha! Muito obrigado por seus esforços.
Temos uma pilha de 5 nós de máquinas configuradas no MAAS.
Eles sobem e descem muito bem, no entanto, a implantação do OpenPack Autopilot do Ubuntu falha com:
./cloud-install/commands.log:
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 bootstrap juju:
/var/log/juju/all-machines.log
Eu não consigo descobrir isso, é só mostrar o abaixo várias vezes até que ele falhe:
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 em funcionamento em um laboratório diferente e a única diferença que vejo é que no laboratório não funcionando no nó juju do boostrap em /var/lib/juju/agents/machine-0/agent.conf o valor SECURE_STATESERVER_CONNECTION: "true" é set e a versão é 1.22.0 .
No ambiente de trabalho SECURE_STATESERVER_CONNECTION: "true" está faltando e a versão é 1.21.3 .
Vou adicionar uma resposta geral aqui que poderia ajudar os outros.
Quando se deparam com 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 o juju em vez de passar pelo instalador da nuvem. Deve ser muito mais fácil e rápido depurar.
Este URL tem instruções para usar o juju diretamente com o MAAS: link