• No se han encontrado resultados

CAPÍTULO 1. CLÚSTER Y HERRAMIENTAS PARA LA GESTIÓN DE PAQUETES

1.3 Gestores de paquetes modernos

1.3.3 Gestor de paquetes SWTools

SWTools también es una "infraestructura para el manejo de software" que fue desarrollado por el Centro Nacional de Ciencias de la Computación (NCCS) y Oak Ridge National Lab (ORNL).

Estructura de directorio

En el diseño de la estructura de directorios para el sistema de gestión de software SWTools, presenta una estructura jerárquica que consiste en tener instalaciones de documentación y software individuales para cada máquina. En la raíz del sistema, se crea una única carpeta para cada la máquina. Un compromiso es hecho en relación con el tema de las carpetas para las máquinas que son casi idénticas en cuanto al uso y el hardware, los principales ejemplos de esto son los sistemas Cray XT4. En el momento de desarrollo de la herramienta NCCS tiene consta de varios sistemas Cray XT4, y debido a esto se elige crear un directorio único para todo el software y la documentación XT4 (este directorio se encuentra en lo que se llamaría nivel de máquina). Esto es, en un intento de encontrar la solución que equilibre la duplicación del trabajo y el riesgo de incompatibilidad entre todas las máquinas. Por lo tanto, todos los sistemas XT4 comparten ejecutables y software. La mayoría de las otras máquinas dentro del NCCS no comparten ningún software y usan únicamente los softwares que son compilados específicamente para ese sistema.

Dentro de cada directorio de máquina, hay una carpeta para cada aplicación que se instala en la máquina. Además, se tiene un directorio llamado modulefiles que también reside en este nivel. Este directorio se utiliza para almacenar módulos (para usar con la aplicación GNU Modules [31]) por cada elemento de software instalado. En este nivel de la estructura de directorios se usa solamente nombres genéricos, sin especificar versión. Por ejemplo, carpetas para python y szip, y no python2.5.1 o szip2.0.

Dentro de cada carpeta de la aplicación (nivel de aplicación), hay una carpeta para cada versión de ese software. Cada carpeta de la versión se nombra utilizando el número de versión. En el caso de las aplicaciones versionadas de manera compleja (por ejemplo

GAMESS que utiliza una combinación de fechas y números de versión), una versión de nomenclatura estándar en función de la aplicación es adoptada y utilizada a partir de entonces. Una carpeta para cada compilación del software se crea dentro del directorio de versión. Estos directorios de compilación se denominan utilizando el formato de nombre

os_compiler[_options]. Por ejemplo, una compilación en Jaguar podría llamarse

sles9.2_pgi7.0.7_i8, la primera abreviatura es para el sistema operativo, en este caso Suse Linux Enterprise Server 9.2. El segundo es la abreviatura para el compilador, que en este caso es el grupo Group Incorporated Portland de compiladores. La última abreviatura en este caso es i8, lo que significa que esta compilación se ha compilado con soporte de entero de ocho bytes.

Archivos usados por SWTools

Dentro de cada nivel del sistema de gestión de software hay varios archivos que son utilizados por el sistema para almacenar información y automatizar tareas. En primer nivel en el que existen estos archivos es el nivel de aplicación. Cada carpeta de la aplicación contiene una carpeta para cada versión de la aplicación instalada en la máquina. Además, hay cuatro archivos utilizados por la herramienta de software. El primer archivo, check4newver

almacena una fecha. La fecha en el archivo es la fecha en que SWTools deben comprobar si hay una nueva versión del software. Por defecto, el sistema utiliza un lapso de tiempo de 90 días entre las comprobaciones de versión. Sin embargo, esto se puede modificar para cualquier período de tiempo que el instalador encuentre apropiado. El script swversion se ejecuta si es el momento de comprobar si hay una nueva versión.

