Timetracking system for taiga using slack integration

En zylk.net llevamos unos diez años gestionando los proyectos y los soportes con el bugtracker (mantis). En este último mes estamos probando distintas herramientas más próximas a la gestión de proyectos que a la gestión de issues/tasks etc.. Hemos probado algunas SAAS otras on premise etc... De momento con la que más a gusto nos estamos encontrando es con taiga...

Una de las cosas que no tiene taiga es la posibilidad de imputar horas reales en las notas de las historias de usuario, issues, tasks etc.. Con lo que hace un poco más compleja la gestión de las horas reales imputadas en un proyecto. Por esa razón y dado que estamos usando también el sistema de mensajería slack a nivel interno he desarrollado este fin de semana un modulo (no lo llamaría módulo de taiga ya que en realidad no lo es) para permitir hacer el seguimiento de tiempos de las tareas definidas en un proyecto del taiga.

Para ello contaba con los siguientes ingredientes

  • Pocos o nulos conocimientos de la arquitectura de taiga (Python pip etc..)
  • Un sistema de mensajería basado en slack con un bot que procesa la información de los canales de slack (Proyecto interno que estamos desarrollando en zylk.net que esperamos poder presentar el año que viene). Hay un montón de post relacionados con el tema en el blog de zylk [1][2][3] que aunque parecen inconexos tiene un objetivo común.
  • Modulo de integración entre taiga y slack

Visto el primer ingrediente ... quedaba descartada la mejor opción a nivel técnico que era hacer un módulo de taiga. Así que lo que diseñe fue lo siguiente

  1. Mandar los mensajes de las acciones realizadas en taiga a un canal de slack, usando el módulo de taiga disponible a tal efecto
  2. Parsear esos mensajes y extraer la información de seguimiento de tiempos, una expresión regular ... [".*<https://taiga.zylk.net/project/(.*?)/task/(.*?)\\|#.*?:(.*)>.*\\n+.*Comment by (.*?):(.*@timetracking\\s{1}(\\S*)\\s?.*)"]
  3. Guardar esa información un backend y notificar que se ha realizar la acción. De momento en una base de datos relacional.

Para ello bastó con diseñar la siguiente tabla

 

CREATE TABLE timetracking
(
   project VARCHAR(255),
   taskId VARCHAR(255),
   task VARCHAR(255),
   channel VARCHAR(255),
   timestamp BIGINT,
   message TEXT,
   timetrack DOUBLE,
   user VARCHAR(255)
);

Y usar el BOT que ya tenemos en zylk para que respondiera a la expresión regular. Con este sencillo modelo hemos conseguido que si se añade la siguiente instrucción (@timetracking 1:00) a un comentario de una tarea en taiga se añada esa imputación a la tabla anteriormente descrita ...

El sistema tiene una enorme cantidad de mejoras posibles... pero tiene una virtud, que no tendría un módulo de taiga, y es que nos permite realizar imputación sobre proyectos tanto desde la interfaz de taiga, como desde el propio sistema de mensajería de slack. A continuación mostramos unas imágenes de cómo sería el flujo de una imputación, el flujo sigue la el siguiente esquema

  1. Se crear una nota en una tarea de un proyecto de taiga, que tenga el texto @timetracking 2:00
  2. El mensaje se envía al canal de slack del proyecto en cuestión
  3. El BOT que tenemos desarrollado en zylk, interpreta ese mensaje, extrae la información necesaria (proyecto, task, timetracking, usuario etc...) y la añade a la tabla
  4. El BOT notifica que ha realizado la acción con éxito

 

Entrada publicada en Sin categoría | Comentarios cerrados

Simulando errores de red o mejorando la calidad de nuestro software

Una de las cosas que no se suelen probar en los proyectos de desarrollo de software es cómo operan los desarrollos realizados antes situaciones en las que la red falla (los famosos micro-cortes de red tan utilizados para justificar el mal funcionamiento de un software)

Hay proyectos, como el ejercito de monos de netflix ... que sirven para probar estas cosas (hay un mono que se dedica a hacer putadas en la red para ver si los componentes son tolerantes a fallos o no y sobre todo si tenemos efecto de bola de nieve, que es el peor de los problemas cuando diseñas sistemas complejos).

Teniendo claro que lo mejor sería integrar el ejército de monos en los sistemas de calidad de zylk, vamos, de momento, a ser un poco menos ambiciosos y vamos a usar únicamente un conjunto de comandos de sistema operativo para simular problemas en la red.

