Category: feilsøking

Publisert

Dag 18: Oppretting av virtualbox maskiner uten vagrant

Onsdag 1. oktober var offisiel kickoff for UH-Sky prosjektet som jeg er en del av. Fremover vil det være mye større aktivitet på github i form av endringer enn tidligere. Til nå har arbeidet med «winch» vært preget av mye feilsøking og manuell konfigurasjon. Det vi ønsker å oppnå er å lage et helautomatisk oppsett for å deployere OpenStack i et testmiljø.

For å unngå en del problemer vi har opplevd tidligere har vi besluttet å lage et script som oppretter virtualbox maskiner uten innblanding fra vagrant. Vagrant låser blant annet eth0 interfacet og setter dette til et NAT’et interface. Dette har ført til at maskiner ikke får TFTP bootet når skal provisjonere disse med Foreman. I tillegg har vi fått en del linux bro problematikk og det har krevd mye feilsøking for å få ting til å fungere som de skal. For nå har jeg laget et script som vil opprette de to komponentene compute og controller. Senere vil vi nok også utvide scriptet til å gjelde for storage og network også.

Publisert

Dag 17: Installasjon av compute og controller node ved hjelp av Foreman

Vi fortsatte med feilsøkingen fra fredag om hvorfor puppet modulene fra «winch» ikke ville fungere når vi provisjonerte med Foreman. De hadde virket før og det ga lite mening at de ikke skulle virke nå som Foreman var med i bildet.

Det viste seg at feilen lå spredt i flere konfigurasjonsfiler, og dette gjorde at puppet modulene feilet på maskinene som Foreman installerte. Nå har det blitt gjort endringer i kickstart filene til Foreman for å gjøre at dette problemet ikke vil oppstå igjen. Nå var det mulig å installere både controller og compute noder ved hjelp av Foreman der alle puppet modulene blir installert.

Til nå har vi brukt vagrant og virtualbox for å lage og provisjonere maskiner. Vagrant legger opp et eth0 interface med en NAT adresse, men dette kludrer mye til det nettverksoppsettet vi ønsker. Derfor er neste steg nå å lage install script som kan lage og sette opp virtualbox maskiner for å unngå at eth0 inferfacet blir bundet opp til denne NAT adressen. Mer om dette på fredag.

Publisert

Dag 12: Feilsøking av «winch» installasjon

Fra tidligere har vi ofte hatt problemer med å få instanser til å snakke med verden på utsiden. Dette har ofte krevd mer konfigurasjon og feilsøking enn først antatt. Denne gangen var intet unntak. Det ble mye repetering av OpenStack network in too much detail og sjekking av brannmurregler for å verifisere at alt var i orden.

Etter en god del feilsøking viste det seg til slutt å være at feilen oppstod på grunn av vagrant. Vi bruker vagrant til å lage virtuelle maskiner og denne hadde da stokket om på IP adressene til de forskjellige interfacene maskinene skulle ha. Derfor var det mye som ikke ble riktig og etterpå kunne maskinene komme på nett. Senere i uken ble også «winch» prosjektet oppdatert. Endringer kan sees her.

Publisert

Dag 10: Feilsøking av instansnettverk & installasjon av «winch»

Første del av dagen ble brukt til videre feilsøking av hvorfor instansene våre ikke kunne snakke ut mot verden. Dette ble løst med å spesifisere hvilket interface vi skulle kjøre maskering ifra. Iptables regelen fra OpenStack networking in too much detail ble modifisert til å se slik ut:

iptables -t nat -I POSTROUTING 1 -s 172.24.4.224/28 -o eth0 -j MASQUERADE

Etter en iptables reload kunne instansene våre snakke ut mot verden. Innenfor sine begrensede parametere kunne vi nå si at vi hadde en fullverdig OpenStack installasjon.

Resten av dagen ble benyttet til å se på «winch» prosjektet fra GitHub. Dette er et prosjekt på lik linje med OpenStack fra scratch. Formålet med winch er å lære oss å deployere OpenStack ved hjelp av puppet moduler og The Forman. Kort forklart er Forman en effektiv måte å installere all infrastruktur til OpenStack installasjonen, eksempelvis compute, storage og network. Foreman gir mye spennende funksjonalitet, så anbefaler videre lesning i linken over. Når «winch» ble laget var OpenStack kommet til havana versjonen. I disse dager bruker vi icehouse, som er samme versjon som ble installert ved hjelp av packstack. For å kunne jobbe videre med «winch» er vi først nødt til å oppdatere denne til å støtte icehouse. Dette vil være klart til neste gang.

 

Publisert

Dag 8: Videre feilsøking av neutron-server

På denne dagen gikk mye av tiden med til å feilsøke hvorfor neutron-server ikke ville starte på compute noden. Feilsøking uten å ha noe logg å lese kan ofte være vanskelig, og da kommer det helt an på hvilke svar man kan finne på nettet i lignende installasjoner. Til slutt viste det seg at en av de tilleggene som neutron bruker ikke fantes på den stien den skulle ha vært, og tillegget var heller ikke installert.

yum install openstack-neutron-ml2

I tillegg skal det være en plugin.ini fil under /etc/neutron/ som skal holde rede på hvilke tillegg man har lagt til installasjonen av OpenStack. Denne må symlinkes hertil.

ln -s /etc/neutron/plugins/ml2/ml2_conf.ini /etc/neutron/plugin.ini

Etter dette fungerte det å starte neutron-server tjenesten. Foruten om dette har det vært noen stabilitetsproblemer på controller noden. Denne har til nå kjørt på en virtuell maskin og har flere ganger fått økt minnetildeling. I skrivende stund kjører den på 4GB RAM, halvparten av det jeg har på min arbeidsstasjon. Jeg har opptil flere ganger hatt stabilitetsproblemer ved å kjøre denne maskinen virtuelt. En del ganger har jeg blitt nødt til å kjøre power down eller reset for å få kontakt med maskinen. På grunn av dette er planen til neste gang å få lagt controller noden over på en fysisk maskin. Samtidig skal vi også installere ML2 tillegget før vi kjører packstack, slik at vi ikke får de samme problemene med neutron-server som tidligere.