oVirt 3.6 e le proposte per oVirt 4 al meetup di Milano

Giovedì 19 novembre ha avuto luogo il primo meetup italiano di oVirt. Subito dopo l'arrivo dei partecipanti, Sandro Bonazzola (Integration team lead di oVirt e RHEV) ha fatto gli onori di casa con una presentazione della community di oVirt; una community che funziona molto bene, come dimostrano le statistiche sul numero di utenti attivi di users@ovirt.org, il tempo medio di riposta alle richieste e il numero di messaggi che ricevono attenzione. Per approfondire i dettagli della presentazione vi invito a scaricare il documento (reperibile qui).

Dopo l'introduzione, alla quale ha partecipato in videoconferenza anche Mikey Ariel (Community lead di oVirt), è stata la volta dei festeggiamenti per la tanto attesa nuova release 3.6. Gli sviluppatori ci hanno raccontato gli sforzi profusi e le difficoltà incontrate durante il percorso. Dunque è stata la volta di torta e spumante.

La seconda parte del meetup è stata interamente dedicata alle proposte della community per la futura nuova major release, oVirt 4.0. Ne sono scaturiti desideri, riflessioni ed esigenze concrete provenienti dal mondo enterprise che, si sa, è il vero feedback di valore per gli sviluppatori. Possiamo qui riassumere alcune delle proposte avanzate per il prossimo futuro rilascio:

• [container] convergenza tra oVirt Node e Atomic Host: anziché sviluppare autonomamente un sistema operativo minimale, partire dal progetto Atomic e creare una variante con gluster, qemu, libvirt, vdsm e tutto quello che serve ad oVirt Node. In questo modo si diminuirebbe sensibilmente il carico di lavoro e si potrebbero sfruttare tutte le potenzialità di Atomic legate ai container (vedi punto successivo).
• [container] creazione e gestione dei container: dal momento che libvirt già supporta i container LXC, aggiungere un nuovo cluster type in modo da poter sfruttare l'integrazione con Docker/Kubernetes già presente in Atomic. Inizialmente sarebbe sufficiente poter creare i container per poi, in futuro, lavorare sulla migrazione dei processi tra un host e l'altro.
• [container] modalità VDSM_remote: così come avviene nel mondo HA cluster, aggiungere la possibilità di affiliare VM guest come nodi VDSM per i container, escludendo sostanzialmente il power management e tutto quello che riguarda il bare metal;
• [gluster] oVirt Node come storage appliance (Samba/CTDB/Ganesha): aggiungere all'oVirt Node funzioni avanzate di storage e inserire nell'Engine la configurazione automatica dei nodi in questo senso. GlusterFS già supporta Samba (liscio o clusterizzato con CTDB) ed NFS Ganesha; rimarrebbe quindi da integrare un provisioning della configurazione come avviene nelle più diffuse soluzioni NAS commerciali (funzionalità NetApp killer, come dice qualcuno).
• [network] supporto diretto ad Open vSwitch: ad oggi l'unico modo per dialogare con Open vSwitch è attraverso il provider esterno di Neutron. Sarebbe molto meglio avere OVS installato sui nodi e gestirlo direttamente attraverso la gestione delle network dell'engine; questo abiliterebbe gli utenti alla creazione di particolari topologie di rete ad oggi ottenibili in oVirt solo attraverso macchinose (e a volte pericolose) combinazioni di VLAN e vNIC secondarie sulle VM.

Questo è solo un estratto del lavoro svolto al meetup; vi invito a leggere la lista completa delle proposte, minuziosamente catalogate da Giuseppe Ragusa sulla mailing list, ordinate per oVirt Node, oVirt Engine e VDSM.

Un saluto da parte mia. Non dimenticatevi di iscrivervi alla nostra community italiana!