Para ello haremos uso del comando netem desde el que podemos simular caídas de red, latencia variable, perdidas de paquetes etc... Los comandos base que podemos usar son

 

>sudo tc qdisc add dev eth0 root netem delay 900ms 10ms distribution normal

Que nos permite añadir un delay a las peticiones de red (eth0) que corresponde a una distribución gaussiana con un máximo de delay de 900ms y un mínimo de 10ms centrada en el 900 y con una campana de 10 de ancho.

>sudo tc qdisc add dev eth0 root netem loss 0.1%

Que nos permite simular una perdida de paquetes del 0.1%

Existen comandos equivalentes para forzar la corrupción de paquetes, duplicidad de los mismos y un montón de cosas más...

La conclusión, una vez que usas este tipo de técnicas para realizar las QA de los proyectos, es que ... Ohhh dios mio!!! (que dirían en friends) los patrones que usa la gente no suelen ser los correctos y fallan estrepitosamente ante este tipo de problemas. Además ahora hay que tener especial cuidado ya que todo se ve como un servicio y un cliente que se conecta a dicho servicio.... Habrá que repasar este patrón. Y estar más atento a lo que hace la gente de netflix que de este tema parece saber mucho mucho mucho... En zylk ya llevamos algún tiempo usando estas técnicas para probar, en condiciones adveras, algunos de los proyectos que realizamos.

Entrada publicada en Sin categoría | Comentarios cerrados

How to control public shared content in Alfresco

Last day, I was asked for a client about how to control "public" shared content in Alfresco Share in a simple way. These are some of the ideas of the support conversation:
 
[me] First, just write in the Alfresco Share search box, the next querys. You should see your shared content. 
 
ASPECT:"qshare:shared" 
ASPECT:"qshare:shared" AND @cm:creator:"ccl001"
ASPECT:"qshare:shared" AND @qshare:sharedBy:"ccl001"
ASPECT:"qshare:shared" AND @cm:modified:["2014-12-31" TO NOW]
ASPECT:"qshare:shared" AND @cm:modified:[MIN TO "2013-12-31"]
 
[client] OMG! There exists a lot of public documents... What can we do for managing this ? Querys are right but many final users do not understand complex queries, and they are not familiar with aspects.
 
[me] Right, we can implement a document filter query in sites and/or in My documents dashlet, for final users.
 
[client] We are not sure about document library filters... because filters will appear in all sites, for all users. What about for Alfresco Admins ? May we get a list of public nodes ? How can we unshare these public urls ? 
 
[me] Just removing qhare:shared aspect. For alfresco admins, we can run a simple script in Javascript API for getting a brief report in CSV, via Alfresco Javascript Console. This should be valid also for users that create rules on their sites, executing the JS code. This is only valid for 1000 items, although you can run it several times (which is not always possible). 
 
var nodes = search.luceneSearch('ASPECT:"qshare:shared"');
var count = 0;
for each(var node in nodes) {
        count = count + 1;
        logger.log(count + ": "+node.displayPath+"/"+node.name);           
        // Uncomment these two lines for unsharing
        //logger.log("  Cleaning the aspect..");    
        //node.removeAspect("qshare:shared");
        //node.save();
        //logger.log("  Done");                        
}
 
[client] Mmm... I don't see the full picture, yet.
 
[me] Ok, we can filter query by modified date too. You can assume that content is shared before being modified and then to unpublish them if the content was modified many time ago.
 
var nodes = search.luceneSearch('ASPECT:"qshare:shared" AND @cm\\:modified:["2014-12-31" TO NOW]'); 
 
[client] This is a little tricky... but I'm not sure about it.
 
[me] Ok, you can use cm:effectivity aspect in Alfresco content, and use cm:to property for controlling the end lifecycle on your public nodes and urls. So, add aspect Effectivity, to the node to be shared, and then edit effectivity properties.
 
[client] I don't see it, this implies more work for final users.
 
[me] Well, you may also use content rules, for setting cm:to by a default relative date, if the content is shared.
 
[client] Better. Something more ?
 
[me] Then, we can write another script that checks the expiration date cm:to (i.e. today), and then remove the aspect or aspects.
 
