Planète AFPy RSS

[carlchenet] Liens intéressants Journal du hacker semaine #35

Publié le 2015-08-27 20:30:29
Suivez-moi aussi sur Diaspora* ou Twitter  ou sur Identi.ca Pour cette 35ème semaine de 2015, 5 liens intéressants que vous avez peut-être ratés, relayés cette semaine par le Journal Du Hacker, votre source d’informations pour le Logiciel Libre francophone ! Une avalanche de FUD sur Mozilla et Firefox APT : Début de simplification Lecteur de flux…

[afpyro] AFPyro à Lyon - mercredi 26 août

Publié le 2015-08-26 00:00:00

Un Afpyro aura lieu le mercredi 26 août à partir de 19h au Gîte Numérique - 6 rue Saint Georges - 69005 Lyon.

Il n’y aura pas de présentation ce mois ci, nous discuterons de pythoneries en toute tranquillité. Nous pourrons aussi voir à organiser les activités à venir !

Les participants sont invités à ramener des boissons ou de la nourriture à partager.

Pour se rendre au Gîte Numérique :

  • en métro : arrêt Vieux Lyon - Cathédrale Saint Jean
  • en bus : lignes C20 ou 31 arrêt Saint Georges ou Sala
  • en vélo’v : stations Saint Jean / Cathédrale, Place Crépu

Nous demandons aux participants de respecter la charte de l’AFPy (lisez là !).

[carlchenet] Retweet 0.2, le bot Twitter : passage à Python 3

Publié le 2015-08-25 21:04:03
Suivez-moi aussi sur Diaspora* ou Twitter  ou sur Identi.ca Pour rappel, Retweet est un bot Twitter qui retweete tout ce qui provient d’un compte Twitter particulier vers un autre compte. Version 0.2 de Retweet sur Github Dépôt Github du projet Retweet Documentation officielle de Retweet Créer une application Twitter (prérequis à l’utilisation de Retweet) Retweet…

[logilab] DebConf15 wrap-up

Publié le 2015-08-25 16:13:00
//www.logilab.org/file/856155/raw/heidelberg-panorama-2.jpg

I just came back from two weeks in Heidelberg for DebCamp15 and DebConf15.

In the first week, besides helping out DebConf's infrastructure team with network setup, I tried to make some progress on the library transitions triggered by libstdc++6's C++11 changes. At first, I spent many hours going through header files for a bunch of libraries trying to figure out if the public API involved std::string or std::list. It turns out that is time-consuming, error-prone, and pretty efficient at making me lose the will to live. So I ended up stealing a script from Steve Langasek to automatically rename library packages for this transition. This ended in 29 non-maintainer uploads to the NEW queue, quickly processed by the FTP team. Sadly the transition is not quite there yet, as making progress with the initial set of packages reveals more libraries that need renaming.

Building on some earlier work from Laurent Bigonville, I've also moved the setuid root Xorg wrapper from the xserver-xorg package to xserver-xorg-legacy, which is now in experimental. Hopefully that will make its way to sid and stretch soon (need to figure out what to do with non-KMS drivers first).

Finally, with the help of the security team, the security tracker was moved to a new VM that will hopefully not eat its root filesystem every week as the old one was doing the last few months. Of course, the evening we chose to do this was the night DebConf15's network was being overhauled, which made things more interesting.

DebConf itself was the opportunity to meet a lot of people. I was particularly happy to meet Andreas Boll, who has been a member of pkg-xorg for two years now, working on our mesa package, among other things. I didn't get to see a lot of talks (too many other things going on), but did enjoy Enrico's stand up comedy, the CitizenFour screening, and Jake Applebaum's keynote. Thankfully, for the rest the video team has done a great job as usual.

Note

Above picture is by Aigars Mahinovs, licensed under CC-BY 2.0

[carlchenet] Le Journal du hacker choisit son nom de domaine !

Publié le 2015-08-24 21:02:50
Suivez-moi aussi sur Diaspora* ou Twitter  ou sur Identi.ca Le Journal du hacker, après avoir choisi son logo, met de nouveau ses inscrits à contribution en leur demandant de voter pour le nom de domaine définitif du Journal ! Pour nos lecteurs qui n’auraient pas encore de compte, il suffit d’en faire la demande ici…

[carlchenet] Liens intéressants Journal du hacker semaine #34

Publié le 2015-08-20 20:30:39
Suivez-moi aussi sur Diaspora* ou Twitter  ou sur Identi.ca Pour cette 34ème semaine de 2015, 5 liens intéressants que vous avez peut-être ratés, relayés cette semaine par le Journal Du Hacker, votre source d’informations pour le Logiciel Libre francophone ! Un tracker caché dans Ghostery ! Sécurité : Docker fait un pas en avant avec…

[carlchenet] Liens intéressants Journal du hacker semaine #33

Publié le 2015-08-13 22:00:59
Suivez-moi aussi sur Diaspora* ou Twitter  ou sur Identi.ca Pour cette 33ème semaine de 2015, 5 liens intéressants que vous avez peut-être ratés, relayés cette semaine par le Journal Du Hacker, votre source d’informations pour le Logiciel Libre francophone ! Une analyse de trafic réseau de Windows 10 dévoile l’incroyable étendue de l’espionnage mis en…

[logilab] Going to DebConf15

Publié le 2015-08-11 12:29:00

On Sunday I travelled to Heidelberg, Germany, to attend the 16th annual Debian developer's conference, DebConf15.