Otro archivo es description. Este archivo es una descripción HTML de la aplicación y su uso. Utiliza etiquetas básicas estándar HTML, como <h1>, <h2>, <p> y <pre>. No se incorporan estilos en el archivo más allá de este nivel básico. La idea detrás de este archivo es que el instalador de la aplicación será muy probablemente la persona más calificada para escribir la documentación sobre la aplicación. El instalador es probablemente el más familiarizado con el paquete, y está sin duda familiarizado con cualquier idiosincrasia particular de las compilaciones en el sistema. Por lo tanto, es de esperar que habrá una sola fuente de documentación tanto la documentación del sistema local y también la documentación proporcionada en la web externa.

El tercer archivo es el archivo support que se encuentra en cada directorio de la aplicación. Este archivo es utilizado por SWTools para documentar el nivel de soporte que el NCCS proporcionará a los usuarios finales para esta aplicación. Hay cuatro palabras clave válidas que pueden usarse en este archivo: nccs, vendor, nccs+vendor o unsupported. La palabra clave nccs implica que esta aplicación fue instalada por el NCCS y que es una aplicación con soporte. La palabra clave vendor implica que la aplicación se proporciona con el sistema y que el proveedor del sistema proporcionará soporte. nccs+vendor significa que tanto una versión proporcionada por el proveedor y proporcionada por el NCCS está instalada en el sistema. Por último, la palabra clave unsupported implica que el NCCS no proporcionará soporte para esta aplicación, esta se utiliza para paquetes no esenciales que a menudo están instalados.

El cuarto archivo en el directorio de la aplicación es el archivo versions. El archivo de versiones como su nombre también indica es utilizado por SWTools para determinar la versión actual, en desarrollo y en desuso. En el nivel de versión no hay archivos especiales usados por SWTools, es simplemente una carpeta para cada compilación presente dentro de la carpeta versión.

En el nivel de compilación hay siete archivos separados que son utilizados por SWTools. Los tres primeros archivos rebuild, relink y retest, todos sirven a un propósito similar, son scripts escritos por el instalador de la aplicación para realizar la acción que indica el nombre de cada uno. Por ejemplo, un script de re-compilación (rebuild) debe limpiar por completo cualquier instalación existente y luego compilar la aplicación de nuevo.

El siguiente archivo que se encuentra en el nivel de compilación es el archivo .owners, que es utilizado por el sistema para documentar que miembro del personal es actualmente responsable del mantenimiento de ese paquete. Este archivo se crea automáticamente cuando se instala la aplicación, con el nombre de usuario del instalador de valor inicial.

El quinto de archivo utilizado por SWTools en el nivel de compilación es el archivo status. Esta es una pieza vital del sistema; que permite al personal NCCS saber si una aplicación está lista para ser usada y completamente operativa. El archivo de estado es creado por el script reset.

El sexto archivo es build-notes y es utilizado por SWTools en el nivel de compilación. build- notes no es un archivo obligatorio; es un lugar para los instaladores documentar pasos especiales que tengan que hacer al compilar esta aplicación.

Por último, el archivo dependencies es utilizado por SWTools para documentar todas las dependencias que son necesarias para que la aplicación pueda ser compilada. Esta información se almacena para uso de referencia.

La herramienta SWTools consta de varios scripts que hacen posible la realización de las tareas pertinentes a la gestión de paquetes, así como el trabajo en la estructura de directorios expuesta anteriormente.

swaddpackage y swaddbuild: son los scripts que facilitan el proceso de instalación de una nueva aplicación.

swbuild, swlink, y swtest: desempeñan funciones similares. Cada uno de estos scripts ejecuta el apropiado script de compilación, swbuild ejecuta rebuild, swlink ejecuta

relink. Ellos soportan un número de características avanzadas que hacen posible hacer operaciones significativas de manera fácil.

swversion es una herramienta que es usada por el personal NCCS para proactivamente actualizar tantas aplicaciones como sea posible, usa el archivo .check4newver.

swduplicate: es el script designado para automatizar el proceso de realizar las actualizaciones.

swreport: todas las características de reporte de SWTools están encapsuladas dentro de swreport.

El gestor de software SWTools de NCCS ha sido una gran desafío a pesar de estar estructurado únicamente para los requerimientos presentes en el NCCS, aun así este puede servir de información para ser usado en otros centros u organizaciones con requerimientos similares [32, 33].