var today  = new Date();
var month = today.getMonth() + 1; //months from 1-12
var day     = today.getDate();
var year    = today.getFullYear();
var mydate = year+"-"+month+"-"+day;
var nodes = search.luceneSearch('ASPECT:"qshare:shared" AND @cm\\:to:"'+mydate+'"');
var count = 0;
for each(var node in nodes) {
  count = count + 1;
  logger.log(count + ": "+node.displayPath+"/"+node.name);
  logger.log(" This public url is expired --> "+node.properties["cm:to"]);
  logger.log(" Cleaning the aspect..");
  node.removeAspect("qshare:shared");
  //node.removeAspect("cm:effectivity");
  node.save();
  logger.log("Done");
}
 
[client] It sounds even better.
 
[me] And finally, we can do a daily quartz executing the javascript code, to unshare the public urls.
 
 
[client] Ok, let's do it. 
 
P.S: Tested in Alfresco 4.2.4 EE (although it may work in other versions).
Entrada publicada en Sin categoría | Comentarios cerrados

Avro RCP yarn and slider II

Siguiendo con la visión de una arquitectura basada en yarn y mirco servicios ... os dejo un diagrama completo de los componentes y su comportamiento

 

 

Entrada publicada en Sin categoría | Comentarios cerrados

Avro RCP yarn and slider

Siguiendo con los artículos relacionados con YARN, SLIDER y arquitecturas relacionadas con BigData mostramos a continuación una posible arquitectura basda en los siguientes tres elementos

Donde lo importante es que con este tipo de arquitectura podríamos disponer de servicios con las caraterísticas indicadas

La idea en este caso es desplegar los servicios que se pueden generar con AVRO en un cluster de yarn empaquetando estos servicios como aplicaciones YARN.

Entrada publicada en Sin categoría | Comentarios cerrados

Online edition with Libreoffice in Alfresco 5

Last days I was asked for a tip (again) for enabling online edition via webdav with Libreoffice in Alfresco 5. It is tested with this setup:
  • Ubuntu 14.04 LTS (although it can work in other Linux)
  • Libreoffice 4.2.8.2 (it comes with the Linux distro)
  • Alfresco CE 5.0c && 5.0d (the jar is valid for Alfresco 4 too)
  • Last versions of Firefox and Chrome
So, in your Alfresco 5 server you need to download the jar file and copy in $ALF_HOME/tomcat/shared/lib directory, restarting alfresco service:
 
 
Once, you should see "Edit. Online" action for MS-Office and Libreoffice mimetypes. It is clear that you need webdav enabled in your repository (and access to the webdav context).
 
Then, for make it work, you need to register an url-handler based protocol for dav:// and davs:// urls with Libreoffice. This can be done via two methods (that can work in different versions of Linux).
 
Method 1:
 
Create the next file, and the corresponding path, if it does not exist.
 
$ vim ~/.local/share/applications/libreoffice-alf.desktop 
[Desktop Entry]
Encoding=UTF-8
Version=1.0
Name=LibreOffice for Alfresco
GenericName=LibreOffice for Alfresco
Comment=Online Editing in Alfresco via webdav
Icon=libreoffice-writer
TryExec=soffice
Exec=soffice %U
Terminal=false
Type=Application
Categories=Office;
MimeType=x-scheme-handler/davs;x-scheme-handler/dav
 
2. Create the mimeapps.list file, if it does not exist. If it exist, just add the two x-scheme handlers,
 
$ vim ~/.local/share/applications/mimeapps.list
[Added Associations]
x-scheme-handler/davs=libreoffice-alf.desktop;
x-scheme-handler/dav=libreoffice-alf.desktop;
 
Method 2: 
 
This is done for all users of the operating systems, you need sudoer privileges
 
1. Just create the file in the next path:
 
$ sudo vim /usr/share/applications/libreoffice-alf.desktop
[Desktop Entry]
Encoding=UTF-8
Version=1.0
Name=LibreOffice for Alfresco
GenericName=LibreOffice for Alfresco
Comment=Online Editing in Alfresco via webdav
Icon=libreoffice-writer
TryExec=soffice
Exec=soffice %U
Terminal=false
Type=Application
Categories=Office;
MimeType=x-scheme-handler/davs;x-scheme-handler/dav
 
2. Add x-scheme-handlers to mimeinfo.cache
 
$ sudo vim /usr/share/applications/mimeinfo.cache
 
# Add to the file
x-scheme-handler/davs=libreoffice-alf.desktop;
x-scheme-handler/dav=libreoffice-alf.desktop;
 
3. Update desktop cache
 
$ sudo update-desktop-database 
 
