Seguimiento Diciembre
Objetivos cumplidos

En la iteración se han logrado dos prototipos. Por una parte, una GUI funcional que permite editar las preferencias (aunque aún no leerlas), además de mostrar una ventana de log en el menú View para comprobar que se monitorizan la creación, borrado y modificación de los archivos o carpetas configurados.

Por otra, se ha diseñado una aplicación que, mediante consola, permite realizar backups, listarlos y recuperarlos. Cuando se realiza un backup de algo que no estaba en las preferencias la aplicación añade dicha carpeta a las mismas.

Durante la integración hemos trabajado sobre los problemas de arquitectura y organización de código que deberemos utilizar, lo que nos resultará útil para futuras integraciones. El brainstorming ha ayudado a definir la arquitectura respecto a nuestras estimaciones iniciales, ayudando a tener en mente algunos casos de uso (como Exportar a disco externo importantes que hemos relegado para fases posteriores del desarrollo. Este caso y su simétrico, importar, cubren la importante funcionalidad de poder recuperarse después de un fallo catastrófico (formateo), o de un cambio de equipo, siempre que se conserven copias de seguridad.

La investigación en esta iteración se ha centrado en:

Python

Todos los equipos de desarrollo han debido familiarizarse con el nuevo entorno y bibliotecas; el nuevo lenguaje de programación no ha traído demasiados problemas. Se han puesto de manifiesto algunas carencias en la documentación interna (tutoriales) que deberán ser solventadas; no era posible detectarlo hasta que se realizaran las primeras integraciones y se probara un poco más el lenguaje.

Rdiff-backup

Por decisión común se decidió en la anterior iteración utilizar la aplicación rdiff-backup como medio de gestión de snapshots. Así, el desarrollo se limitaba al diseño de una API general expuesta al resto de módulos y una serie de wrappers que envolviesen el funcionamiento de la aplicación.

La investigación fue corta pero concluyente y se encuentra reflejada en el apéndice I del informe de investigación sobre snapshot-manager.

El desarrollo fue apresurado y difícil debido en primer lugar a la escasez de tiempo disponible por las circunstancias académicas y personales de los desarrolladores. Aun así, la entrega se efectuó a tiempo y la API cubría algunos de los casos de uso críticos expuestos en el documento correspondiente.

Uno de los principales problemas fue causado por el abandono de uno de los integrantes del equipo HD Lorean asignado precisamente a este módulo. Las consecuencias de la marcha de nuestro compañero resultaron en un aumento de la carga de trabajo del otro componente del equipo que se vio desbordado; un riesgo que no podemos mitigar completamente debido a la falta de personal, pero que en adelante mitigaremos mediante rebalanceos más frecuentes del trabajo. Además el análisis de alcance y el reparto de objetivos era incompleto, ya que no estaban explicitadas las prioridades; queda pendiente para la siguiente iteración.

La investigación a fondo de la aplicación ha puesto de manifiesto varios problemas. Por una parte, rdiff-backup genera deltas inversas, a diferencia de lo que creíamos: ello que cambia buena parte de las presuposiciones que hacíamos sobre el programa (tanto en funcionamiento como en requisitos), y a priori dificultaría el borrado de snapshots concretos, una funcionalidad necesaria entre otras para reducir el uso de disco. Además, por estar orientado a una granularidad mayor que la nuestra no ofrece la posibilidad de actualizar un archivo individual en el backup: el escaneo siempre es sobre los tiempos de modificación de la carpeta completa monitorizada, lo que inutiliza inotify y ralentiza el programa respecto al uso que queremos darle. Por otra parte, en el desarrollo de la arquitectura quedó patente que una base de datos que indexe contenido es necesaria aunque se use rdiff-backup debajo, lo cual limita aún más sus ventajas. Queda pendiente la investigación sobre si es posible y merece la pena solucionar estos problemas, o se debe descartar el uso de rdiff-backup y buscar alternativas o construirlas desde cero.

Cron

Administrador regular de procesos en segundo plano (véase demonio) que ejecuta programas a intervalos regulares (por ejemplo, cada minuto, día, semana o mes). En un primer momento se intentó modificar el crontab del usuario, pero para acceder a él se necesitaban privilegios de superusuario. Un requisito de la aplicación es que ésta se pudiera ejecutar como usuario (por ser el usuario medio el objetivo del desarrollo), y no necesariamente como administrador, lo cual suponía un problema.

Linux nos otorga ciertos comandos para poder acceder al crontab de forma segura, sin requerir estos permisos. Entre ellos existe uno que nos lista el contenido del fichero. La solución adoptada es abrir un pipe asociado a la salida de este comando para obtener su contenido, el cual verteremos en un archivo temporal. Este archivo temporal podemos modificarlo a nuestro antojo (manteniendo siempre la sintaxis de cron). Por último actualizaremos el crontab del usuario con este archivo temporal.

Un problema es que cron supone sistemas que están operativos siempre, y por ello si el sistema no esta activo en el momento de ejecutar la tarea, esta simplemente se pierde. Sin embargo, un pc personal suele apagarse y encenderse con cierta frecuencia, por lo que tenemos que buscar algún otro mecanismo para solventar este problema.

Anacron es un programador de tareas similar a cron, con la diferencia de que no necesita que el sistema esté en ejecución. Se puede utilizar para ejecutar los procesos que cron ejecuta normalmente de forma diaria, semanal y mensual. Lo más recomendable es que se utilicen ambos, cron para intervalos pequeños de tiempo, y anacron para intervalos mayores (a partir de un día). Con Anacron no se ha conseguido solucionar el problema de los permisos, por lo que posiblemente, si no se encuentra la manera, haya que decidir que nos interesa más, si usar anacron y ejecutar la aplicación como root o usar cron y que sólo se hagan las copias de seguridad cuando el equipo esté encendido.

Además se investigó fcron, similar a anacron, pero por el momento queda descartado, ya que instalarlo modifica instalaciones por defecto de Ubuntu.

Inotify

hemos descubierto que los límites por defecto se pueden saltar y definir según nuestras necesidades, lo que mitiga el riesgo de que no sirviera o de que dificultara en exceso el desarrollo. La funcionalidad que ofrece este componente está prácticamente concluida.

Formato de ayuda de YELP (ayuda de GNOME)

esta todo en xml y además resulta incómodo a la hora de editar. Sin embargo se ha localizado un editor (Conglomerate) específico para el formato docbook, todavía en desarrollo.

Objetivos no alcanzados

No ha dado tiempo a estabilizar la arquitectura ni a realizar la API; queda como tarea pendiente para la iteración de enero a fin de poder pasar a construcción cuando se concreten las clases y se realice el UML.

Riesgos reducidos
  • La incompatibilidad de horarios ha sido mitigada al establecer como estándar el martes por la tarde para las reuniones, el día que viene "menos mal" a todo el grupo.
  • El riesgo "no llegar a superar inotify" está cubierto e implementado, así como el riesgo que apareció durante la investigación de no tener suficientes handlers.
  • GTK razonablemente superado; ya hay un GUI, pero aún falta funcionalidad por implementar en el mismo.
  • Riesgo de corrupción de backup queda cubierto *siempre y cuando* se utilice rdiff-backup, que implementa checksums.
  • Launchpad reducido, lo hemos usado todos.
  • No lograr funcionar sin internet está superado, dado que dependemos menos del wiki y el control de versiones es distribuído (en última instancia puede funcionar "punto a punto", sin pasar por los servidores de launchpad).
Nuevos riesgos
  • rdiff-backup no cubre los casos de uso, lo que nos aprieta bastante los tiempos de desarrollo y puede suponer un bloqueo para seguir avanzando con la aplicación (mejores interfaces, etc), así como dificulta su desarrollo respecto de la previsión (que era corta porque, en la primera investigación, creímos erróneamente que nos solucionaba todos los casos de uso sin trabajo adicional).
  • Detectar dispositivos externos puede requerir del subsistema HAL, una nueva tecnología a investigar.
  • La integración en bazaar es delicada; hemos comprobado que es posible romper el repositorio por parte de cualquiera. La solución prevista, a falta de comprobar si podemos restringir escrituras dentro del grupo en el servidor, es una política clara de integración: resumiendo, nadie sube a ninguna parte fuera de su grupo de trabajo, y de integrar se encargan personas determinadas. A tal fin se desarrollarán tutoriales de integración y guidelines de desarrollo específicos en python para facilitar la integración.
  • Los exámenes están próximos, quedan bastantes entregas en las otras asignaturas y el problema de falta de tiempo se incrementa. Además hemos sufrido un abandono, lo que reduce aún más el personal disponible y convierte en más crítico otra hipotética baja de media duración. Mucha gente tendrá disponibilidad reducida o nula en vacaciones; para compensar, esta es la iteración más larga (un mes y una semana), y en vacaciones al no haber jornada lectiva ni laborable hay más tiempo para trabajar.
  • No hay api de nautilus; va implícita en el código, y no hay documentación ninguna. La integración con el mismo se complicará bastante por ello.
  • Cómo exportar nuestro sistema de backups aplanado a sistema de ficheros aún no está claro, pues es un problema no trivial en absoluto; además la documentación de FUSE, el sistema que se usaría para ello, es confusa. Como la funcionalidad que nos proporcionaría es principalmente interna este riesgo tiene un impacto bastante leve.
  • Python es un lenguaje interpretado y puede ser muy ineficiente en comparación con otros módulos. No obstante, la optimización queda pendiente para futuras fases de desarrollo, es posible enlazar python con módulos en C y además presumimos que el cuello de botella no estará marcado por tiempo de cpu sino de entrada / salida.
  • Fat32 impone límites al almacenamiento de archivo que se deben cubrir, sea mediante una aplicación externa o mediante un formato de archivo propio. Al ser el formato más común en discos externos (suelen venir preformateados) es crítico que funcione almacenar sobre fat32 si se quieren externalizar las copias. Algunos de esos riesgos son que no se soportan links (ni hard ni soft), ni permisos, ni archivos de más de 4 GB de tamaño. Los riesgos son compartidos en parte por ntfs.
  • Rdiff impone límites en sus funciones internas para paths muy largos; hay que investigar el alcance de ese riesgo y actuar en consecuencia. Los desarrolladores de rdiff-backup parecen tenerlo solucionado no obstante.
  • Las herramientas de modelado UML no suelen tener soporte para python: es escaso a la hora de realizar ingeniería inversa sobre código, y casi nulo para generarlo. Localizadas herramientas que cubren en teoría ambas funcionalidades, queda comprobar hasta qué punto lo hacen y familiarizarse con ellas.
Tiempo real empleado

En general no ha habido un buen reparto del trabajo, lo cual viene motivado en parte porque la investigación implica desconocimiento del tiempo de desarrollo, pero también porque el reparto no era bueno en origen y ha habido cierta desorganización. Para mitigar este problema, según la sugerencia dada en clase trataremos de hacer planificación semanal, mediante tareas atómicas ordenadas según su nivel de importancia y relevancia para el camino crítico, y revisando más frecuentemente el reparto. No obstante esto será difícil hasta la primera iteración de construcción, pues aún queda investigación por realizar. Asimismo se ha propuesto un método de refuerzo positivo: quien llegue tarde a la fecha de entrega pierde puntos, y quien la logre los obtiene. Esos puntos serían canjeables por fermentaciones líquidas varias en la cafetería, a gusto del consumidor.

Conclusiones

Aunque se han cumplido la mayoría de los objetivos, se puede mejorar bastante el proceso de trabajo. Es necesario mejorar la integración para conseguir interoperabilidad fácilmente entre el código de todos, y conseguir un reparto de trabajo más equitativo. Aunque la integración ha sido difícil era algo previsto por ser la primera; intentaremos resolver los procesos para ello para la próxima iteración. Además, la opinión general sobre Python, el nuevo lenguaje de programación usado en el proyecto, es que para lo que podía ser ha funcionado razonablemente bien, sin grandes dificultades de desarrollo.

Respecto del abandono de un miembro del equipo, solo destacar que al no ser un miembro activo hasta ese punto no ha afectado tanto a las planificaciones de reparto de trabajo. Confiamos en que no tengamos de nuevo ese problema, ya que el equipo de desarrollo está muy motivado.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License