Обновление:
Дополнительные исследования показывают, что контейнеры LXC не получали IP-адреса во время установки.
Но если оставить их на несколько часов, контейнеры LXC в конечном итоге получат IP от MAAS.
Итак, сегодня утром я взял кластер и переместил его с очень дорогого коммутатора Cisco L3 на дешевый коммутатор Dell L2. Адреса DHCP получаются мгновенно всеми контейнерами LXC, и установщик Openstack завершается без единой заминки. Вероятно, какой-то параметр конфигурации нам нужно сделать на коммутаторе Cisco, но пока мы будем поддерживать простоту сети, пока будем играть с программным обеспечением в нашей лаборатории.
1115 Много времени ушло на эту довольно раздражающую и странную проблему! Большое спасибо за ваши усилия.
У нас есть 5 узлов стека машин, которые настроены в MAAS.
Они прекрасно справляются с задачей, однако развертывание Ubuntu Openstack Autopilot завершается неудачно:
./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
- Больше журналов
С машины начальной загрузки juju:
/var/log/juju/all-machines.log
http://paste.ubuntu.com/10724991/
Я не могу понять это, я просто показываю ниже и снова и снова, пока не произойдет сбой:
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
Не уверен, что это связано, но у меня есть рабочее развертывание в другой лаборатории и единственное отличие, которое я вижу, состоит в том, что в нерабочей лаборатории на узле jump boostrap в /var/lib/juju/agents/machine-0/agent.conf
установлено значение SECURE_STATESERVER_CONNECTION: "true"
, а версия - 1.22.0
.
В рабочей среде SECURE_STATESERVER_CONNECTION: "true"
отсутствует и версия 1.21.3
.
Я добавлю общий ответ здесь, который мог помочь другим.
При обнаружении с такими проблемами, где не ясно, что перестало работать, общее предложение должно пойти простое.
В этом случае, попытайтесь настроить узлы в МААСЕ непосредственно с амулетом вместо того, чтобы пройти облачный установщик. Это должно быть намного легче и быстрее для отладки.
Этот URL имеет инструкции относительно использовать амулет с МААСОМ непосредственно: https://maas.ubuntu.com/docs1.7/juju-quick-start.html