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

Imagina que eres parte de un equipo de construcción masivo y global que está construyendo una ciudad en la nube gigante y compleja llamada OpenStack. Esta ciudad no es construida por una sola persona; es construida por miles de trabajadores (desarrolladores) que trabajan en cientos de barrios diferentes (proyectos) como Cinder, Glance y Nova. Para asegurarse de que la ciudad no colapse, cada vez que alguien añade un nuevo ladrillo o cambia una tubería, ejecutan una serie de "comprobaciones de seguridad" automatizadas (pruebas).

Idealmente, estas comprobaciones de seguridad deberían ser como un semáforo perfecto: Verde significa "Adelante, el cambio es seguro", y Rojo significa "Alto, hay un problema".

Pero a veces, el semáforo parpadea. Se pone Rojo sin ninguna razón válida, luego Verde cuando lo vuelves a comprobar, y luego Rojo de nuevo. En el mundo del software, esto se llama "Inestabilidad" (Flakiness). Es como una prueba que está simplemente "de mal humor": no sabe si está aprobando o fallando, incluso aunque nada haya cambiado en el código.

Este artículo es una historia de detectives sobre cómo este comportamiento "de mal humor" se extiende por toda la ciudad de OpenStack, no solo en un barrio.

Los Dos Grandes Problemas que Encontraron

Los investigadores descubrieron dos formas específicas en las que este comportamiento "de mal humor" causa problemas:

1. El Error "Contagioso" (Inestabilidad Transversal entre Proyectos)
Imagina una comprobación de seguridad específica (una prueba) que debería verificar si funciona un cerrojo de puerta. En esta ciudad, ese mismo chequeo de cerrojo se utiliza en el barrio de Cinder, en el barrio de Glance y en el barrio de Nova.

• El Problema: El chequeo de cerrojo está "de mal humor". Falla aleatoriamente en los tres barrios.
• El Impacto: Como los barrios comparten esta única prueba, un solo fallo caprichoso detiene el progreso en múltiples lugares a la vez. Los investigadores descubrieron que el 55% de todos los barrios en OpenStack se ven afectados por estos errores contagiosos. Es como una sola manzana podrida pudriendo todo el barril, pero la manzana es en realidad una prueba que todos están utilizando.

2. El Error "Selectivo" (Inestabilidad Inconsistente)
Ahora, imagina que ese mismo chequeo de cerrojo se utiliza en el barrio de Cinder y en el barrio de Nova.

• El Problema: En Cinder, la prueba es perfectamente fiable (siempre Verde). Pero en Nova, la misma prueba exacta está "de mal humor" (parpadeando entre Rojo y Verde).
• El Impacto: ¡Esto es confuso! Significa que la prueba en sí no está rota; algo sobre el entorno en Nova está causando el problema. Es como un coche que arranca perfectamente en tu entrada de casa pero trota cada vez que intentas arrancarlo en la casa de un amigo. Los investigadores encontraron más de 1.100 de estos errores "selectivos".

La Gran Sorpresa: Incluso las Pruebas "Unitarias" se Están Enfermando

Por lo general, los desarrolladores piensan en las Pruebas Unitarias como los "microscopios" del mundo del software. Observan piezas diminutas y aisladas de código (como una sola función) en un vacío. Se supone que son las pruebas más estables y predecibles porque no se comunican con el mundo exterior.

El Hallazgo Impactante del Artículo:
Los investigadores descubrieron que el 70% de estas pruebas de "microscopio" están realmente involucradas en los errores "Contagiosos".

• Analogía: Es como descubrir que los tornillos diminutos y aislados que sostienen tu tostadora son los mismos tornillos que están causando un cortocircuito en todo el sistema eléctrico de la cocina. Asumimos que estas pruebas pequeñas eran seguras y aisladas, pero en un ecosistema gigante, están profundamente conectadas y pueden propagar la inestabilidad a todas partes.

¿Por Qué Sucede Esto? (Las Causas)

El equipo revisó los registros para descubrir por qué las pruebas actuaban mal en algunos lugares pero no en otros. Encontraron tres culpables principales:

1. La "Condición de Carrera" (El Asesino del 89%): Esta es la causa más común. Imagina a dos trabajadores intentando agarrar la misma herramienta en el mismo milisegundo exacto. A veces el Trabajador A la consigue; a veces el Trabajador B la consigue. Si la prueba intenta agarrar un recurso (como un servidor o un archivo) que ya está siendo utilizado por otra cosa, falla. Si lo consigue, pasa. Esta aleatoriedad se llama "condición de carrera".
2. Configuraciones Desajustadas: Es como intentar hornear un pastel usando una receta de un país pero ingredientes de otro. La prueba espera una configuración específica (como una versión específica de una biblioteca o una velocidad de servidor específica), pero el entorno no coincide.
3. Problemas de Dependencias: Un barrio podría haber actualizado su "red eléctrica" (una biblioteca de software), mientras que la ciudad vecina no lo ha hecho. La prueba funciona en la ciudad actualizada pero falla en la antigua.

El Costo del Enfoque "Esperar y Ver"

Cuando una prueba falla, la reacción estándar en OpenStack es decir: "Oh, debe ser un error. Vamos a ejecutarla de nuevo (recheck) y esperar".

• El Costo: Los investigadores calcularon que este hábito de "recheck y esperar" ha desperdiciado 1.156 días de tiempo de computación y dinero.
• La Analogía: Es como un agente de tráfico que ve una luz roja, asume que el sensor está roto, y hace pasar a los coches, luego comprueba de nuevo, y luego hace pasar a los coches de nuevo. Esto desperdicia combustible (recursos de computación) y retrasa el viaje de todos (revisiones de código).

¿Qué Dicen los Trabajadores? (Feedback de los Desarrolladores)

Los investigadores preguntaron a los constructores reales (desarrolladores) sobre esto.

• La Frustración: Muchos desarrolladores se sienten impotentes. Dicen: "Soy nuevo, no sé a quién preguntar, así que sigo pulsando 'recheck' hasta que pasa".
• La Realidad: Admiten que solucionar estos problemas es difícil porque requiere hablar con múltiples equipos. Si una prueba falla en Nova debido a un problema en Cinder, el desarrollador de Nova tiene que esperar a que el equipo de Cinder lo solucione.
• La Brecha de Herramientas: Mencionaron que, aunque existen herramientas para ayudar, a menudo se rompen o se abandonan porque nadie tiene tiempo para mantenerlas. Necesitan un "mecánico" dedicado para el sistema de CI, no solo voluntarios haciéndolo al margen.

La Conclusión

El artículo concluye que en un ecosistema de software gigante y conectado, no se pueden tratar las pruebas como islas aisladas.

• Para los Desarrolladores: Dejen de simplemente "recheckear" y esperar. Investiguen por qué falló una prueba, incluso si parece no tener relación con su código.
• Para los Líderes de Equipo: Necesitan estandarizar cómo se ejecutan las pruebas en todos los barrios. Si una ciudad usa una herramienta específica, todos deberían usarla. También necesitan centralizar el seguimiento de estos errores para que todos sepan qué "tornillos" están sueltos.
• Para el Futuro: Necesitamos mejores herramientas para decirnos automáticamente por qué una prueba es inestable (por ejemplo: "Falló porque el servidor estaba caído", no solo "Falló").

En resumen, el artículo argumenta que para mantener la ciudad de OpenStack funcionando sin problemas, debemos dejar de tratar los fallos de las pruebas como mala suerte aleatoria y empezar a tratarlos como un problema sistémico de coordinación que afecta a toda la ciudad.