oVirt e CentOS Stream, solo vantaggi!

 

Immagino che tutti voi siate al corrente di quello che sta succedendo a nella community CentOS. Vorrei però dirvi subito che la decisione di anticipare l'EOL di CentOS Linux 8 (CL8) in favore di CentOS Stream 8 (CS8) non avrà alcun impatto su oVirt.

 

Lato hypervisor

1. oVirt Node, che rimane la PRIMA SCELTA come sistema operativo per i vostri nodi hypervisor, dalla 4.4.5 verrà compilato a partire da CentOS Stream 8;
   
   
2. per chi invece ancora sta ancora utilizzando l'EL host, potrà tranquillamente usare CentOS Stream 8. Semplicemente installando il repository di oVirt, tutti le dipendenze andranno a posto.

Seguiamo il mantra "oVirt Node if you can, CentOS Stream if you must".

 

Lato manager

1. se, come consigliato dalla community, avete adottato la soluzione SHE (Self Hosted Engine), il vostro mamanger non è altro che un'appliance contenuta in un OVA e scaricata al momento dell'installazione. Niente di cui preoccuparsi in questo caso.
   
   
2. se state utilizzando un manager esterno, allora CentOS Stream 8 rimane ancora la scelta migliore proprio perché è la distro più testata dagli sviluppatori oVirt.
   

CentOS Stream? Un'opportunità più che un problema

Vi ricordo quello che scrisse Sandro Bonazzola sul blog un anno fa: «...we expect CentOS Stream to be the preferred upstream platform on which oVirt should be run...».

Di questo abbiamo avuto riscontro durante il 2020 quando diversi problemi di dipendenze nei vari SIG (Special Interest Groups) di oVirt sono stati causati proprio dalla lentezza del progetto CentOS Linux nel rilasciare pacchetti già presenti in RHEL; uno su tutti il SIG Virtualization che è alla base di oVirt Node. Il paradosso è proprio questo: oVirt è un progetto community upstream, a rilascio veloce, mentre CentOS Linux è un downstream, con un ritardo di rilascio ormai insostenibile.

Non per nulla, dalla versione 4.4.5, oVirt Node verrà compilato a partire da CentOS Stream 8 (CS8) anziché CentOS Linux 8 (CL8). Una scelta dettata dall'efficienza.

La vera soluzione: passare ad oVirt Node

Da quando esiste, oVirt Node ha sempre avuto un'accoglienza fredda da parte dei suoi utenti. Il motivo va ricercato nell'esigenza, dei sistemisti Linux, di poter mettere le mani sul sistema operativo. Per molti veteran è inaccettabile non avere la possibilità di gestire il nodo hypervisor come una qualsiasi installazione Linux application server, installando pacchetti, modificando le regole del firewall e avviando servizi a piacimento.

Un'esigenza molto spesso ingiustificata dal momento che un hypervisor type-1 come oVirt Node, per sua definizione, è un sistema embedded progettato per assolvere quello specifico scopo.

La stessa storte è toccata al progetto Atomic su OpenShift 3 che di per sè era una tecnologia molto valida. La scarsa adozione da parte degli utenti OpenShift in favore di RHEL ne ha decretato la chiusura. Questo però non sta accadendo con CoreOS, essendo di fatto l'unica scelta (almeno per i nodi master) in OpenShift 4.

Ma quale cliente si sognerebbe, su vSphere, di mettere mano alla versione delle librerie presenti sui nodi ESXi?

Com'è fatto oVirt Node?

oVirt Node è una spin di CentOS Stream con i soli pacchetti necessari alla virtualizzazione tramite oVirt, niente di più, niente di meno. Quindi libvirt, qemu, vdsm, glusterfs e tutto ciò che ci aspettiamo su un nodo hypervisor.

 

I principi che stanno dietro alla sua adozione sono:

• stabilità → è la piattaforma più testata dagli sviluppatori in quanto deterministica a livello di versione dei pacchetti contenuti;
  
  
• facilità d'uso → semplicemente, la manutenzione dei nodi hypervsor è affidata ad oVirt, che ne gestisce la maggior parte del ciclo di vita;
  
  
• facilità di aggiornamento → avete presente un firmware di un ruoter? Monolitico e immutabile? Ecco, oVirt Node ha un approccio simile. Usa squashfs e imgbased per gestire gli aggiornamenti come immagini e, in caso di errore, poter fare rollback.

Per maggiori informazioni architetturali consiglio la lettura della relativa Development Guide.

E se devo installare un pacchetto?

Molto spesso è necessario installare un qualche agent di terze parti per il monitoring o per la gestione dello storage. Su oVirt Node è permessa l'installazione di soli pacchetti rpm purché questa operazione venga effettuata tramite yum.

I pacchetti rpm, infatti, oltre a venir installati, verranno copiati anche nella directory /var/imgbased/persisted-rpms/ e reinstallati nel nuovo layer una volta aggiornato il nodo.

Riassumendo

In definitiva, per quanto l'annuncio del board di CentOS abbia spiazzato tantissime organizzzazioni, possiamo almeno dire che per quanto riguarda oVirt questa modifica non avrà alcun impatto. Per la maggior parte dei deployment oVirt Node è quello di cui avete bisogno.

Veniteci a trovare su Telegram, Facebook e LinkedIn. Vi aspettiamo!