Cross-Project Flakiness: A Case Study of the OpenStack Ecosystem

Immagina di far parte di una gigantesca squadra di costruzione globale che sta edificando una città cloud enorme e complessa chiamata OpenStack. Questa città non è costruita da una sola persona; è costruita da migliaia di operai (sviluppatori) che lavorano su centinaia di diversi quartieri (progetti) come Cinder, Glance e Nova. Per assicurarsi che la città non crolli, ogni volta che qualcuno aggiunge un nuovo mattone o modifica un tubo, eseguono una serie di "controlli di sicurezza" automatizzati (test).

Idealmente, questi controlli di sicurezza dovrebbero essere come un semaforo perfetto: Verde significa "Procedi, la modifica è sicura", e Rosso significa "Ferma, c'è un problema".

Ma a volte il semaforo sfarfalla. Si accende di Rosso senza un buon motivo, poi diventa Verde quando lo ricontrolli, e di nuovo Rosso. Nel mondo del software, questo fenomeno è chiamato "Instabilità" (Flakiness). È come un test che è semplicemente "malinconico" — non sa se sta passando o fallendo, anche se nulla è cambiato nel codice.

Questo articolo è una storia da detective su come questo comportamento "malinconico" si diffonda attraverso l'intera città di OpenStack, non solo in un singolo quartiere.

I Due Grandi Problemi Scovati

I ricercatori hanno scoperto due modi specifici in cui questo comportamento "malinconico" causa problemi:

1. Il Glitch "Contagioso" (Instabilità Trans-Project)
Immagina un controllo di sicurezza specifico (un test) che dovrebbe verificare se una serratura funziona. In questa città, quella stessa verifica della serratura viene utilizzata nel quartiere Cinder, nel quartiere Glance e nel quartiere Nova.

• Il Problema: La verifica della serratura è "malinconica". Fallisce casualmente in tutti e tre i quartieri.
• L'Impatto: Poiché i quartieri condividono questo singolo test, un singolo test difettoso blocca i progressi in più luoghi contemporaneamente. I ricercatori hanno scoperto che il 55% di tutti i quartieri in OpenStack è colpito da questi glitch contagiosi. È come una singola mela marcia che fa marcire l'intera botte, ma la mela è in realtà un test che tutti stanno utilizzando.

2. Il Glitch "Selettivo" (Instabilità Incoerente)
Ora, immagina che quella stessa verifica della serratura venga utilizzata nel quartiere Cinder e nel quartiere Nova.

• Il Problema: In Cinder, il test è perfettamente affidabile (sempre Verde). Ma in Nova, lo stesso identico test è "malinconico" (sfarfalla tra Rosso e Verde).
• L'Impatto: Questo è confuso! Significa che il test in sé non è rotto; qualcosa nell'ambiente di Nova sta causando il problema. È come un'auto che parte perfettamente nel tuo vialetto ma tossisce ogni volta che provi ad avvviarla a casa di un amico. I ricercatori hanno trovato oltre 1.100 di questi glitch "selettivi".

La Grande Sorpresa: Anche i Test "Unitari" Si Ammalano

Di solito, gli sviluppatori considerano i Test Unitari come i "microscopi" del mondo del software. Osservano piccoli pezzi isolati di codice (come una singola funzione) nel vuoto. Dovrebbero essere i test più stabili e prevedibili perché non parlano con il mondo esterno.

La Scoperta Scioccante dell'Articolo:
I ricercatori hanno scoperto che il 70% di questi test "al microscopio" è effettivamente coinvolto nei glitch "Contagiosi".

• Analogia: È come scoprire che le piccole viti isolate che tengono insieme il tuo tostapane sono le stesse viti che causano un cortocircuito nell'intero impianto elettrico della cucina. Avevamo assunto che questi piccoli test fossero sicuri e isolati, ma in un enorme ecosistema, sono profondamente connessi e possono diffondere instabilità ovunque.

Perché Succede Questo? (Le Cause)

Il team ha scavato nei log per scoprire perché i test si comportavano male in alcuni luoghi ma non in altri. Hanno individuato tre principali colpevoli:

1. La "Condizione di Gara" (Il Killer dell'89%): Questa è la causa più comune. Immagina due operai che cercano di afferrare lo stesso strumento nello stesso esatto millisecondo. A volte l'Operaio A lo prende; a volte l'Operaio B lo prende. Se il test cerca di acquisire una risorsa (come un server o un file) che è già utilizzata da qualcos'altro, fallisce. Se riesce a prenderla, passa. Questa casualità è chiamata "condizione di gara".
2. Configurazioni Non Corrispondenti: È come cercare di fare una torta usando una ricetta di un paese ma ingredienti di un altro. Il test si aspetta una configurazione specifica (come una versione specifica di una libreria o una velocità specifica del server), ma l'ambiente non corrisponde.
3. Problemi di Dipendenza: Un quartiere potrebbe aver aggiornato la sua "rete elettrica" (una libreria software), mentre la città vicina no. Il test funziona nella città aggiornata ma fallisce in quella vecchia.

Il Costo dell'Approccio "Aspetta e Vedi"

Quando un test fallisce, la reazione standard in OpenStack è dire: "Oh, deve essere un glitch. Riproviamo semplicemente (recheck) e aspettiamo".

• Il Costo: I ricercatori hanno calcolato che questa abitudine di "ripetere e aspettare" ha sprecato 1.156 giorni di tempo di calcolo e denaro.
• L'Analogia: È come un vigile urbano che vede un semaforo rosso, presume che il sensore sia rotto, e fa passare le auto, poi ricontrolla, poi fa passare le auto di nuovo. Questo spreca carburante (risorse di calcolo) e ritarda il viaggio di tutti (revisioni del codice).

Cosa Dicono gli Operai? (Feedback degli Sviluppatori)

I ricercatori hanno chiesto agli stessi costruttori (sviluppatori) a riguardo.

• La Frustrazione: Molti sviluppatori si sentono impotenti. Dicono: "Sono nuovo, non so a chi chiedere, quindi continuo a premere 'recheck' finché non passa".
• La Realtà: Ammettono che risolvere questi problemi è difficile perché richiede di parlare con più team. Se un test fallisce in Nova a causa di un problema in Cinder, lo sviluppatore di Nova deve aspettare che il team di Cinder lo risolva.
• Il Vuoto Strumentale: Hanno menzionato che, sebbene esistano strumenti per aiutare, spesso si rompono o vengono abbandonati perché nessuno ha il tempo di mantenerli. Serve un "meccanico" dedicato per il sistema CI, non solo volontari che lo fanno a lato.

La Conclusione

L'articolo conclude che in un enorme ecosistema software connesso, non puoi trattare i test come isole isolate.

• Per gli Sviluppatori: Smetti di limitarti a "ricontrollare" e aspettare. Indaga perché un test è fallito, anche se sembra non correlato al tuo codice.
• Per i Responsabili di Team: È necessario standardizzare come i test vengono eseguiti in tutti i quartieri. Se una città utilizza uno strumento specifico, tutti dovrebbero farlo. È anche necessario centralizzare il tracciamento di questi glitch in modo che tutti sappiano quali "viti" sono allentate.
• Per il Futuro: Abbiamo bisogno di strumenti migliori per dirci automaticamente perché un test è instabile (ad esempio, "È fallito perché il server era giù", non solo "È fallito").

In breve, l'articolo sostiene che per mantenere la città di OpenStack funzionante senza intoppi, dobbiamo smettere di trattare i fallimenti dei test come sfortuna casuale e iniziare a trattarli come un problema di coordinamento sistemico che colpisce l'intera città.