Then when you "Edit. online", you see some dialog for remembering the action for opening the url. Libreoffice asks for your credentials once in a session.
 
For Windows users, it is possible to register the protocol too, with the help of (there is also a .reg file in the downloads section of the googlecode project - put the correct path for the Libreoffice command):
 
Entrada publicada en Sin categoría | Comentarios cerrados

Usando yarn y slider para levantar procesos en un cluster de hortonworks

Siguiendo con las pruebas y las arquitecturas relacionados con bigdata vamos a inspeccionar las capacidades de yarn para levantar procesos en un cluster HDP. Lo primero que habría que introducir es el producto yarn. De la página siguiente de hortonworks podemos obtener la siguiente definición

YARN is the prerequisite for Enterprise Hadoop, providing resource management and a central platform to deliver consistent operations, security, and data governance tools across Hadoop clusters.
YARN also extends the power of Hadoop to incumbent and new technologies found within the data center so that they can take advantage of cost effective, linear-scale storage and processing. It provides ISVs and developers a consistent framework for writing data access applications that run IN Hadoop.


Por tanto como podemos ver yarn es una suerte de sistema operativo para interactuar con hadoop y que éste (yarn) gestione los recursos del cluster de hadoop/hortonworks.

Sobre Yarn existen varios APIs que podemos usar para desplegar nuestros propios procesos.

  • YARN (API de más bajo nivel sobre el que se montan, TEZ y SLIDER)
  • TEZ (API para simplificar el desarrollo de aplicaciones que se pueden ejecutar sobre YARN, se puede ver como un API para ejecutar procesos, por ejemplo scripts de PIG, HIVE etc...)
  • SLIDER (API que simplifica el desarrollo de aplicaciones que se pueden ejecutar sobre YARN, a diferencia de TEZ slider está diseñado para es levantar servicios, como explican el la página de howtonworks, Slider is a framework for deployment and management of these long-running data access applications in Hadoop)


Una vez presentados los tres "sabores" principales vamos con el caso de uso que estamos probando. En este caso lo que vamos a crear es bot para slack que va a leer los mensajes de un canal y va a contestar a los mensajes de dicho canal. La idea es que una vez que tengamos esa aplicación java desarrollada la levantemos sobre el cluster de hdp/yarn usando slider.

La arquitectura general de la solución es la siguiente




Donde podemos ver que los eventos producidos en un canal de slack son consumidos por el bot que se ha levantado en un cluster de hadoop usando slider. Para desarrollar esta prueba de concepto los requisitos son

El primer requisito se ha tratado en otros posts en este blog. El segundo requisito es la parte en la que nos hemos centrado para crear esta entrada. Un paquete slider se compone (a grandes rasgos) de los elementos que vemos en la siguiente imagen



Donde lo principal son los ficheros de configuración, los scripts de arranque, y los binarios que se ejecutan. Los binarios son la parte que en este caso hemos desarrollado en java. Los archivos de configuración nos permiten definir las siguientes características:

  • classloader de la aplicación
  • version de java que se quiere usar
  • memoria reservada para el proceso
  • nombre del paquete/servicio
  • parámetros extra que se pasan al proceso (pueden ser parámetros gestionados por el que despliega el proceso o por el propio nodo donde se levanta el proceso)
  • threshold que nos permite definir los límites que hacen que un proceso que se ha detenido se vuelva a levantar automáticamente. Por ejemplo si se ha producido un error de comunicación y el proceso se muere según definamos los límites el proceos se volverá a levantar de manera automática.
  • numero mínimo y máximo de procesos que se deben levantar
  • ... y un montón más de características que podemos ver en el site del proyecto

Una vez que tenemos el paquete creado podríamos desplegarlo usando los siguientes comandos de slider

  • slider  package --install --replacepkg  --name MOMO_BOT --package /home/hadoop/jenkins/jobs/slack_bot/slack_bot-0.0.1-SNAPSHOT-slider-package.zip
  • slider stop momo_bot
  • slider  destroy momo_bot
  • slider  create momo_bot --template /home/hadoop/jenkins/jobs/slack_bot/appConfig-default.json --resources /home/hadoop/jenkins/jobs/slack_bot/resources-default.json

Una vez ejecutada esta secuencia podremos ver nuestro proceso desde la vista slider de nuestro ambari.

