A implementação do Openstack do Landscape falha no Configure Availability Zones

8

Usando a opção "OpenStack Beta" do Landscape atual para implantar o OpenStack na minha configuração do MAAS. Eu tenho 98% de conclusão, com 1 falha em "Configurar zonas de disponibilidade". Minhas configurações utilizavam o KVM, o Open vSwitch e atualmente utilizo o Ceph para armazenamento de objetos e blocos. Quando olho para o /var/log/landscape/job-handler-1.log na máquina de paisagem, vejo mais de 100 erros sobre:

2015-03-05 21:18:38 INFO root RetryingCall for '_get_nova_info' failed, trying 103 more time(s): 2015-03-05 21:18:38 INFO root Traceback: : Missing 4 nova-compute units
/usr/lib/python2.7/threading.py:783:__bootstrap
/usr/lib/python2.7/threading.py:810:__bootstrap_inner
/usr/lib/python2.7/threading.py:763:run
--- < exception caught here> ---
/usr/lib/python2.7/dist-packages/twisted/python/threadpool.py:191:_worker
/usr/lib/python2.7/dist-packages/twisted/python/context.py:118:callWithContext
/usr/lib/python2.7/dist-packages/twisted/python/context.py:81:callWithContext
/usr/lib/python2.7/dist-packages/storm/twisted/transact.py:76:_wrap
/opt/canonical/landscape/canonical/landscape/model/openstack/jobs.py:751:_get_nova_info

NOTE: The line number in jobs.py is off as I've added some print statements for debugging. It's the assert in the _get_nova_info() function near line #741 (if memory serves), and yes I'm using the newest version of landscape as of today from the landscape ppa for trusty.

Então eu modifiquei a função /opt/canonical/landscape/canonical/landscape/model/openstack/jobs.py _get_nova_info () para imprimir o comprimento de o nova_compute_hostnames e eu tenho zero . Então eu persegui isso em /opt/canonical/landscape/canonical/landscape/model/openstack/region.py 's get_nova_compute_hostnames () e encontrei o self. O juju_environment.get_computer_ids (). count () também era zero . Então eu adicionei uma chamada para self.juju_environment.has_computers () e obtive false . Então eu corri self.juju_environment.get_juju_home () e obtive / var / lib / landscape / juju-homes / 20 . (Sim, esta é a minha tentativa de 20 na minha segunda reconstrução da caixa de paisagem, eu estive nisso por algum tempo). Então eu corri status juju utilizando a casa juju mencionada acima e tudo parecia bem. Todas as 5 máquinas e serviços foram iniciados, sem estados pendentes ou de erro. (incluindo os 4 novos nós de computação) Alguma idéia? Eu sou um pouco novo para a paisagem, MAAS, JUJU, & python, então minha depuração é um pouco lenta.

UPDATE 1:

De acordo com o pedido, recebi os 2 logs (embora minha casa agora seja # 23) status do juju e broker.log . Acho que agora sei qual é o meu problema com o trecho de broker.log abaixo. (Obrigado dpb por me apontar lá) Minha máquina MAAS está distribuindo o endereço DHCP para o meu paisagem LXC, mas o meu ambiente LXC não está no DNS controlado pelo MAAS, pois não é provisionado pelo MAAS. Portanto, as máquinas provisionadas não podem se conectar ao servidor de paisagem pelo nome.

Então, isso me leva a uma questão relacionada. Existe uma boa maneira de fazer com que o MAAS atualize automaticamente o DNS com máquinas que não são aprovisionadas (ou sob controle do MAAS)? Se não, terei que fornecer um IP estático fora do meu intervalo DHCP e definir manualmente o DNS.

2015-03-06 17:09:50,665 INFO [MainThread] Broker started with config /etc/landscape/client.conf
2015-03-06 17:09:52,382 INFO [MainThread] Starting urgent message exchange with https://landscape/message-system.
2015-03-06 17:09:52,389 ERROR [PoolThread-twisted.internet.reactor-1] Error contacting the server at https://landscape/message-system.
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/landscape/broker/transport.py", line 71, in exchange
message_api)
File "/usr/lib/python2.7/dist-packages/landscape/broker/transport.py", line 45, in _curl
headers=headers, cainfo=self._pubkey, curl=curl))
File "/usr/lib/python2.7/dist-packages/landscape/lib/fetch.py", line 109, in fetch
raise PyCurlError(e.args[0], e.args1)
PyCurlError: Error 6: Could not resolve host: landscape
2015-03-06 17:09:52,390 INFO [MainThread] Message exchange failed.
2015-03-06 17:09:52,391 INFO [MainThread] Message exchange completed in 0.01s.

UPDATE 2:

Minha configuração é um pouco limitada, pois só recebi 6 máquinas (5 nós e 1 controlador) para mostrar os recursos do OpenStack / Landscape, portanto não posso usar uma máquina dedicada para paisagem. Eu estava usando o landscape-server-quickstart em um < um href="https://help.ubuntu.com/community/LXC"> LXC no meu controlador MAAS para que eu possa rapidamente apagá-lo e começar tudo de novo.

então eu estraguei a configuração da paisagem e configurei o LXC para um IP estático e, em seguida, modifiquei o DNS (controlado pelo MAAS) para ter a entrada de DNS estático do meu servidor de paisagem. Em seguida, instalei o Landscape Dedicated Server no LXC usando o método de início rápido do servidor paisagem mencionado acima.

Após essa reinstalação (principalmente para limpar toda a minha bagunça de depuração), finalmente consegui instalar o OpenStack, embora paisagem. Obrigado.

    
por Master5597 05.03.2015 / 23:46

1 resposta

4

A mensagem "Missing N nova-compute units" é sobre agentes paisagistas registrados de volta ao panorama, Verifique /var/log/landscape/broker.log nas unidades ausentes.

UPDATE:

Como você identificou corretamente, as coisas funcionam melhor se o LDS (Landscape Dedicated Server) estiver instalado no mesmo MAAS onde a sua openstack viverá, principalmente por causa do roteamento de rede e do DNS. No entanto, existem inúmeras variações de uma topologia válida com rotas entre redes, etc.

Algumas sugestões de coisas para experimentar, leia-as todas. No final, você precisará determinar sua topologia de implantação:

  • Para um teste, implante o LDS no mesmo MAAS em que a sua openstack estará - apenas para verificar se as coisas estão funcionando lá. Use a ferramenta openstack-install , ou o landscape-dense-maas empacote com o juju-quickstart diretamente para facilitar isso.

  • Seus clientes precisam ser capazes de alcançar o LDS, como você afirmou. Se eles puderem rotear por IP para onde o LDS está implantado, você poderá derrubar a instalação do openstack, alterar a configuração do nome do servidor do apache e tentar novamente. %código%. Depois de fazer isso, siga o debug-log do juju, certifique-se de que tudo esteja OK e verifique se você pode navegar até a LDS GUI na URL link . / p>

por dpb 06.03.2015 / 00:32