Utilizzo dell'attuale opzione "OpenStack Beta" di Landscape per distribuire OpenStack sul mio setup MAAS. Ottengo il completamento del 98%, con 1 errore su "Configura zone di disponibilità". Le mie impostazioni utilizzavano KVM, Open vSwitch e attualmente utilizzo Ceph per l'archiviazione di oggetti e blocchi. Quando guardo il /var/log/landscape/job-handler-1.log sulla macchina del paesaggio, vedo oltre 100 errori su:

2015-03-05 21:18:38 INFO root RetryingCall per '_get_nova_info' non riuscito, prova 103 volte in più: 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
--- < eccezione rilevata qui> ---
/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

NOTA : il numero di riga in jobs.py è disattivato poiché ho aggiunto alcune istruzioni di stampa per il debug. È l'asserzione nella funzione _get_nova_info () vicino alla linea # 741 (se la memoria serve), e sì, sto usando la versione più recente del paesaggio a partire da oggi dal landscape ppa per fiducia.

Così ho modificato /opt/canonical/landscape/canonical/landscape/model/openstack/jobs.py 's _get_nova_info () la funzione per stampare la lunghezza delle nova_compute_hostnames e mi sono pari a zero . Quindi l'ho inseguito in /opt/canonical/landscape/canonical/landscape/model/openstack/region.py di get_nova_compute_hostnames () e ho scoperto che self.juju_environment.get_computer_ids (). Count () era anche zero . Quindi ho aggiunto una chiamata a self.juju_environment.has_computers () e sono diventato falso . Quindi ho eseguito self.juju_environment.get_juju_home () e ho ottenuto/ var / lib / landscape / juju-homes / 20 . (Sì, questo è il mio ventesimo tentativo per la mia seconda ricostruzione della scatola del paesaggio, ci sono stato per un po '). Così ho gestito lo status di juju usando la casa di juju sopra menzionata e tutto sembrava a posto. Tutte e 5 le macchine e i servizi sono stati avviati, senza stati in sospeso o di errore. (compresi i 4 nodi nova-compute) Qualche idea? Sono un po 'nuovo in Landscape, MAAS, JUJU e Python, quindi il mio debug è un po' lento.

AGGIORNAMENTO 1:

Secondo la richiesta ho i 2 log (anche se la mia casa è ora # 23) juju status e broker.log . Penso di sapere ora qual è il mio problema per lo snippet di broker.log di seguito. (Grazie dpb per avermi indicato) La mia macchina MAAS sta fornendo l'indirizzo DHCP al mio LXC orizzontale, ma il mio LXC orizzontale non è nel DNS controllato da MAAS in quanto non è fornito da MAAS. Pertanto, le macchine fornite non possono connettersi al server orizzontale per nome.

Quindi questo mi porta a una domanda correlata, c'è un buon modo per fare in modo che MAAS aggiorni automaticamente il DNS con macchine che non sono fornite (o sotto il controllo MAAS)? Altrimenti dovrò assegnargli un IP statico al di fuori del mio intervallo DHCP e impostare manualmente il DNS.

2015-03-06 17: 09: 50.665 INFO [MainThread] Il broker è iniziato con config /etc/landscape/client.conf
2015-03-06 17: 09: 52.382 INFO [MainThread] Avvio dello scambio di messaggi urgenti con https: // landscape / sistema di messaggi .
06-03-2015 17: 09: 52.389 ERRORE [PoolThread-twisted.internet.reactor-1] Errore nel contattare il server su https: // landscape / message-system .
Traceback (ultima chiamata più recente):
file "/usr/lib/python2.7/dist-packages/landscape/broker/transport.py", linea 71, in scambio
message_api)
File "/usr/lib/python2.7/ dist-package / landscape / broker / transport.py ", riga 45, in _curl
headers = headers, cainfo = self._pubkey, curl = curl))
File "/usr/lib/python2.7/dist-packages/landscape/lib/fetch.py", linea 109, in fetch
raise PyCurlError (e.args [0], e.args 1 )
PyCurlError: Errore 6: potrebbe host non risolto: panorama
06-03-2015 17: 09: 52.390 INFO [MainThread] Scambio di messaggi non riuscito.
06-03-2015 17: 09: 52.391 INFO [MainThread] Scambio di messaggi completato in 0.01s.

AGGIORNAMENTO 2:

La mia configurazione è un po 'limitata in quanto mi sono state assegnate solo 6 macchine (5 nodi e 1 controller) per mostrare le capacità di OpenStack / Landscape, quindi non posso usare una macchina dedicata per il paesaggio. Stavo usando il landscape-server-quickstart in un LXC sul mio controller MAAS in modo da poterlo spazzare via rapidamente e ricominciare da capo.

così ho spazzato via la configurazione orizzontale e impostato LXC su un IP statico, quindi ho modificato il DNS (controllato da MAAS) per avere la voce DNS statica per il mio server orizzontale. Quindi ho installato Landscape Dedicated Server su LXC usando il metodo di avvio rapido landscape-server di cui sopra.

Dopo questa reinstallazione (principalmente per ripulire tutto il mio pasticcio di debug) sono stato finalmente in grado di installare OpenStack attraverso il panorama. Grazie.

Il messaggio "Missing N nova-compute units" riguarda gli agenti client-paesaggio registrati di nuovo in orizzontale, controllare /var/log/landscape/broker.logle unità mancanti.

AGGIORNARE:

Come hai correttamente identificato, le cose funzionano senza intoppi se LDS (Landscape Dedicated Server) è installato sullo stesso MAAS in cui vivrà il tuo openstack, principalmente a causa del routing di rete e del DNS. Tuttavia, esistono innumerevoli varianti di una topologia valida con percorsi tra reti, ecc.

Alcuni suggerimenti su cosa provare, per favore leggili tutti. Alla fine dovrai determinare la tua topologia di distribuzione:

• Per un test, distribuisci LDS nello stesso MAAS in cui si troverà il tuo openstack - solo per verificare se le cose stanno funzionando lì. Usa lo strumento openstack-install o il bundle landscape-denso-maas con juju-quickstart direttamente per facilitare questo.

• I tuoi clienti devono essere in grado di raggiungere LDS, come hai affermato. Se riescono a instradare tramite IP fino a dove viene distribuito LDS, è possibile abbattere l'installazione di openstack, modificare le impostazioni del nome server apache e riprovare. juju set apache2 servername=IP_ADDRESS. Dopo aver fatto ciò, segui il debug-log di juju, assicurati che tutto vada bene e assicurati di poter accedere alla GUI LDS in quel https: // IP_ADDRESS / URL.