☰

Openstack Autopilot дает сбой при развертывании Landscape

tag-icon • tag-icon juju maas openstack landscape openstack-autopilot
Openstack Autopilot дает сбой при развертывании Landscape

Обновлять:

Дальнейшее расследование показало, что контейнеры LXC не получали IP-адреса во время установки.

Но если оставить контейнеры LXC на несколько часов, они в конечном итоге получат IP-адрес от MAAS.

Итак, сегодня утром я взял кластер и переместил его с очень дорогого коммутатора Cisco L3 на дешевый коммутатор Dell L2. DHCP-адреса мгновенно получаются всеми контейнерами LXC, а установщик Openstack завершил работу без единой заминки. Возможно, нам нужно будет сделать какие-то настройки конфигурации на коммутаторе Cisco, но пока мы будем поддерживать сеть простой, пока будем экспериментировать с программным обеспечением в нашей лаборатории.

Много времени потрачено на эту довольно раздражающую и странную проблему! Большое спасибо за ваши усилия.

У нас имеется стек из 5 узлов машин, настроенных в MAAS.

Они нормально запускаются и останавливаются, однако при развертывании Openstack Autopilot в Ubuntu возникает ошибка:

./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

Не уверен, связано ли это, но у меня есть работающее развертывание в другой лаборатории, и единственное отличие, которое я вижу, заключается в том, что в нерабочей лаборатории на узле juju boostrap установлено /var/lib/juju/agents/machine-0/agent.confзначение SECURE_STATESERVER_CONNECTION: "true", а версия — 1.22.0.

В рабочей среде SECURE_STATESERVER_CONNECTION: "true" отсутствует, а версия — 1.21.3.

решение1

Я добавлю здесь общий ответ, который может помочь другим.

При столкновении с такими проблемами, когда неясно, что именно неисправно, обычно рекомендуется действовать проще.

В этом случае попробуйте предоставить узлы в MAAS напрямую с помощью juju, а не через облачный установщик. Это должно быть намного проще и быстрее для отладки.

По этому URL-адресу можно получить инструкции по использованию juju напрямую с MAAS:https://maas.ubuntu.com/docs1.7/juju-quick-start.html

Связанный контент