Para la generación del paquete hemos usando maven y para el despliegue automatizado jenkins. El objetivo de esta prueba era analizar las características de slider como modelo de despliegue de aplicaciones. El hecho de desplegar una aplicación usando este modelo dota al servicio de las siguientes características

  • auto-escalado
  • monitorización y re-arranque de containers en base de los parámetros definidos en la configuración del paquete slider
  • gestión de los recursos asociados al servicio usando del modelo de containers de yarn
  • registro automático del servicio etc..

En esta página se puede ver todo lo que slider puede hacer (https://slider.incubator.apache.org/docs/manpage.html). Lo más destacable a nuestro modo de ver sería

  • A user can create an application instance.
  • Users can flex an application instance: adding or removing components dynamically. If the application instance is live, the changes will have immediate effect. If not, the changes will be picked up when the instance is next started.

Y como última conclusión ... slider es mucho más que de lo que se ha explicado en este post... parafraseando a pedro salinas ... Eso no es nada aún. Buscaos bien, hay más.

Entrada publicada en Sin categoría | Comentarios cerrados

How to track SOLR indexation process in Alfresco

For tracking indexation in SOLR, we have the Alfresco Administration Console, which gives us the indexation status, the indices in disk, and an estimation of the remaining time of transactions to be indexed. This is available in Enterprise edition in Admin Console:
 
  http://localhost:8080/alfresco/service/enterprise/admin/admin-searchservice
 
This information is directly taken from SOLR Summary XML Report (in this case the url is using 8080 instead of the default secured 8843):
 
  http://localhost:8080/solr/admin/cores?action=SUMMARY&wt=xml
 
Another way for tracking or monitoring the indexation progress is to set debug logger in log4j.properties of SOLR application:
 
  log4j.logger.org.alfresco.solr.tracker.CoreTracker=DEBUG
 
In SOLR, the log4j can not be extended out of WEB-INF (as in Alfresco Share) and you should change it directly under WEB-INF directory at:
 
  /opt/alfresco424/tomcat/webapps/solr/WEB-INF/classes/log4j.properties
 
The best part of this is that you can activate it or reload it (without restarting the service) with this action:
 
  http://localhost:8080/solr/admin/cores?action=LOG4J
 
By last, you can monitor size data.dir.root for SOLR via operating system, or via JMX (only in EE edition) with the next bean and their corresponding variables:
 
In jmxterm the sequence is the next one:
 
> jvms
> open <tomcat-id>
> domain Alfresco
> bean Alfresco:Category=Search,Type=Configuration,id1=managed,id2=solr
 
> get tracker.alfresco.active
> get tracker.alfresco.approx.indexing.time.remaining
> get tracker.alfresco.approx.txns.remaining
> get tracker.alfresco.disk
> get tracker.alfresco.lag
> get tracker.alfresco.lag.duration
> get tracker.alfresco.last.indexed.txn
> get tracker.alfresco.memory
 
Finally, you must take into consideration that there is an issue for getting this data if archive core is disabled by config in SOLR (in < Alfresco 4.2.5).
 
Entrada publicada en Sin categoría | Comentarios cerrados

How to get logs for Alfresco querys

For getting more information about Alfresco querys just edit (extend) custom-log4j.properties in extension directory, for example:
 
/opt/alfresco/tomcat/shared/classes/alfresco/extension/custom-log4j.properties
 
SQL queries:
 
  log4j.logger.java.sql=debug
  log4j.logger.java.sql.Connection=DEBUG
  log4j.logger.java.sql.Statement=DEBUG
  log4j.logger.java.sql.PreparedStatement=DEBUG
  log4j.logger.java.sql.ResultSet=DEBUG
 
Be careful, this is pretty verbose. Be careful with caches too!.
 
SOLR queries:
 
  log4j.logger.org.alfresco.repo.search.impl.solr.SolrQueryHTTPClient=DEBUG
  log4j.logger.org.alfresco.repo.search.impl.solr.DbOrIndexSwitchingQueryLanguage=DEBUG
 
Javascript API queries:
 
  log4j.logger.org.alfresco.repo.jscript.ScriptLogger=DEBUG
  log4j.logger.org.alfresco.repo.jscript.Search=DEBUG
 
In Alfresco Enterprise, you have more options for doing this without restarting the service:
although not all classes are enabled via JMX or support tools, for example the SQL and DbOrIndexSwitchingQueryLanguage loggers. Tested in Alfresco 4.2.4 EE.
 
Links:
Entrada publicada en Sin categoría | Comentarios cerrados