The conference itself is not until next week, but this week is DebCamp, a hacking session. I've already met a few of my DSA colleagues, who've been working on setting up the network infrastructure. My other plans for this week involve helping the Big Transition of 2015 along, and trying to remove the setuid bit from /usr/bin/X in the default Debian install (bug #748203 in particular).

As for next week, there's a rich schedule in which I'll need to pick a few things to go see.

//www.logilab.org/file/524206/raw/Dc15going1.png

[sciunto] Don du mois : pdf2htmlEX

Publié le 2015-08-09 22:00:00

Ce post s'inscrit dans la série des dons pour vous donner envie de contribuer même très modestement à des logiciels libres. Les petites pierres font les grands édifices.

Mes précédents dons étaient destinés à des projets. J'ai découvert très récemment pdf2htmlEX, un logiciel permettant de convertir un pdf en html avec une fidélité exceptionnelle. Le logiciel est d'ailleurs particulièrement adapté pour les équations.

Je tire du README quelques examples:

  • Bible de Genève, 1564 (fonts and typography): HTML / PDF
  • Cheat Sheet (math formulas): HTML / PDF
  • Scientific Paper (text and figures): HTML / PDF
  • Full Circle Magazine (read while downloading): HTML / PDF
  • Git Manual (CJK support): HTML / PDF

J'ai eu l'occasion de tester ce logiciel sur quelques uns de mes documents (produit avec LaTeX), et je suis bluffé par le résultat. Etant auto-hébergé, l'affichage progressif de l'html améliorera l'expérience utilisateur. C'est donc 7$ qui vont à l'auteur de ce projet ce mois-ci.

[carlchenet] Liens intéressants Journal du hacker semaine #32

Publié le 2015-08-06 22:00:08
Suivez-moi aussi sur Diaspora* ou Twitter  ou sur Identi.ca Pour cette 32ème semaine de 2015, 5 liens intéressants que vous avez peut-être ratés, relayés cette semaine par le Journal Du Hacker, votre source d’informations pour le Logiciel Libre francophone ! Retweet, le bot Twitter qui … retweete OpenShift 3 : le PaaS privé avec Docker…

[afpy.org] PyCon-fr 2015 l'appel à conférencier est prolongé

Publié le 2015-08-06 19:30:04
Chaque année nous refusons des confs, par manque de place, (très peu par manque d'intérêt, ou pour cause de hors sujet). Nous avons déjà une cinquantaine de proposition de talks de très bonne facture et l'on pourrait s'arrêter là, cependant cette année nous avons la chance d'être accueilli dans un lieu qui dispose de 3 salles !, nous pouvons augmenter le nombre de slots.

[carlchenet] Retweet, le bot Twitter qui … retweete

Publié le 2015-08-04 22:00:23
Suivez-moi aussi sur Diaspora* ou Twitter  ou sur Identi.ca Pour les besoins du Journal du hacker, le Hacker News francophone, j’ai eu besoin d’écrire rapidement un bot Twitter qui retweete tout ce qui provient d’un compte Twitter particulier vers un autre, dans mon cas particulier depuis le compte Twitter du Journal du hacker vers mon…

[carlchenet] My Free activities in July 2015

Publié le 2015-08-02 22:00:36
Follow me on Identi.ca  or Twitter  or Diaspora* Here are the details of my Free activities in July 2015. Carl Chenet’s projects: Retweet – version 0.1 – Github home page a small project of Twitter bot for le Journal du hacker – small and efficient. Github star it if you like it ;) Le Journal du hacker…

[sciunto] Scifig : générer ses figures sans effort (avec latex, tikz, python, gnuplot, etc.)

Publié le 2015-08-02 22:00:00

J'ai déjà parlé sur ce blog d'un outil pour générer mes figures sans peine ici et . Je l'utilise dans le cadre de mon travail de recherche.

En quelques mots, l'idée est d'avoir un outil de construction qui converti des sources vers des fichiers finaux tels que eps, pdf, svg, png, avec un support de traduction. il doit gérer des graphiques, des schémas, des graphiques avec des schémas, des formules chimiques, etc. L'outil que j'avais précédemment codé ne me donnait pas entière satisfaction car il reposait sur waf et il n'était pas toujours facile de faire évoluer les règles de compilation.

Les objectifs :

  • automatisation (une commande construit tout)
  • reproductibilité (je sais comment chaque figure a été générée)
  • versionnage des sources (je sais ce qui a pu changer)
  • données stockées à un seul endroit (facile à sauvegarder)

Les choix technologiques et le principes ont été expliqués dans les précédents billets. L'utilisation intensive que j'en ai fait (environ 200 à 300 figures générées jusqu'ici) valident totalement ces choix par l'usage.

Le principe étant très simple, j'ai décidé de recoder l'outil (nommé scifig) en python sans dépendance forte à une librairie existante. J'ai tiré profit de mon expérience avec waf pour soigner l'affichage, les logs et le principe de deux répertoires src/ et build/ ainsi que d'un export vers un répertoire de travail. L'avantage que je tire avec un code qui se suffit à lui-même est que l'écriture de règles doit être évident (ou alors, j'ai mal conçu ma bibliothèque).

Par la suite, il faudra que j'ajoute quelques nouvelles fonctionnalités qui me manquent et que j'avais du mal à inclure dans ma précédente version :

  • construction rapide (un seul format) pour les retouches des figures
  • règles pour matplotlib
  • sorties png avec canal alpha et noir et blanc (utile pour vérifier qu'une figure est lisible sans imprimante couleur)

Plus de détails se trouvent sur mon wiki et dans la documentation.

[carlchenet] Liens intéressants Journal Du Hacker semaine #31

Publié le 2015-07-30 22:00:58
Suivez-moi aussi sur Diaspora* ou Twitter  ou sur Identi.ca Pour cette 31ème semaine de 2015, 5 liens intéressants que vous avez peut-être ratés, relayés cette semaine par le Journal Du Hacker, votre source d’informations pour le Logiciel Libre francophone ! L’installation par défaut de Windows 8.1, ou comment légalement autoriser les USA à nous espionner…

[carlchenet] Vidéo de présentation de Backup Checker aux RMLL 2015

Publié le 2015-07-28 22:00:20
Suivez-moi aussi sur Diaspora* ou Twitter  ou sur Identi.ca Pour ceux qui n’ont pas pu se rendre RMLL 2015 qui avaient lieu à Beauvais cette année, je vous propose la vidéo de présentation de Backup Checker en français que l’équipe des RMLL a réalisée. Pour rappel, le but de cet outil est de détecter les…

[carlchenet] Le Journal du hacker choisit son logo !

Publié le 2015-07-26 22:00:05
Suivez-moi aussi sur Diaspora* ou Twitter  ou sur Identi.ca Après avoir modifié son nom, le Journal du hacker choisit son logo ! Et vous pouvez l’aider si vous êtes membre du Journal en choisissant vos 6 logos préférés sur 99designers puis en votant ici. Il s’agit ici de choisir un concept et un illustrateur, pas…

[carlchenet] Liens intéressants Journal Du Hacker semaine #30

Publié le 2015-07-23 22:00:48
Suivez-moi aussi sur Diaspora* ou Twitter  ou sur Identi.ca Pour cette 30ème semaine de 2015, 5 liens intéressants que vous avez peut-être ratés, relayés cette semaine par le Journal Du Hacker, votre source d’informations pour le Logiciel Libre francophone ! Transformer un Rasperry Pi en chaîne Hifi avec Hifiberry Amp+ Premiers pas avec Cassandra [Debian…

[carlchenet] Le Journal Du Hacker remplace le Journal Du Pirate

Publié le 2015-07-22 22:00:43
Suivez-moi aussi sur Diaspora* ou Twitter  ou sur Identi.ca Un consensus s’étant dégagé des différentes discussions autour du changement de nom du Journal Du Pirate, nous sommes heureux de vous annoncer le nouveau nom de votre média participatif du Logiciel Libre : Le Journal Du Hacker Pour rappel, le journal propose une sélection de l’actualité…

[AFPy Salt-fr] Compte rendu "Table ronde et Comparaison des frameworks" Salt Ansible Chef Puppet

Publié le 2015-07-16 22:00:00

Comme annoncé sur ce blog, le meetup de juin était un peu particulier. Nous avons rassemblé plusieurs frameworks pour discuter comparativement des technologies similaires à Salt. Nous sommes ressortis avec une idée plus précise des forces et faiblesses de chacun, mais aussi des idées pour améliorer Salt.

Voici les diapositives utilisées pour introduire la soirée.

Merci à Mathieu de Bearstech, Guilhem de Wemanity, Francois de D2SI et Arthur de Logilab pour leurs interventions.

Puppet Salt Ansible Chef Logilab Bearstech Wemanity D2SI

Nous avons abordé 8 grandes thématiques :

  • Introduction intervenants et leurs entreprises
  • Introduction générale par projet, historique, key features, langages de programmation, DSLs, installation multiplateforme (linux, unix, windows, mac, etc. ?)
  • Déploiement de configuration et templating
  • Exécutions de commandes, organisation des noeuds, machines, ciblage
  • Architecture (réseau, parefeux, bus de communication, protocoles)
  • Extensibilité, plugins, écriture et déploiement
  • Orchestration, gestion de resources élastiques (cloud)
  • Délégation, collaboration, environnements (dev, preprod, prod), approche Devops
  • Composants "sur étagère", taille de la communauté, utilisateurs notables
  • Offres "entreprise" autour ou écosystème commercial, Logique open-source / open-core, formations, livres
Meetup Salt juin 2015

Le meetup était visionnable en direct en streaming sur Dailymotion et un montage de l'enregistrement a été publié par École42 :


CONF@42 - MeetUp Salt par 42Born2Code

Nous avons fini la soirée autour de pizzas et boissons offertes par Logilab.

Lors de l'organisation (sur le pad notamment), plusieurs personnes ont montré un intérêt pour ce type de débat, notamment dans d'autres villes que Paris (Lyon, Rennes, Nantes), n'hésitez pas à nous en parler sur la liste de discussion pour qu'on réitère l'expérience.

[sciunto] Don du mois : Joey Hess

Publié le 2015-07-10 22:00:00

Ce post s'inscrit dans la série des dons pour vous donner envie de contribuer même très modestement à des logiciels libres. Les petites pierres font les grands édifices.

Mes précédents dons étaient destinés à des projets. Ce mois-ci, j'ai décidé de faire à don à Joey Hess, un développeur de logiciel libre dont voici la liste. J'utilise trois d'entre-eux et pas des moindres :

  • git-annex (stocker des binaires dans git à la manière d'un système de portage BSD, une véritable killer-feature)
  • ikiwiki (pour mes blogs et wiki)
  • etckeeper (pour l'admin sys, ca versionne les fichiers de config).

Ces logiciels sont d'une très grande qualité, pas destiné à un grand public mais ils permettent de faire des choses uniques et ça me rend bien service. Il est aussi amusant de lire sa page sur ses goûts en matière de langages de programmation.

Joey propose sur son site plusieurs moyens pour les dons et j'ai choisi de lui offrir un album sur sa liste amazon, une manière très intéressante de dire merci je trouve.

[afpyro] AFPyro à Lyon - mercredi 24 juin

Publié le 2015-06-24 00:00:00

Un Afpyro aura lieu le mercredi 24 juin à partir de 19h au Gîte Numérique - 6 rue Saint Georges - 69005 Lyon.

Il n’y aura pas de présentation ce mois ci, nous disucterons de pythoneries en toute tranquillité.

Les participants sont invités à ramener des boissons ou de la nourriture à partager.

Pour se rendre au Gîte Numérique :

  • en métro : arrêt Vieux Lyon - Cathédrale Saint Jean
  • en bus : lignes C20 ou 31 arrêt Saint Georges ou Sala
  • en vélo’v : stations Saint Jean / Cathédrale, Place Crépu

[afpy.org] PyCon-FR 2015 We Want You !

Publié le 2015-06-20 08:32:38
La PyCon-FR 2015 se déroulera donc à Pau du 17 au 20 Octobre à l'E.I.S.T.I

[logilab] Exemple de "contrat agile" mis en place entre Logilab et ses clients

Publié le 2015-06-19 11:41:00

Dans la mesure du possible, nous essayons de travailler avec nos clients en mode agile. Bon, c'est pas toujours évident, ça ne s'applique pas à tout le monde, mais ce n'est pas le sujet de ce billet. Supposons donc que vous ayez un client déjà initié au sujet et souhaitant fonctionner de cette manière avec vous (si si ça peut arriver !).

Même dans ce cas, il reste à préciser un certain nombre de points qui vont définir plus précisément les processus et interactions, comme par exemple la durée des itérations, le ou les environnements de test / production et autres manières d'utiliser les outils de suivis. C'est précisément l'objet de ce qu'on appelle le contrat agile, dont voici un exemple qu'il me semble utile de partager avec vous (miroir sur slideshare).

https://www.logilab.org/file/294043/raw/handshake.jpg

(photo by Julia Taylor licence CC BY-NC-ND )

Cet exemple a été légèrement anonymisé. Il rappelle quelques éléments d'agilité et définit :

  • le cycle de développement (itération, recette, etc)
  • les livrables et environnements
  • le mode de fonctionnement avec notre extranet de suivi (une variante de cette forge)

Il vous faudra donc de fait l'adapter à votre projet, en collaboration avec votre client. Et évidemment, dans un esprit agile, le faire évoluer au fur et à mesure du temps (dans l'exemple avec notre client, nous en sommes à la 3eme version).

Les sources sont du HTML qui utilise showr et je n'ai aucun problème à les partager pour ceux qui ça intéresse.

Enfin merci de me faire part de vos remarques et retours sur ce contrat !

[logilab] Experiments on building a Jenkins CI service with Salt

Publié le 2015-06-17 11:15:00

In this blog post, I'll talk about my recent experiments on building a continuous integration service with Jenkins that is, as much as possible, managed through Salt. We've been relying on a Jenkins platform for quite some time at Logilab (Tolosa team). The service was mostly managed by me with sporadic help from other team-mates but I've never been entirely satisfied about the way it was managed because it involved a lot of boilerplate configuration through Jenkins user interface and this does not scale very well nor does it make long term maintenance easy.

So recently, I've taken a stance and decided to go through a Salt-based configuration and management of our Jenkins CI platform. There are actually two aspects here. The first concerns the setup of Jenkins itself (this includes installation, security configuration, plugins management amongst other things). The second concerns the management of client projects (or jobs in Jenkins jargon). For this second aspect, one of the design goals was to enable easy configuration of jobs by users not necessarily familiar with Jenkins setup and to make collaborative maintenance easy. To tackle these two aspects I've essentially been using (or developing) two distinct Salt formulas which I'll detail hereafter.

Jenkins jobs salt

Core setup: the jenkins formula

The core setup of Jenkins is based on an existing Salt formula, the jenkins-formula which I extended a bit to support map.jinja and which was further improved to support installation of plugins by Yann and Laura (see 3b524d4).

With that, deploying a Jenkins server is as simple as adding the following to your states and pillars top.sls files:

base:
  "jenkins":
    - jenkins
    - jenkins.plugins

Base pillar configuration is used to declare anything that differs from the default Jenkins settings in a jenkins section, e.g.:

jenkins:
  lookup:
    - home: /opt/jenkins

Plugins configuration is declared in plugins subsection as follows:

jenkins:
  lookup:
    plugins:
      scm-api:
        url: 'http://updates.jenkins-ci.org/download/plugins/scm-api/0.2/scm-api.hpi'
        hash: 'md5=9574c07bf6bfd02a57b451145c870f0e'
      mercurial:
        url: 'http://updates.jenkins-ci.org/download/plugins/mercurial/1.54/mercurial.hpi'
        hash: 'md5=1b46e2732be31b078001bcc548149fe5'

(Note that plugins dependency is not handled by Jenkins when installing from the command line, neither by this formula. So in the preceding example, just having an entry for the Mercurial plugin would have not been enough because this plugin depends on scm-api.)

Other aspects (such as security setup) are not handled yet (neither by the original formula, nor by our extension), but I tend to believe that this is acceptable to manage this "by hand" for now.

Jobs management : the jenkins_jobs formula

For this task, I leveraged the excellent jenkins-job-builder tool which makes it possible to configure jobs using a declarative YAML syntax. The tool takes care of installing the job and also handles any housekeeping tasks such as checking configuration validity or deleting old configurations. With this tool, my goal was to let end-users of the Jenkins service add their own project by providing a minima a YAML job description file. So for instance, a simple Job description for a CubicWeb job could be:

- scm:
    name: cubicweb
    scm:
      - hg:
         url: http://hg.logilab.org/review/cubicweb
         clean: true

- job:
    name: cubicweb
    display-name: CubicWeb
    scm:
      - cubicweb
    builders:
      - shell: "find . -name 'tmpdb*' -delete"
      - shell: "tox --hashseed noset"
    publishers:
      - email:
          recipients: cubicweb@lists.cubicweb.org

It consists of two parts:

  • the scm section declares, well, SCM information, here the location of the review Mercurial repository, and,

  • a job section which consists of some metadata (project name), a reference of the SCM section declared above, some builders (here simple shell builders) and a publisher part to send results by email.

Pretty simple. (Note that most test running configuration is here declared within the source repository, via tox (another story), so that the CI bot holds minimum knowledge and fetches information from the sources repository directly.)

To automate the deployment of this kind of configurations, I made a jenkins_jobs-formula which takes care of:

  1. installing jenkins-job-builder,
  2. deploying YAML configurations,
  3. running jenkins-jobs update to push jobs into the Jenkins instance.

In addition to installing the YAML file and triggering a jenkins-jobs update run upon changes of job files, the formula allows for job to list distribution packages that it would require for building.

Wrapping things up, a pillar declaration of a Jenkins job looks like:

jenkins_jobs:
  lookup:
    jobs:
      cubicweb:
        file: <path to local cubicweb.yaml>
        pkgs:
          - mercurial
          - python-dev
          - libgecode-dev

where the file section indicates the source of the YAML file to install and pkgs lists build dependencies that are not managed by the job itself (typically non Python package in our case).

So, as an end user, all is needed to provide is the YAML file and a pillar snippet similar to the above.

Outlook

This initial setup appears to be enough to greatly reduce the burden of managing a Jenkins server and to allow individual users to contribute jobs for their project based on simple contribution to a Salt configuration.

Later on, there is a few things I'd like to extend on jenkins_jobs-formula side. Most notably the handling of distant sources for YAML configuration file (as well as maybe the packages list file). I'd also like to experiment on configuring slaves for the Jenkins server, possibly relying on Docker (taking advantage of another of my experiment...).

[sciunto] Python : callback à paramètre unique et passage d'options

Publié le 2015-06-13 22:00:00

Le besoin m'est venu de la bibliothèque pims permettant de charger séquentiellement des images. Typiquement, on fait

frames = pims.ImageSequence('../sample_data/bulk_water/*.png')

Mais si on veut appliquer une fonction appliquant un pré-traitement, on peut ajouter une callback


from skimage.color import rgb2grey 
def preprocess(im):
    """
    callback prenant une image im
    """
    return rgb2grey(im)

frames = pims.ImageSequence('../sample_data/bulk_water/*.png', process_func=preprocess)

Ce qui a pour effet que les images soient en niveau de gris plutôt qu'en RGB. Maintenant, imaginons que ce soit un seuil que je souhaite appliquer

def preprocess(im):
    threshold = 0.8
    grey_im = rgb2grey(im)
    # selectionne les indices satisfaisant la condition
    idx = grey_im < grey_im.max() * threshold
    # applique une transformation
    grey_im[idx] = 0
    return grey_im

L'exemple fonctionne toujours, mais on a un paramètre threshold définit dans la fonction, ce qui n'est pas très flexible si on veut placer cette fonction dans une petite bibliothèque maison. Je préfèrerais la signature suivante :

def preprocess(im, threshold=0.8):

Je vais donc définir dans ma bibliothèque la fonction suivante :

# Je definie une fonction qui prend une fonction et des arguments optionels
def all_args(func, **params):
    # Je definie une fonction qui prend une image
    def wrapper(im):
        # Je retourne ma fonction func avec les bons arguments
        return func(im, **params)
    # je retourne une fonction
    return wrapper

# Je definie ma fonction comme je le souhaite
def preprocess(im, threshold=0.8):
    grey_im = rgb2grey(im)
    idx = grey_im < grey_im.max() * threshold
    grey_im[idx] = 0
    return grey_im

Ainsi je peux faire dans mon code principal

from mabiblio import all_args, preprocess

mythreshold = .36

# je crée une fonction new_preprocess à partir de preprocess, auquel je cache
# le parametre threshold
new_preprocess = all_args(preprocess, threshold=mythreshold)

frames = pims.ImageSequence('../sample_data/bulk_water/*.png', process_func=new_preprocess)

Ici, je peux donc utiliser la fonction preprocess, de manière compacte, un peu partout dans mes codes, sans me soucier de son détail.

Je crois que je dois cette astuce à Thomas Caswell que je remercie.

Liens utiles de sametmax :

[carlchenet] Liens intéressants Journal Du Pirate semaine #24

Publié le 2015-06-11 22:00:10
Suivez-moi aussi sur Diaspora* ou Twitter  ou sur Identi.ca Pour cette 24ème semaine de 2015, 5 liens intéressants que vous avez peut-être ratés, relayés cette semaine par le Journal Du Pirate, votre source d’informations pour le Logiciel Libre francophone ! Swift 2 sera open source Papaye 0.2 est arrivé ! #Python #PyPi Debian 8 :…

[logilab] BestOfWeb 2015

Publié le 2015-06-11 20:01:00

Nous étions à la journée BestOfWeb 2015 vendredi. Au programme, quelques unes des présentations jugées les plus intéressantes qui avaient été faites lors de différents meetups orientés "web" ces derniers mois.

http://photos4.meetupstatic.com/photos/event/3/8/3/2/global_434894386.jpeg

Même si j'aurais pu me passer des nombreuses interventions des sponsors et si toutes les présentations n'ont pas retenu mon attention, j'ai dans l'ensemble bien apprécié la journée. Voilà en particulier ce que je retiens :

  • angular n'a plus beaucoup de défenseurs, ou alors ils crient moins fort que les autres. De notre côté, après l'avoir utilisé pour construire quelques applications, la mauvaise documentation, la difficulté à conserver l'application maintenable et le fait qu'angular 2 — qui aura certainement plein de qualités — ne laisse pas de perspective de migration simple du code nous ont amenés à préférer des bibliothèques plus simples comme Backbone ;

  • Microsoft continue à contribuer du code libre et poursuit sa reconquête des développeurs perdus ;

  • j'aurais bien aimé voir Hydra mentionné dans la présentation REST,

  • j'étais resté sur l'utilisation de Accept-Ranges et Range dans le cadre de contenus binaires et je découvre (!) que ça semble être une pratique courante de les utiliser pour la pagination dans les API REST. À utiliser dans CubicWeb ?

  • CSS Grid Layout n'a pas l'air parti pour être utilisable avant un petit moment ;

  • l'an dernier, dans le cadre d'une collaboration avec l'itemm, nous avions fait de l'acquisition audio dans le navigateur. Nous testions la justesse d'instruments à vents et affichions les instruments en 3D dans le navigateur. Je me souviens qu'il fallait utiliser les nightly builds de chrome pour que ça fonctionne. Mais la présentation de l'ircam a montré que l'api Web Audio décollait vraiment. Ils ont fait des démonstrations de mixage en direct et on est passé à deux doigts de faire faire du sound painting à l'assemblée à coups de téléphones portables et websockets. Leur dépôt GitHub vaut le détour ;

    /file/293356/raw
  • RxJS et ses cousins BaconJS et KefirJS permettent d'écrire des traitements de flux d'information assez simplement à partir d'événements, de promesses et de plein d'autres choses.

Et CubicWeb dans tout ça ? Et bien tout ça m'a donné envie de continuer activement le travail entamé sur le javascript utilisé dans CubicWeb. J'aimerais notamment qu'on puisse écrire de l'ES 6, qu'en mode debug, les fichiers soient transpilés à coups de babel (-- watch) et qu'on transpile également à la construction des paquets. On pourrait par la même occasion définir la liste des fonctionnalités "futures" qu'on s'autorise à utiliser dans le cœur de CubicWeb et pour lesquelles CubicWeb fournirait des polyfills si besoin (promesses, fetch, fileAPI, etc.).

Pour conclure, félicitations aux organisateurs pour avoir su trouver une autre salle à la dernière minute et pour la qualité de la journée dans son ensemble. Sans doute à l'an prochain et pour certains d'entre eux à bientôt à WebGL Paris

[rcommande] Papaye 0.2 est arrivé !

Publié le 2015-06-06 22:00:00
Cannes - Firework 2014 (Italia), Ludovick sur Flickr

Ça y est! Après de longs mois d'attente, j'ai enfin pu sortir une nouvelle release de Papaye ! Pour rappel, c'est une application que je développe depuis quelques temps et qui permet d'avoir un dépôt de paquets Python en local tout en faisant également office de proxy et de cache pour le dépôt PyPI officiel.

Autant dire la vérité, ça n'a pas été de la tarte (à la papaye ...). Je suis parti sur une brique logicielle assez exotique (la ZODB en chef de file) ce qui fait qu' au moindre problème, je me sentais bien seul, Google DuckDuckGo n'était pas toujours d'une grande aide. J'ai notamment été confronté à des problèmes de conflits de transactions et de migrations de données.

Les nouveautés

Un petit mot sur les nouveautés:

  • Une interface web afin de naviguer dans les paquets
  • Un nouveau scheduler pour la gestion des tâches en arrière plan
  • Un système de migrations de données basé sur repoze.evolution (un prochain article sur mon retour d'expérience) et inspiré par South / Alembic

L'application arrive également avec son petit lot de pansements :

  • L'arbre de la base de données ne se déteriore plus dans le temps
  • La configuration de webassets ne pose plus de problème en production
  • Le système de proxy/cache possédait de nombreux bugs. Il a été entièrement réécrit
  • Les paquets ayant des espaces dans leur nom sont correctement pris en charge.

L'interface web

La grosse nouveauté c'est donc l'interface qui permet de naviguer dans les paquets. En voici quelques images:

La page d'accueil:

La page d'accueil

La liste des paquets avec un champs de filtrage:

La liste de paquets

Le détail d'un paquet:

La détail d'un paquet

Pour les utilisateurs d'une des versions précédentes de Papaye, il faudra exécuter une commande suplémentaire afin de migrer/nettoyer votre ancienne base de données

papaye_evolve votre_fichier_de_configuration.ini

Papaye vous obligera de toute façon à exécuter cette commande si vous ne le faites pas.

Au passage, je fais tourner une version "demo" ici: http://papaye.rcommande.org/ (demo/demo pour s'identifier)

La suite

Il reste encore un bout de chemin mais je considère cette version comme la première réellement utilisable et reposant sur des bases solides. La prochaine étape, c'est l'enrichissement de l'interface web avec une interface d'administration pour gérer la base de données (opérations de maintenances), purger le cache des paquets, manipuler le dépôt (édition, suppression, ...) et gérer les utilisateurs. Je vais aussi essayer de travailler sur la documentation, qui est pour le moment...inexistante. La faute à mon anglais très aproximatif.

Et surtout n'hésitez pas à me faire le maximum de retours concernant cette version. Ça se passe toujours sur le dépôt Github

Merci également a Foxmask et Ldgeo pour leurs remontées et corrections !

[carlchenet] Liens intéressants Journal Du Pirate semaine #23

Publié le 2015-06-04 22:00:00
Suivez-moi aussi sur Diaspora* ou Twitter  ou sur Identi.ca Pour cette 23ème semaine de 2015, 5 liens intéressants que vous avez peut-être ratés, relayés cette semaine par le Journal Du Pirate, votre source d’informations pour le Logiciel Libre francophone ! Linux : découverte d’un bug sur le système de fichiers EXT4, qui pourrait causer une…

[AFPy Salt-fr] Annonce : Meetup Salt "Table ronde et Comparaison des frameworks" Salt Ansible Chef Puppet

Publié le 2015-06-04 22:00:00

Le meetup de juin est un peu spécial: nous avons invité des personnes pour défendres les "autres" frameworks. Et oui, la communauté nous demande souvent comment Salt se compare à des frameworks comme Puppet, Chef ou Ansible. Avantages, inconvénients, tailles des ecosystèmes, architecture, nous essayerons d'aborder tous les points qui permettent à chaqun de choisir l'application qui convient à son infrastructure et ses processus.

Le meetup aura lieu le jeudi 18 juin 2015 à 19h à l'école 42 au 96 Boulevard Bessières, Paris, métro Porte de Clichy.

École 42

Voici la liste des intervenants :

Intervenants pour défendre chaque framework

Nous avons prévu un certain nombre de sujets et questions à poser aux intervenants, si vous avez des questions brûlantes, faites nous en part sur la liste, sur IRC (#salt-fr sur freenode) ou sur twitter.

Le meetup est gratuit mais il faut s'inscrire (limité à 100 places) sur meetup.com. Inscrivez vous avant qu'il n'y ait plus de places pour ce meetup un peu exceptionnel !

Comme d'habitude, nous aurons de quoi manger et boire pour continuer les discussion après le débat.

[logilab] KanbanDay 2015

Publié le 2015-06-02 19:34:00

Nous étions plusieurs personnes de Logilab à participer au KanbanDay ce jeudi 28 mai 2015 à Paris.

Management Visuel

La présentation que j'ai préféré est 1+9 outils de management visuel de Damien Thouvenin. Le support comme l'orateur étaient clairs et agréables.

Au-delà d'une sorte de catalogue d'outils, j'en retiens que le but du management visuel est de montrer l'écart par rapport à la situation espérée et non de fournir un ensemble d'informations qui permettent de comprendre dans le détail la situation. Le management visuel est un moyen, pour ceux qui produisent, de s'assurer qu'ils restent sur la trajectoire prévue. Les indicateurs mis en place doivent donc être choisis en fonction de l'objectif fixé et de la trajectoire choisie pour l'atteindre. Dans le cas d'une dérive, il sera nécessaire de chercher des explications et d'identifier les problèmes à la racine, mais ce n'est pas le rôle du tableau de bord utilisé au quotidien que de présenter tous les détails du fonctionnement de votre système de production.

Une analogie simple serait que dans votre voiture, le compteur de vitesse vous permet de contrôler le résultat d'une pression sur l'accélérateur ou le frein, mais qu'en cas de problème, il vous faudra ouvrir le capot pour déterminer la panne.

La principale lecture recommandée a été L'usine s'affiche.

/file/293145/raw

Gribouille Académie

Je me suis bien amusé à l'atelier Gribouille académie. Après avoir vu des personnes dessiner des résumés de présentations lors de conférences et avoir été agréablement surpris de découvrir l'efficacité du prototypage papier lors d'une récente formation "Lean UX", j'avais envie d'explorer la prise de note graphique.

S'il est vrai qu'il n'est pas nécessaire de faire une école d'art pour faire des gribouillages, être capable d'obtenir un résultat plaisant en peu de temps demande du travail et de l'entraînement... mais ce n'est pas surprenant, puisque comme le disent nos amis d'outre-océan, il n'y a pas de repas gratuit.

/file/293142/raw

Plénières

Les présentations en séances plénières m'ont donné quelques idées à creuser.

La première idée concerne l'allocation partielle de ressources, qui est bien décrite dans la bibliographie Lean au sujet du taux d'occupation des machines et pourrait se traduire dans le domaine du développement logiciel par l'affectation de 10% à 20% des ressources à "toutes les tâches qui surviendront et pourraient permettre aux autres membres de l'équipe de ne pas rester bloqués ou de ne pas être ralentis". Une des difficultés est de savoir à qui faire payer ce temps dans le cadre de développements au forfait, surtout si la réserve de capacité est partagée entre plusieurs projets.

La deuxième idée est plus difficile à formuler mais pourrait se résumer par "essayer de faire parfaitement une tâche bien définie fait aller moins loin qu'essayer d'aller le plus loin possible". Dans la présentation, le titre était "viser la perfection ou viser l'excellence".

/file/293141/raw

La troisième idée est le rapport entre agilité et enseignement. Je me suis déjà intéressé de près à la pédagogie Montessori et à la classe inversée (dont la Kahn Academy est un exemple. Sachez aussi que le premier congrès français de classe inversée aura lieu début juillet à Paris), j'ai suivi plusieurs cours en ligne (MOOC), donc j'étais en terrain connu quand Christian den Hartig, un professeur de français de collège, a expliqué comment il applique les principes de l'agilité dans sa classe. Nous faisons beaucoup de formation à Logilab et je me demande comment nous pourrions faire évoluer ou diversifier notre offre pour y intégrer ces idées.

Autres ressources

Je connaissais déjà les jeux présentés, mais je note que KanbanZine est une version améliorée de GetKanban. Il en existerait une version libre, mais je ne l'ai pas encore trouvée. Une des qualités de ce jeu quand il est joué à plusieurs équipes qui se concurrencent est de souligner la différence entre estimation de la valeur et estimation de la charge.

Au rayon bouquiniste, j'ai apprécié la lecture du "Guide du chefs de produit", pardon, du "Guide des Product Managers et des Products Owners d'élite" offert par Thiga et j'espère que Christophe Keromen, de CoActiv, pensera à m'envoyer sa bibliographie de Bob l'Eponge.

Conclusion

Merci à l'équipe d'organisation de KanbanDay, je n'ai pas perdu mon temps en y consacrant ma journée du 28 mai 2015.

[afpyro] AFPyro à Lyon - mercredi 27 mai

Publié le 2015-05-27 00:00:00

Un Afpyro aura lieu le mercredi 27 mai à partir de 19h au Gîte Numérique - 6 rue Saint Georges - 69005 Lyon.

Matthieu nous parlera de son éditeur de texte écrit en Python.

Les participants sont invités à ramener des boissons ou de la nourriture à partager.

Pour se rendre au Gîte Numérique :

  • en métro : arrêt Vieux Lyon - Cathédrale Saint Jean
  • en bus : lignes C20 ou 31 arrêt Saint Georges ou Sala
  • en vélo’v : stations Saint Jean / Cathédrale, Place Crépu

[logilab] Running a local salt-master to orchestrate docker containers

Publié le 2015-05-20 14:45:00

In a recent blog post, Denis explained how to build Docker containers using Salt.

What's missing there is how to have a running salt-master dedicated to Docker containers.

There is not need the salt-master run as root for this. A test config of mine looks like:

david@perseus:~$ mkdir -p salt/etc/salt
david@perseus:~$ cd salt
david@perseus:~salt/$ cat << EOF >etc/salt/master
interface: 192.168.127.1
user: david

root_dir: /home/david/salt/
pidfile: var/run/salt-master.pid
pki_dir: etc/salt/pki/master
cachedir: var/cache/salt/master
sock_dir: var/run/salt/master

file_roots:
  base:
    - /home/david/salt/states
    - /home/david/salt/formulas/cubicweb

pillar_roots:
  base:
    - /home/david/salt/pillar
EOF

Here, 192.168.127.1 is the ip of my docker0 bridge. Also note that path in file_roots and pillar_roots configs must be absolute (they are not relative to root_dir, see the salt-master configuration documentation).

Now we can start a salt-master that will be accessible to Docker containers:

david@perseus:~salt/$ /usr/bin/salt-master -c etc/salt

Warning

with salt 2015.5.0, salt-master really wants to execute dmidecode, so add /usr/sbin to the $PATH variable before running the salt-master as non-root user.

From there, you can talk to your test salt master by adding -c ~/salt/etc/salt option to all salt commands. Fortunately, you can also set the SALT_CONFIG_DIR environment variable:

david@perseus:~salt/$ export SALT_CONFIG_DIR=~/salt/etc/salt
david@perseus:~salt/$ salt-key
Accepted Keys:
Denied Keys:
Unaccepted Keys:
Rejected Keys:

Now, you need to have a Docker images with salt-minion already installed, as explained in Denis' blog post. (I prefer using supervisord as PID 1 in my dockers, but that's not important here.)

david@perseus:~salt/ docker run -d --add-host salt:192.168.127.1  logilab/salted_debian:wheezy
53bf7d8db53001557e9ae25f5141cd9f2caf7ad6bcb7c2e3442fcdbb1caf5144
david@perseus:~salt/ docker run -d --name jessie1 --hostname jessie1 --add-host salt:192.168.127.1  logilab/salted_debian:jessie
3da874e58028ff6dcaf3999b29e2563e1bc4d6b1b7f2f0b166f9a8faffc8aa47
david@perseus:~salt/ salt-key
Accepted Keys:
Denied Keys:
Unaccepted Keys:
53bf7d8db530
jessie1
Rejected Keys:
david@perseus:~/salt$ salt-key -y -a 53bf7d8db530
The following keys are going to be accepted:
Unaccepted Keys:
53bf7d8db530
Key for minion 53bf7d8db530 accepted.
david@perseus:~/salt$ salt-key -y -a jessie1
The following keys are going to be accepted:
Unaccepted Keys:
jessie1
Key for minion jessie1 accepted.
david@perseus:~/salt$ salt '*' test.ping
jessie1:
    True
53bf7d8db530:
    True

You can now build Docker images as explained by Denis, or test your sls config files in containers.

[logilab] Building Docker containers using Salt

Publié le 2015-05-13 10:51:00

In this blog post, I'll talk about a way to use Salt to automate the build and configuration of Docker containers. I will not consider the deployment of Docker containers with Salt as this subject is already covered elsewhere (here for instance). The emphasis here is really on building (or configuring) a container for future deployment.

Motivation

Salt is a remote execution framework that can be used for configuration management. It's already widely used at Logilab to manage our infrastructure as well as on a semi-daily basis during our application development activities.

Docker is a tool that helps automating the deployment of applications within Linux containers. It essentially provides a convenient abstraction and a set of utilities for system level virtualization on Linux. Amongst other things, Docker provides container build helpers around the concept of dockerfile.

So, the first question is why would you use Salt to build Docker containers when you already have this dockerfile building tool. My first motivation is to encompass the limitations of the available declarations one could insert in a Dockerfile. First limitation: you can only execute instructions in a sequential manner using a Dockerfile, there's is no possibility of declaring dependencies between instructions or even of making an instruction conditional (apart from using the underlying shell conditional machinery of course). Then, you have only limited possibilities of specializing a Dockerfile. Finally, it's no so easy to apply a configuration step-by-step, for instance during the development of said configuration.

That's enough for an introduction to lay down the underlying motivation of this post. Let's move on to more practical things!

A Dockerfile for the base image

Before jumping into the usage of Salt for the configuration of a Docker image, the first thing you need to do is to build a Docker container into a proper Salt minion.

Assuming we're building on top of some a base image of Debian flavour subsequently referred to as <debian> (I won't tell you where it comes from, since you ought to build your own base image -- or find some friend you trust to provide you with one!), the following Dockerfile can be used to initialize a working image which will serve as the starting point for further configuration with Salt:

FROM <debian>
RUN apt-get update
RUN apt-get install -y salt-minion

Then, run docker build . docker_salt/debian_salt_minion and you're done.

Plugin the minion container with the Salt master

The next thing to do with our fresh Debian+salt-minion image is to turn it into a container running salt-minion, waiting for the Salt master to instruct it.

docker run --add-host=salt:10.1.1.1 --hostname docker_minion \
    --name minion_container \
    docker_salt/debian/salt_minion salt-minion

Here:

  • --hostname is used to specify the network name of the container, for easier query by the Salt master,
  • 10.1.1.1 is usually the IP address of the host, which in our example will serve as the Salt master,
  • --name is just used for easier book-keeping.

Finally,

salt-key -a docker_minion

will register the new minion's key into the master's keyring.

If all went well, the following command should succeed:

salt 'docker_minion' test.ping

Configuring the container with a Salt formula

salt 'docker_minion' state.sls some_formula
salt 'docker_minion' state.highstate

Final steps: save the configured image and build a runnable image

(Optional step, cleanup salt-minion installation.)

Make a snapshot image of your configured container.

docker stop minion_container
docker commit -m 'Install something with Salt' \
    minion_container me/something

Try out your new image:

docker run -p 8080:80 me/something <entry point>

where <entry point> will be the main program driving the service provided by the container (typically defined through the Salt formula).

Make a fully configured image for you service:

FROM me/something
[...anything else you need, such as EXPOSE, etc...]
CMD <entry point>

[sciunto] Don du mois : grammalecte

Publié le 2015-05-02 22:00:00

Ce post s'inscrit dans la série des dons pour vous donner envie de contribuer même très modestement à des logiciels libres. Les petites pierres font les grands édifices (ex de pratiques similaires : 1, 2).

Ce mois-ci, j'ai choisi de donner à grammalecte, une campagne de financement pour un correcteur grammatical. Le montant de ce don est de 5€. Les raisons de ce soutien :

  • développement d'un logiciel libre (comme spécifié ici.
  • utilité grand public évidente
  • fonction serveur qui offira la possibilité d'interfacer avec n'importe quel logiciel et language (latex, markdown...).
  • greffons firefox et thunderbird qui rendront la solution populaire (donc retour d'expérience, donc amélioration à long terme)

Pour donner à grammalecte.

[logilab] Mini-Debconf Lyon 2015

Publié le 2015-04-29 16:52:00
//www.logilab.org/file/291628/raw/debian-france.png

A couple of weeks ago I attended the mini-DebConf organized by Debian France in Lyon.

It was a really nice week-end, and the first time a French mini-DebConf wasn't in Paris :)

Among the highlights, Juliette Belin reported on her experience as a new contributor to Debian: she authored the awesome "Lines" theme which was selected as the default theme for Debian 8.

//www.logilab.org/file/291626/raw/juliette.jpg

As a non-developer and newcomer to the free software community, she had quite intesting insights and ideas about areas where development processes need to improve.

And Raphael Geissert reported on the new httpredir.debian.org service (previously http.debian.net), an http redirector to automagically pick the closest Debian archive mirror. So long, manual sources.list updates on laptops whenever travelling!

//www.logilab.org/file/291627/raw/raphael.jpg

Finally the mini-DebConf was a nice opportunity to celebrate the release of Debian 8, two weeks in advance.

Now it's time to go and upgrade all our infrastructure to jessie.

[cubicweb] Serving Cubicweb via WSGI with Pyramid: comparing the options

Publié le 2015-04-24 18:15:00

CubicWeb can now be powered by Pyramid (thank you so much Christophe) instead of Twisted.

I aim at moving all our applications to CubicWeb/Pyramid, so I wonder what will be the best way to deliver them. For now, we have a setup made of Apache + Varnish + Cubicweb/Twisted. In some applications we have two CubicWeb instances with a naive load balacing managed by Varnish.

When moving to cubicweb-pyramid, there are several options. By default, a cubicweb-pyramid instance started via the cubicweb-ctl pyramid command, is running a waitress wsgi http server. I read it is common to deliver wsgi applications with nginx + uwsgi, but I wanted to play with mongrel2 (that I already tested with Cubicweb a while ago), and give a try to the circus + chaussette stack.

I ran my tests :

  • using ab the simple Apache benchmark tool (aka ApacheBench) ;
  • on a clone of our logilab.org forge ;
  • on my laptop (Intel Core i7, 2.67GHz, quad core, 8Go),
  • using a postgresql 9.1 database server.

Setup

In order to be able to start the application as a wsgi app, a small python script is required. I extracted a small part of the cubicweb-pyramid ccplugin.py file into a elo.py file for this:

appid = 'elo2'

cwconfig = cwcfg.config_for(appid)
application = wsgi_application_from_cwconfig(cwconfig)
repo = cwconfig.repository()
repo.start_looping_tasks()

I tested 5 configurations: twisted, pyramid, mongrel2+wsgid, uwsgi and circus+chaussette. When possible, they were tested with 1 worker and 4 workers.

Legacy Twisted mode

Using good old legacy twisted setup:

cubicwebctl start -D -l info elo

The config setting that worth noting are:

webserver-threadpool-size=6
connections-pool-size=6

Basic Pyramid mode

Using the pyramid command that uses waitress:

cubicwebctl pyramid --no-daemon -l info elo

Mongrel2 + wsgid

I have not been able to use uwsgi-mongrel2 as wsgi backend for mongrel2, since this uwsgi plugin is not provided by the uwsgi debian packages. I've used wsgid instead (sadly, the project appears to be dead).

The mongrel config is:

main = Server(
   uuid="f400bf85-4538-4f7a-8908-67e313d515c2",
   access_log="/logs/access.log",
   error_log="/logs/error.log",
   chroot="./",
   default_host="localhost",
   name="test",
   pid_file="/pid/mongrel2.pid",
   bind_addr="0.0.0.0",
   port=8083,
   hosts = [
       Host(name="localhost",
            routes={'/': Handler(send_spec='tcp://127.0.0.1:5000',
                                 send_ident='2113523d-f5ff-4571-b8da-8bddd3587475',
                                 recv_spec='tcp://127.0.0.1:5001',
                                 recv_ident='')
                   })
           ]
   )

servers = [main]

and the wsgid server is started with:

wsgid --recv tcp://127.0.0.1:5000 --send tcp://127.0.0.1:5001 --keep-alive \
--workers <N> --wsgi-app elo.application --app-path .

uwsgi

The config file used to start uwsgi is:

[uwsgi]
stats = 127.0.0.1:9191
processes = <N>
wsgi-file = elo.py
http = :8085
plugin = http,python
virtualenv = /home/david/hg/grshells/venv/jpl
enable-threads = true
lazy-apps = true

The tricky config option there is lazy-apps which must be set, otherwise the worker processes are forked after loading the cubicweb application, which this later does not support. If you omit this, only one worker will get the requests.

circus + chaussette

For the circus setup, I have used this configuration file:

[circus]
check_delay = 5
endpoint = tcp://127.0.0.1:5555
pubsub_endpoint = tcp://127.0.0.1:5556
stats_endpoint = tcp://127.0.0.1:5557
statsd = True
httpd = True
httpd_host = localhost
httpd_port = 8086

[watcher:webworker]
cmd = /home/david/hg/grshells/venv/jpl/bin/chaussette --fd $(circus.sockets.webapp) elo2.app
use_sockets = True
numprocesses = 4

[env:webworker]
PATH=/home/david/hg/grshells/venv/jpl/bin:/usr/local/bin:/usr/bin:/bin
CW_INSTANCES_DIR=/home/david/hg/grshells/grshell-jpl/etc
PYTHONPATH=/home/david/hg/grshells//grshell-jpl

[socket:webapp]
host = 127.0.0.1
port = 8085

Results

The bench are very simple; 100 requests from 1 worker or 500 requests from 5 concurrent workers, getting the main index page for the application:

One ab worker

ab -n 100 -c 1 http://127.0.0.1:8085/

We get:

Synthesis (1 client)

Response times are:

Response time (1 client)

Five ab workers

ab -n 500 -c 5 http://127.0.0.1:8085/

We get:

Synthesis (5 clients)

Response times are:

Response time (5 clients)

Conclusion

As expected, the legacy (and still default) twisted-based server is the least efficient method to serve a cubicweb application.

When comparing results with only one CubicWeb worker, the pyramid+waitress solution that comes with cubicweb-pyramid is the most efficient, but mongrel2 + wsgid and circus + chaussette solutions mostly have similar performances when only one worker is activated. Surprisingly, the uwsgi solution is significantly less efficient, and especially have some requests that take significantly longer than other solutions (even the legacy twisted-based server).

The price for activating several workers is small (around 3%) but significant when only one client is requesting the application. It is still unclear why.

When there are severel workers requesting the application, it's not a surpsise that solutions with 4 workers behave significanly better (we are still far from a linear response however, roughly a 2x better for 4x the horsepower; maybe the hardware is the main reason for this unexpected non-linear response).

I am quite surprised that uwsgi behaved significantly worse than the 2 other scalable solutions.

Mongrel2 is still very efficient, but sadly the wsgid server I've used for these tests has not been developed for 2 years, and the uwsgi plugin for mongrel2 is not yet available on Debian.

On the other side, I am very pleasantly surprised by circus + chaussette. Circus also comes with some nice features like a nice web dashboard which allows to add or remove workers dynamically:

//www.cubicweb.org/file/5272071/raw//www.cubicweb.org/file/5272077/raw

[afpyro] AFPyro à Lyon - mercredi 22 avril

Publié le 2015-04-22 00:00:00

Un Afpyro aura lieu le mercredi 22 avril à partir de 19h au Gîte Numérique - 6 rue Saint Georges - 69005 Lyon.

Balthazar nous emmène en balade coté backend et nous propose une visite guidée des différents types d’outils communément rencontrés dans le backend d’une application web Python (application et serveur WSGI, serveur web, base de données relationnelles et NoSQL, moteur de recherche, moteur de cache, tâches de fonds, etc...).

Les participants sont invités à ramener des boissons ou de la nourriture à partager.

Pour se rendre au Gîte Numérique :

  • en métro : arrêt Vieux Lyon - Cathédrale Saint Jean
  • en bus : lignes C20 ou 31 arrêt Saint Georges ou Sala
  • en vélo’v : stations Saint Jean / Cathédrale, Place Crépu

Autres liens :

[AFPy Salt-fr] Compte rendu Salt Meetup Paris - avril 2015

Publié le 2015-04-15 22:00:00

Une petite trentaine de membres de la communauté Salt parisienne a été accueilli dans les nouveaux locaux de Tinyclues pour ce meetup. Merci également à Logilab qui a sponsorisé la nourriture.

Nicolas Chauvat PDG de Logilab a annoncé son partenariat avec SaltStack pour assurer la formation, le support et la certification sur Salt en France et en Europe.

Voici un compte rendu rapide des trois présentations de cette soirée.

Interface Web SaltStack Enterprise

Rob Hilberding de SaltStack Inc. qui était à Paris pour plusieurs jours est venu présenter une "pure preview" ce que sera potentiellement l'interface web de la version Enterprise de SaltStack.

Rob de SaltStack

Il a présenté l'interface qu'ils développent, cette dernière s'appuie sur l'API SaltStack et MariaDB ou MySQL. À noter que cette interface n'est qu'une extension, à savoir que la version SalStack Enterprise (master et minion) est basée sur le même code que la version communautaire.

L'interface supporte le multi-master, elle liste les minions et pour chaque minion : elle permet d'avoir l'ensemble de ces grains, le statut de sa connexion et des informations sur les derniers jobs.

La liste des minions pouvant être longue il y a la possibilité de filtrer soit par une correspondance sur une partie de l'ID des minions soit sur la valeur d'un ou plusieurs grains. Un filtre peut permettre la création de groupe de minions, c'est également possible via un wizard dédié. Les groupes créés peuvent être partagés (publics) ou privés. Pour les minions sélectionnés il est possible de lancer un job (depuis une liste). Ainsi cette interface permet à des utilisateurs ne connaissant pas de manière poussé Salt de lancer des actions (job) sur des machines (minions) pour lesquelles ils ont les droits.

Comparaison avec Ansible

Paul Tonelli de Heuritech a présenté les différences entre Ansible et SaltStack qu'il a pu appréhender après une semaine d'utilisation d'Ansible.

  • Ansible utilise SSH pour les communications et donc c'est le serveur qui se connecte aux clients ce qui peut impliquer de paramétrer ssh avec des proxies, le cas typique est l'accès aux serveurs qui sont derrière un HAProxy en mode transparent.
  • Ansible n'a pas de serveur (daemon) qui tourne en continu comme SaltStack, mis à part Tower qui est payant.
  • Tower est une interface Web, qui au delà du fait d'être une GUI, peut offrir des fonctionnalités proches du reactor de Salt.
  • L'approche d'Ansible est d'avoir un playbook par projet alors que Salt a une arborescence pour l'ensemble.
  • Ansible peut cibler un peu comme Salt mais sur des noms de machines et faire des groupes de machines en les déclarant dans un fichier, les wilcards peuvent être utilisés.
  • La gestion des dépendances est simple, il faut que cela soit déclaré avant/au dessus. La conclusion est que Ansible a une approche plus minimaliste et la configuration est plus statique.

Retour d'experience

Joe Bounour de DDN a présenté l'utilisation de Salt dans le cadre du déploiement et maintient des produits de DDN de stockage (type Big data et Object storage). Les produits de DDN déploient des paquets RPMs et produisent une configuration de clusters qui va pousser sur l'ensemble des nœuds (via SSH) les masters et les minions pour déployer toute la stack de cluster management (ZooKeeper, HBase, Hadoop, memcached, etc) afin de surveiller et orchestrer les noeuds. À noter que l’environnement déployé est multi-master, composé au plus de 2 ou 3 masters afin de garantir un service haute disponibilité. DDN a développé un ensemble d'outils (*ctl) qui forment une couche d'abstraction à SaltStack afin de gérer un cluster de nœuds pour des solutions de stockage. Salt est masqué pour le client qui n'a pas besoin de le maîtriser. Salt a été choisi pour sa rapidité, sa parallélisation, sa consistance et son mode multi-master (actif-actif).

Nous avons poursuivi les discussions autour de petits bagels offerts par Logilab.

bagels et companie

[AFPy-Nantes] Le meetup du 28 avril sera un barcamp

Publié le 2015-04-11 22:00:00

La prochaine rencontre Python Nantes sera au format BarCamp et se déroulera le mardi 28 avril, à la Cantine de Nantes.

L'idée est simplement de se retrouver et de décider sur place des sujets de discussions qui vous intéressent, de les aborder ensemble en différents groupes, puis de mettre en commun ce qui s'est dit pendant les ateliers.

Comme toujours ce meetup est ouvert à tous les amoureux ou curieux du langage Python, nous apprécions particulièrement la diversité des profils qui joignent à nous !

Ceux qui ont envie pourront prolonger la soirée autour d'un verre en centre ville de Nantes.

Si vous avez des questions ou des remarques concernant nos meetups, rejoignez-nous sur le chan IRC de l'AFPy Nantes ou inscrivez vous sur la liste de diffusion . Vous pouvez aussi nous suivre sur Twitter via notre compte @PythonNantes :)

À bientôt !

[AFPy Salt-fr] Annonce : Meetup Salt Paris chez tinyclues - avril 2015

Publié le 2015-04-08 22:00:00

Le meetup d'avril aura lieu dans les locaux de tinyclues au 1 rue du mail 75002, Paris, métro Bourse. Jeudi 16 avril à 19h.

tinyclues

Programme :

  • L'utilisation de la nouvelle feature de chiffrage dans la 2014.7 par Ronan Amicel (Pocket Sensei)
  • Présentation et utilisation de la Salt Mine par Damien DESMARETS (Weborama)
  • Productizing and shipping Salt as a Private Cloud par Samuel Phan (DDN)

Le meetup est gratuit mais il faut s'inscrire (limité à 50 places) sur meetup.com.


View Larger Map

[logilab] Retour sur la journée conteneurs dans le cadre de Open Source Innovation Spring

Publié le 2015-04-07 12:41:00

Logilab a co-organisé la demi-journée sur les conteneurs dans le cadre du Printemps de l'innovation open source (Open Source Innovation Spring). Voici une partie des choses qui y furent dites.

Open Source Innovation Spring

AlterWay a commencé par une introduction expliquant pourquoi docker est si hype en ce moment. Quelques bémols ont été placés sur les questions de sécurité et les systèmes de fichiers utilisés par défaut (AUFS n'est pas dans le kernel linux officiel, des alternatives sont à l'étude).

Une partie de l'écosystème autour de Docker a été mentionné :

Ensuite Normation a présenté la gestion de configuration et Docker, avec de grandes questions générales sur le déploiement de serveurs, leur durée de vie, leur transformation, etc.

Logilab & Mozilla

Logilab a présenté l'utilisation conjointe de Salt Mercurial et Docker pour appliquer les bonnes pratiques du développement logiciel à la gestion d'infrastructures. Les supports de présentation sont sur http://slides.logilab.fr/osis/osis (aussi sur slideshare).

Normation a ensuite présenté les fondements techniques des conteneurs, à savoir les fonctionnalités du noyau linux qui ont permis leur essor. Petit historique sur les cgroups, avec les idées d'origine sur les processus dans Unix, mais aussi les bonnes idées apportées par Plan 9 (et qui ont ensuite été reprises par Linux). On a vu des choses sur les chroots, les namespaces, fakeroot, ip netns, les informations dans /proc/<pid>/ns, et les systèmes de fichier d'union utilisé par les conteneurs : aufs, unionfs, overlayfs, fuse.

Intervenants de la journée

Ensuite deux démonstrations ont été présentées :

  • Utilisation de docker et docker-swarm sur amazon ec2 pour déployer une application html5 : CircleCI lit le dépôt git de l'application, construit l'image Docker et l'ajoute au hub puis pilote docker-swarm pour qu'elle soit déployée.
  • Utilisation de plusieurs plate-formes de cloud (Azure, Numergy, CloudWatt) pour déployer un conteneur docker sur plusieurs clouds en parallèle.

Deux retours d'expérience par Theodo et Deliverous ont conclu la journée.

[afpyro] AFPyro à Lyon - mercredi 25 mars

Publié le 2015-03-25 00:00:00

Un Afpyro aura lieu le mercredi 25 mars à partir de 19h au Gîte Numérique - 6 rue Saint Georges - 69005 Lyon.

Une présentation sur apetizer sera donnée par son auteur, et hôte de l’AFPyro, Nicolas Danjean. Apetizer est une librairie pour Django permettant de simplifier la création de vues, APIs, et notamment dans le cadre de création de wizards.

Pour se rendre au Gîte Numérique :

  • en métro : arrêt Vieux Lyon - Cathédrale Saint Jean
  • en bus : lignes C20 ou 31 arrêt Saint Georges ou Sala
  • en vélo’v : stations Saint Jean / Cathédrale, Place Crépu

[sciunto] Don du mois : ipython et jupyter

Publié le 2015-03-19 23:00:00

Ce post s'inscrit dans la série des dons pour vous donner envie de contribuer même très modestement à des logiciels libres. Les petites pierres font les grands édifices.

C'est au tour de Ipython, une interface de type console et web pour python et d'autres langages. Le montant de ce don est de $6. Les raisons de ce soutien :

  • Je l'utilise au quotidien avec Python, notamment pour les notebooks qui me facilite l'analyse et la visualisation de données. Ca a grandement amélioré mon travail.
  • Ipython donne une réelle valeur ajoutée à python par une approche complémentaire pour résoudre un problème. En effet, je n'effectue pas un traitement d'images comme l'écriture d'une bibliothèque logicielle.
  • Ipython a annoncé qu'il allait se découper en deux avec Jupyter, car Ipython gère aussi d'autres langages comme perl ou ruby. C'est donc un projet de très grande ampleur et qui a un fort potentiel.
  • Plusieurs financements viennent aider le développement, ce qui permet d'avoir 6 développeurs à plein temps.
  • L'intégration dans un navigateur en fait une solution facilement auto-hébergeable.

Pour donner à Ipython/Jupyter.

[afpyro] Afpy à Pau le Mercerdi 18 Mars

Publié le 2015-03-18 00:00:00

Un afpyro aura lieu à Pau le 18 Mars à 20h30.

Cela se tiendra au fablab MIPS 4 rue Despourrins au premier étage. (Il faut sonner à l’interphone)

On abordera les générateurs en Python et on causera librement de différents sujets autour de python.

Voir la map

[logilab] De retour du raid agile

Publié le 2015-03-17 12:45:00
https://www.logilab.org/file/288474?vid=download

J'ai eu la semaine dernière la chance de participer au raid agile organisé par Pablo et Claudio. Je dis bien une chance car, de mon point de vue, cette formation atypique donne vraiment l'occasion de passer quelques jours loin du quotidienn dans un cadre idyllique et une ambiance sympathique, à réfléchir aux fondements des méthodes agiles. En plus d'y (re)découvrir un tas d'outils et de jeux agiles, c'est l'occasion d'échanger avec tous les participants et de remettre en cause ses pratiques. Bref, une bonne remise à zéro des compteurs. Je ne vous révélerais pas plus l'emploi du temps minuté-mais-aéré des trois jours (vous en saurez plus sur le site), je ne saurais que vous recommander de sauter sur l'occasion de partiper à une prochaine édition du raid !

Ceci étant dit, revenons-en à l'objet principal de ce billet : ce que j'ai ramené dans ma petite tête pour améliorer nos pratiques à Logilab. Ou en tout cas celle que j'essaie de mettre en place avec mon équipe à Toulouse.

Une de mes principales problématiques est la suivante : comment adapter une méthode comme Scrum ou un outil comme le kanban dans le cadre d'une petite société de service, où nous avons majoritairement des petits projets, plusieurs en parallèle, développés par une à deux personnes maximum ? La littérature sur le sujet applique systématiquement (à ma connaissance) la méthode à des équipes de développement "produit" avec des phases souvent gérées par des personnes différentes (développeurs, testeurs, intégrateurs, etc.). Ça fait un moment que je tâtonne sur le sujet, d'une manière parfois satisfaisante, parfois frustrante, mais certainement améliorable. Sans prétendre avoir répondu à toutes mes interrogations, une réflexion de Claude m'a donné envie d'améliorer un point en particulier : travailler en équipe, plutôt qu'être une somme d'individus dans un même espace. Le principal changement à conduire consistera donc à faire travailler tous les membres de l'équipe sur tous les projets. Il y aura bien sûr un coût non-négligeable dans la mise en place de chacun sur chaque projet, mais j'espère que cela sera contrebalancé par :

  • la montée en compétence de l'ensemble de l'équipe ("essaimage")
  • moins de spécialisation individuelle, plus de souplesse dans la gestion des projets
  • un renforcement de l'esprit d'équipe

Pour moi, ça vaut donc le coup de tenter ! Et le compagnon de ce changement sera un autre point qui me pose souvent question : le découpage des besoins du client en user stories (voir features ou epics) et tâches, leur relation avec le kanban qu'on essaie de mettre en place (principalement pour visualiser les tâches de chacun jusqu'ici) et notre extranet de gestion de projet. Jusqu'ici, nous dupliquions plus ou moins l'information, sans vraiment faire ressortir la notion de tâche autrement que dans les discussions informelles. Pour maintenir un rapport coût de gestion / besoin de collaboration et d'indicateurs, on va maintenant essayer de maintenir les histoires dans l'extranet, avec leur estimation, les discussions avec le client et autres (dépendance, relation aux features, etc.), tout en ayant sur le kanban les tâches qui en découlent. Ceci devrait notamment permettre de mieux échanger sur les implémentations des différentes histoires en amont, voire de permettre à plusieurs personnes de travailler sur la même histoire. Et ainsi de rendre le kanban plus au centre de notre gestion quotidienne en diminuant sa granularité.

Ces deux points sont les gros morceaux qu'il va falloir digérer dans les prochains mois. Parmi les autres points abordés ou évoqués pendant la formation et ramenés en stock, il y a :

  • faire un delegation board avec l'équipe à Toulouse et peut-être aussi à l'échelle de Logilab entre les équipes de direction et de développement, voire au sein de l'équipe de direction ;
  • ne pas oublier de faire fixer l'heure sur l'horloge de Cohn à nos clients qui jouent le jeu de l'agilité (ils ne seront jamais assez nombreux) ;
  • faire plus de rétrospectives, sans hésiter à en essayer différentes formes ;
  • à l'occasion, réessayer un impact mapping, l'exercice le plus délicat que nous ayons abordé ;
  • rappeler que si on fait des journées "compactes" à Toulouse, il ne faut pas oublier de maintenir un rythme soutenable. Voir acheter un canapé ou un siège confortable pour les amateurs de power nap (merci Pierre-Jean dont la pratique décomplexée est rafraichissante !) ;
  • enfin creuser les core protocols et le business value game dès que possible, voire réfléchir au #noSlides pour nos formations techniques.

Voilà, y a encore d'autres restes parmi les outils et idées discutés, mais je pense avoir cité ici l'essentiel et ça promet déja des impacts non négligeables. J'accueillerais avec plaisir vos remarques ou idées sur les points ci-dessus. Et avec un peu de chance j'aurais même le courage de faire un billet pour raconter ces différentes expériences ! En tout cas, encore un grand merci à Pablo et Claudio ainsi qu'à tous les participants de ce raid du changement.

[logilab] Monitoring our websites before we deploy them using Salt

Publié le 2015-03-11 18:23:00

As you might have noticed we're quite big fans of Salt. One of the things that Salt enables us to do, it to apply what we're used to doing with code to our infrastructure. Let's look at TDD (Test Driven Development).

Write the test first, make it fail, implement the code, test goes green, you're done.

Apply the same thing to infrastructure and you get TDI (Test Driven Infrastructure).

So before you deploy a service, you make sure that your supervision (shinken, nagios, incinga, salt based monitoring, etc.) is doing the correct test, you deploy and then your supervision goes green.

Let's take a look at website supervision. At Logilab we weren't too satisfied with how our shinken/http_check were working so we started using uptime (nodejs + mongodb). Uptime has a simple REST API to get and add checks, so we wrote a salt execution module and a states module for it.

https://www.logilab.org/file/288174/raw/68747470733a2f2f7261772e6769746875622e636f6d2f667a616e696e6f74746f2f757074696d652f646f776e6c6f6164732f636865636b5f64657461696c732e706e67.png

For the sites that use the apache-formula we simply loop on the domains declared in the pillars to add checks :

{% for domain in salt['pillar.get']('apache:sites').keys() %}
uptime {{ domain }} (http):
  uptime.monitored:
    - name : http://{{ domain }}
{% endfor %}

For other URLs (specific URL such as sitemaps) we can list them in pillars and do :

{% for url in salt['pillar.get']('uptime:urls') %}
uptime {{ url }}:
  uptime.monitored:
    - name : {{ url }}
{% endfor %}

That's it. Monitoring comes before deployment.

We've also contributed a formula for deploying uptime.

Follow us if you are interested in Test Driven Infrastructure for we intend to write regular reports as we make progress exploring this new domain.

[cubicweb] CubicWeb Roadmap meeting on March 5th 2015

Publié le 2015-03-11 12:30:00

The Logilab team holds a roadmap meeting every two months to plan its CubicWeb development effort. The previous roadmap meeting was in January 2015.

Christophe de Vienne (Unlish) and Aurélien Campéas (self-employed) joined us.

Christophe de Vienne asked for discussions on:

  • Security Context: settle on an approach, and make it happen.
  • Pyramid Cubicweb adoption: where are we? what authentication stack do we want by default?
  • Package layout (aka "develop mode" friendliness): let's get real
  • Documentation: is the restructuration attempt (https://www.cubicweb.org/ticket/4832808) a credible path for the documentation?

Aurélien Campéas asked for discussions on:

  • status of integration in the 3.21 branch
  • a new API for cubicweb stores

Sylvain Thénault asked for discussions on:

  • a new API for dataimport (including cubicweb stores, but not only),
  • new integrators on CW

Versions

Cubicweb

Version 3.18

This version is stable but old and maintained (current is 3.18.8).

Version 3.19

This version is stable and maintained (current is 3.19.9).

Version 3.20

This version is now stable and maintained (current is 3.20.4).

Version 3.21

See below

Agenda

Next roadmap meeting will be held at the beginning of may 2015 at Logilab. Interested parties are invited to get in touch.

Open Discussions

New integrators

Rémi Cardona (rcardona) and Denis Laxaldle (dlaxalde) have now the publish access level on Cubicweb repositories.

Security context

Christophe exposed his proposal for a "security context" in Cubicweb, as exposed in https://lists.cubicweb.org/pipermail/cubicweb/2015-February/002278.html and https://lists.cubicweb.org/pipermail/cubicweb/2015-February/002297.html with a proposition of implementation (see https://www.cubicweb.org/ticket/4919855 )

The idea has been validated based on a substitution variables, which names will start with "ctx:" (the RQL grammar will have to be modified to accept a ":")

This will then allow to write RQL queries like (API still to be tuned):

X owned_by U, U eid %(ctx:cwuser_eid)s

Pyramid

The pyramid-based web server proposed by Christophe and used for its unlish website is still under test and evaluation at Logilab. There are missing features (implemented in cubes) required to be able to deploy pyramid-cubicweb for most of the applications used at Logilab, especially cubicweb-signedrequest

In order to make it possible to implement authentication cubes like cubicweb-signedrequest, the pyramid-cubicweb requires some modifications. These has been developped and are about to be published, along with a new version of signedrequest that provide pyramid compatibility.

There are still some dependencies that lack a proper Debian package, but that should be done in the next few weeks.

In order to properly identify pyramid-related code in a cube, it has been proposed that these code should go in modules in the cube named pviews and pconfig (note that most cube won't require any pyramid specific code). The includeme function should however be in the cube's main packgage (in the __init__.py file)

There have been some discussions about the fact that, for now, a pyramid-cubicweb instance requires an anonymous user/access, which can also be a problem for some application.

Layout

Christophe pointed the fact that the directory/files layout of cubicweb and cubes do not follow current Python's de facto standards, which makes cubicweb hard to use in a context of virtualenv/pip based installation. There is the CWEP004 discussing some aspects of this problem.

The decision has been taken to move toward a Cubicweb ecosystem that is more pip-friendly. This will be done step by step, starting with the dependencies (packages currently living in the logilab "namespace").

Then we will investigate the feasibility of migrating the layout of Cubicweb itself.

Documentation

The new documentation structure has been approved.

It has been proposed (and more or less accepted) to extract the documentation in a dedicated project. This is not a priority, however.

Roadmap for 3.21

No change since last meeting:

  • the complete removal of the dbapi, the merging of Connection and ClientConnection. remains
  • Integrate the pyramid cube to provide the pyramid command if the pyramid framework can be imported: removed (too soon, pyramid-cubicweb's APIs are not stable enough)
  • Integration of CWEP-003 (FROM clause for RQL): removed (will probably never be included unless someone needs it)
  • CWEP-004 (cubes as standard python packages) is being discussed: removed (not for 3.21, see above)

dataimports et stores

A heavy refactoring is under way that concerns data import in CubicWeb. The main goal is to design a single API to be used by the various cubes that accelerate the insertion of data (dataio, massiveimport, fastimport, etc) as well as the internal CWSource and its data feeds.

For details, see the thread on the mailing-list and the patches arriving in the review pipeline.

[logilab] A report on the Salt Sprint 2015 in Paris

Publié le 2015-03-06 16:33:00

On Wednesday the 4th of march 2015, Logilab hosted a sprint on salt on the same day as the sprint at SaltConf15. 7 people joined in and hacked on salt for a few hours. We collaboratively chose some subjects on a pad which is still available.

//www.logilab.org/file/248336/raw/Salt-Logo.png

We started off by familiarising those who had never used them to using tests in salt. Some of us tried to run the tests via tox which didn't work any more, a fix was found and will be submitted to the project.

We organised in teams.

Boris & Julien looked at the authorisation code and wrote a few issues (minion enumeration, acl documentation). On saltpad (client side) they modified the targeting to adapt to the permissions that the salt-api sends back.

We discussed the salt permission model (external_auth) : where should the filter happen ? the master ? should the minion receive information about authorisation and not execute what is being asked for ? Boris will summarise some of the discussion about authorisations in a new issue.

//www.logilab.org/file/288010/raw/IMG_3034.JPG

Sofian worked on some unification on execution modules (refresh_db which will be ignored for the modules that don't understand that). He will submit a pull request in the next few days.

Georges & Paul added some tests to hg_pillar, the test creates a mercurial repository, adds a top.sls and a file and checks that they are visible. Here is the diff. They had some problems while debugging the tests.

David & Arthur implemented the execution module for managing postgresql clusters (create, list, exists, remove) in debian. A pull request was submitted by the end of the day. A state module should follow shortly. On the way we removed some dead code in the postgres module.

All in all, we had some interesting discussions about salt, it's architecture, shared tips about developing and using it and managed to get some code done. Thanks to all for participating and hopefully we'll sprint again soon...