Antes de describir las principales características que definen el algoritmo creado para que el demonio del nodo máster cumpla su tarea, es necesario entender los diferentes cambios de estado
que los paquetes fuentes experimentan durante el proceso de construcción. Estas transiciones de un estado a otro son guiadas por varias condiciones:
La figura 4 muestra un diagrama de máquina de estados que representa los cambios de estado que atraviesan los paquetes durante el proceso de construcción. Las reglas que se siguen para cambiar de estado se muestran en la figura como números encima de cada arco que representa una transición, y se explican como sigue:
0. Regla general para todas las etapas: Regla activada por disparadores en la base de datos (no está programada en el algoritmo principal que rige el proceso). Cada vez que algún paquete cambia su estado de construcción, un disparador es activado, que comprueba si el nuevo estado de construcción es Hecho. Si el paquete que activó el disparador ha cambiado al estado de construcción Hecho y su estado de configuración es Transicional, sus dependencias de construcción se comprueban para determinar si todas ellas están satisfechas (durante el estado En Construcción, algunas dependencias pueden haberse hecho disponibles, ver epígrafe 2.5.9 Problemas de concurrencia detectados para más detalles) y si este es el caso , se cambia el estado a Listo, por lo que puede ser seleccionado para la construcción en la próxima ronda de las asignaciones a los nodos
Fig 4. Diagrama de máquina de estados que representa las transiciones entre los estados de construcción.
esclavos, con el objetivo de generar un paquete nativo final. Si el estado de configuración del paquete quedó como Transicional o Nativo, a continuación cada paquete dependiente de este paquete se comprueba para determinar si la totalidad de sus dependencias de construcción están satisfechas, que el paquete dependiente no esté en el estado En Construcción y que su estado de configuración no sea Nativo. Si estos requisitos se cumplen, el paquete dependiente cambia su estado de construcción a Listo.
1. El cambio del estado Necesita Construcción a Listo varía según las distintas etapas:
• Etapa 1: El paquete es un paquete esencial, necesario para crear una imagen de base. La lista de tales paquetes se mantiene en la base de datos del sistema.
• Etapa 2: El paquete ha sido seleccionado en orden de acuerdo a su nivel de demanda como una dependencia de construcción (Ver epígrafe 2.5.3 Estrategia de selección de paquetes para su asignación a los nodos de compilación).
• Etapa 3: El paquete cambia automáticamente a Listo. En esta etapa, es responsabilidad del administrador del sistema asegurar que todas las dependencias de construcción se cumplan, de lo contrario la construcción fallará.
• Todas las etapas: la regla general 0 se aplica aquí.
2. El cambio del estado Listo a En Construcción varía según las distintas etapas:
• Etapa 1 y 2: El paquete ha sido entregado a un nodo esclavo para su construcción. Si todas las dependencias estaban satisfechas con paquetes binarios (en estado de configuración
Transicional o Nativo), y dependiendo si el estado de configuración del paquete es Faltante
o Transicional, se cambia el estado de configuración del paquete que se está construyendo a
Hacia Nativo Desde Faltante o Hacia Nativo Desde Transicional. En caso de dependencias faltantes se cambia el estado de configuración del paquete a Hacia Transicional.
• Etapa 3: Al no existir, por estar prohibidos, los paquetes externos o transicionales, el único cambio de estado de configuración posible es Hacia Nativo Desde Faltante.
3. El cambio del estado Necesita Construcción a Falló solo ocurre en la Etapa 3: Ocurre cuando se trata de construir un paquete cuyas dependencias no están satisfechas por el repositorio. Todas las dependencias deben estar en estado de configuración Nativo.
4. El cambio del estado En Construcción a Falló funciona igual en todas las etapas: el nodo esclavo reporta que fracasó la construcción del paquete. El estado de configuración del paquete retorna a su estado previo.
• Etapa 1: No ocurre. Es responsabilidad del administrador del sistema solucionar el problema mediante la subida de nuevas versiones o la adición de otros repositorios externos, pero esto cambia el estado del paquete a Necesita Construcción, no a Listo.
• Etapa 2: El algoritmo reintentará la construcción de los paquetes fallidos cuando ya no queden más paquetes con los estados Necesita Construcción o Listo. Para lograr esto, se cambiará el estado de todos los paquetes fallidos a Listo. Hay un contador por cada paquete en la base de datos que se incrementa cuando se produce esta acción específica, que sería revisado en la siguiente ronda y tiene un valor máximo permitido, evitando así un ciclo infinito.
• Etapa 3: Igual que la etapa 1.
• Todas las etapas: la regla general 0 se aplica aquí.
6. El cambio del estado Falló a Necesita Construcción funciona igual en todas las etapas: el administrador del sistema cambia manualmente el estado del paquete a Necesita Construcción a través de la interfaz de usuario o mediante la subida de una nueva revisión del paquete, después de arreglar el problema que causó que el proceso de construcción fallara.
7. El cambio del estado En Construcción a Hecho varía según las distintas etapas: la condición común es que el nodo esclavo reporta que concluyó con éxito la construcción del paquete, pero los cambios en el estado de configuración dependen de como esté configurado el repositorio:
• Etapas 1 y 2: Si el estado de configuración del paquete era Hacia Transicional, se cambia este estado por Transicional; si el estado de configuración del paquete era Hacia Nativo Desde Faltante o Hacia Nativo Desde Transicional, se cambia este estado por Nativo. En el caso del cambio hacia Transicional, puede darse el caso de que el paquete en realidad haya cambiado a Nativo aunque en la base de datos se marque de otra forma, pero eso no afecta significativamente el estado del repositorio (para más información, consultar epígrafe 2.5.9
Problemas de concurrencia detectados)
• Etapa 3: No existen los paquetes en estado Transicional y los paquetes externos están prohibidos, por lo que el único cambio de estado de configuración posible es de Hacia Nativo Desde Faltante por Nativo.
8. El cambio del estado Hecho a Listo se rige por la regla 0.
Cuando el demonio máster se inicia, busca paquetes con el estado Listo, si no los encuentra, entonces se inicia la aplicación de las reglas anteriormente mencionadas, en primer lugar se buscan los paquetes con el estado de construcción Necesita Construcción para cambiarlos a Listo o si no
hay ninguno de estos y hay paquetes en otros estados de configuración diferentes de Nativo, trata de reconstruir los fallidos (cambiando su estado de construcción a Listo) para desencadenar el reinicio del proceso de construcción y así eliminar los paquetes transicionales y los que han fallado de la base de datos mediante la satisfacción de sus dependencias de construcción. El demonio mantiene una cola de paquetes listos en la memoria para evitar las consultas a la base de datos para cada paquete listo cada vez que un nodo esclavo esté disponible.