Blog entries

SaltStack Paris Meetup - some of what was said

2013/10/09 by Arthur Lutz

Last week, on the first day of OpenWorldForum 2013, we met up with Thomas Hatch of SaltStack to have a talk about salt. He was in Paris to give two talks the following day (1 & 2), and it was a great opportunity to meet him and physically meet part of the French Salt community. Since Logilab hosted the Great Salt Sprint in Paris, we offered to co-organise the meetup at OpenWorldForum.

http://saltstack.com/images/SaltStack-Logo.pnghttp://openworldforum.org/static/pictures/Calque1.png

Introduction

About 15 people gathered in Montrouge (near Paris) and we all took turns to present ourselves and how or why we used salt. Some people wanted to migrate from BCFG2 to salt. Some people told the story of working a month with CFEngine and meeting the same functionnality in two days with salt and so decided to go for that instead. Some like salt because they can hack its python code. Some use salt to provision pre-defined AMI images for the clouds (salt-ami-cloud-builder). Some chose salt over Ansible. Some want to use salt to pilot temporary computation clusters in the cloud (sort of like what StarCluster does with boto and ssh).

When Paul from Logilab introduced salt-ami-cloud-builder, Thomas Hatch said that some work is being done to go all the way : build an image from scratch from a state definition. On the question of Debian packaging, some efforts could be done to have salt into wheezy-backports. Julien Cristau from Logilab who is a debian developer might help with that.

Some untold stories where shared : some companies that replaced puppet by salt, some companies use salt to control an HPC cluster, some companies use salt to pilot their existing puppet system.

We had some discussions around salt-cloud, which will probably be merged into salt at some point. One idea for salt-cloud was raised : have a way of defining a "minimum" type of configuration which translates into the profiles according to which provider is used (an issue should be added shortly). The expression "pushing states" was often used, it is probably a good way of looking a the combination of using salt-cloud and the masterless mode available with salt-ssh. salt-cloud controls an existing cloud, but Thomas Hatch points to the fact that with salt-virt, salt is becoming a cloud controller itself, more on that soon.

Mixing pillar definition between 'public' and 'private' definitions can be tricky. Some solutions exist with multiple gitfs (or mercurial) external pillar definitions, but more use cases will drive more flexible functionalities in the future.

http://openworldforum.org/en/speakers/112/photo?s=220

Presentation and live demo

For those in the audience that were not (yet) users of salt, Thomas went back to explaining a few basics about it. Salt should be seen as a "toolkit to solve problems in a infrastructure" says Thomas Hatch. Why is it fast ? It is completely asynchronous and event driven.

He gave a quick presentation about the new salt-ssh which was introduced in 0.17, which allows the application of salt recipes to machines that don't have a minion connected to the master.

The peer communication can be used so as to add a condition for a state on the presence of service on a different minion.

While doing demos or even hacking on salt, one can use salt/test/minionswarm.py which makes fake minions, not everyone has hundreds of servers in at their fingertips.

Smart modules are loaded dynamically, for example, the git module that gets loaded if a state installs git and then in the same highstate uses the git modules.

Thomas explained the difference between grains and pillars : grains is data about a minion that lives on the minion, pillar is data about the minion that lives on the master. When handling grains, the grains.setval can be useful (it writes in /etc/salt/grains as yaml, so you can edit it separately). If a minion is not reachable one can obtain its grains information by replacing test=True by cache=True.

Thomas shortly presented saltstack-formulas : people want to "program" their states, and formulas answer this need, some of the jinja2 is overly complicated to make them flexible and programmable.

While talking about the unified package commands (a salt command often has various backends according to what system runs the minion), for example salt-call --local pkg.install vim, Thomas told this funny story : ironically, salt was nominated for "best package manager" at some linux magazine competition. (so you don't have to learn how to use FreeBSD packaging tools).

While hacking salt, one can take a look at the Event Bus (see test/eventlisten.py), many applications are possible when using the data on this bus. Thomas talks about a future IOflow python module where a complex logic can be implemented in the reactor with rules and a state machine. One example use of this would be if the load is high on X number of servers and the number of connexions Y on these servers then launch extra machines.

To finish on a buzzword, someone asked "what is the overlap of salt and docker" ? The answer is not simple, but Thomas thinks that in the long run there will be a lot of overlap, one can check out the existing lxc modules and states.

Wrap up

To wrap up, Thomas announced a salt conference planned for January 2014 in Salt Lake City.

Logilab proposes to bootstrap the French community around salt. As the group suggest this could take the form of a mailing list, an irc channel, a meetup group , some sprints, or a combination of all the above. On that note, next international sprint will probably take place in January 2014 around the salt conference.


PyConFr

2013/10/28 by Alain Leufroy
http://www.pycon.fr/2013_static/pyconfr/images/banner.png

Logilab était au rendez-vous annuel des pythonistes de tous genres : la conférence PYCONFR organisée par l'AFPy, qui avait lieu cette année à l'université de Strasbourg.

Si vous n'y étiez pas, voici un petit aperçu de ce que vous avez raté, sachant que le programme était chargé.

Où en est le packaging ?

Nos amis de Unlish ont fait une présentation de l'état actuel de la distribution de paquets python.

Après une présentation générale de PyPI, ils ont décrit les derniers changements qui ont permis d'améliorer la disponibilité des paquets python.

L'information la plus importante concernait Wheel qui est le format désormais recommandé pour fournir des binaires précompilés. Fini les .egg de setuptools ! Ceci devrait faire sourir plus d'un mainteneur de paquet ou administrateur système.

Wheel est un format de fichier de distribution. Ce format clair et succinct est décrit par la PEP427. Il vise à simplifier la fabrication des paquets pour les distributions de vos OS favoris.

Les versions récentes de l'installeur pip peuvent gérer les paquets Wheel qui sont compatibles avec le système d'installation décrit dans la PEP376. Il faut toutefois, pour l'instant, dire explicitement à pip de prendre en compte ces fichiers dès qu'ils sont disponibles, grâce à l'option --use-wheel.

Vous disposez ainsi des avantages de pip (gestion claire et simple des dépendances, freeze, désinstallation, etc.) et ceux d'une distribution de paquets précompilés (installation rapide et simple, environnement de développement non requis, etc.).

Les paquets Wheel prennent en compte les implementations de python et leurs ABIs. Vous pouvez donc fournir des paquets Wheel (et les signer) facilement pour des versions spécifiques de Jython, Pypy, IronPython, etc.

$ python setup.py bdist_wheel
$ pypy setup.py bdist_wheel

Cela ne vous dispense pas de distribuer les sources de votre paquet ;)

$ python setup.py sdist

Python dans Mercurial

http://www.selenic.com/hg-logo/logo-droplets-50.png

Pierre-Yves David et Alexis Métaireau ont fait un petit rappel des trucs vraiment géniaux dans Mercurial comme les revsets et les templates.

Le coeur de leur présentation concernait l'utilisation de Python pour écrire Mercurial.

D'après son auteur, Mercurial existe aujourd'hui grâce à Python. En effet Python a permis à Matt Mackall d'écrire une preuve de son concept en à peine deux semaines -- il n'avait pas plus de temps à y dédier donc l'implementation en C n'était pas envisageable.

Rappelons qu'avant de changer le langage d'implementation il est toujours intéressant de se poser des questions sur les algorithmes utilisés. Nous avons vu quelques exemples d'optimisation en Python qui ont permis de d'accélérer Mercurial, et quelques astuces pour contourner les lenteurs que l'on rencontre avec l'interpréteur CPython (lazy import, low-level access, etc.).

Les autres avantages notables de l'utilisation de Python viennent de sa flexibilité. Les extensions pour Mercurial peuvent grâce à cela changer le comportement interne de Mercurial. Par exemple largefiles et watchman améliorent grandement la gestion des gros fichiers et la mise à jour des informations du dépôt.

Hy, lisp on Python

http://docs.hylang.org/en/latest/_images/hy_logo-smaller.png

Julien Danjou a présenté une implémentation de Lisp basé sur la VM de Python. En effet Python peut être vu comme un sous-ensemble de Lisp.

Hy interprète un script écrit dans un dialecte de Lisp et le convertit en arbre syntaxique Python classique, qui est ensuite exécuté par l'interpréteur Python.

[Python] .py -(parse)---> AST -(compile)-> .pyc -(run)-> python vm
                      /
[Lisp]   .hy -(parse)/

tip

hy2py permet de montrer l'équivalent Python d'un script Lisp.

Il y a donc une grande interopérabilité entre ce qui est implémenté en Hy et ce qui l'est en Python. Aucun souci pour importer les autres modules Python, quels qu'ils soient.

Hy supporte presque toutes les versions de Python et beaucoup d'interpréteurs, notamment pypy.

De nombreuses fonctions de common Lisp sont disponibles, et Hy se rapproche de Clojure pour la définition des classes.

Pour ceux qui sont intéressés par Hy, notez qu'il manque encore quelques petites choses :

  • les cons cells sont en cours de discussion
  • il faudra faire sans les macroexpand pour vous aider dans vos macros
  • les fonctions de Common Lisp ne sont pas toutes présentes
  • le dialect de Lisp nécessite, pour l'instant, de mixer les [...]` et les (...)`, mais ceci devrait changer.
  • Hy n'est pas présent à l'exécution, il y a donc forcément des limitations.

Python pour la Robotique

Il y avait une présentation bien sympathique d'une équipe qui participe régulièrement aux championnats de france de robotique.

Ils utilisent une carte basée sur un SoC ARM sur laquelle ils disposent d'un Gnu/Linux et d'un interpréteur Python (2.7).

Ils ont codé en C/C++ quelques routines de bas niveau pour un maximum de réactivité. Mise à part cela, tout le reste est en Python, notamment leurs algorithmes pour gérer la stratégie de leurs robots.

Python leur facilite énormément la vie grâce au prototypage rapide, à la rapidité pour corriger leur code (surtout avec le manque de sommeil durant la compétition), à la souplesse pour simuler en amont, analyser des logs, etc.

Un Python dans la maison

http://hackspark.fr/skin/frontend/base/default/images/logo3d_hackspark_small.png

Il y avait aussi la présentation d'un projet (Hack'Spark!) jeune mais déjà fonctionnel de domotique. La petite démonstration en direct du système était du plus bel effet ;)

Et, pour moins de 100 euros vous pourrez allumer la lumière chez vous depuis une interface web ! Perso, je m'y mets ce mois ;)

Framework Graphique Kivy

http://kivy.org/logos/kivy-logo-black-64.png

Kivy est entièrement écrit en Python/Cython et utilise OpenGL. Il a donc un très bon support sur les machines récentes (Linux, BSD, MacOs, Android, iOS, Rpi, etc.). Et il n'a rien a envier aux autres frameworks.

Kivy semble particulièrment pratique pour mener à bien des projets sur les plateformes mobiles comme les téléphones portables et les tablettes (Android et iOS).

De plus, parmi les outils fournis avec Kivy vous pourrez trouver quelques trucs pour simplifier votre développement :

  • PyJNIus utilise l'interface JNI de la VM Java (via Cython). Il sert de proxy sur les classes Java et vous donne donc accès à l'ensemble de l'API Android.
  • PyObjus est le pendant de PyJNIus pour ObjectiveC sous iOS.
  • Plyer essaie de rassembler en une API commune de plus haut niveau PyJNIus et PyObjus, ce qui permet de coder une seule fois pour les deux plateformes.
  • Buildozer aide à la compilation de projet pour Android de manière plus simple qu'avec Python for Android.

Nous avons eu droit à une présentation des concepts et comment les mettre en œuvre en direct. Je sens que ça va me simplifier la vie !


Retour sur MiniDebConf Paris 2014

2014/03/05 by Arthur Lutz
http://www.logilab.org/file/226609/raw/200px-Mini-debconf-paris.png

Nous sommes heureux d'avoir participé à la MiniDebConf Paris.

Nous avons sponsorisé l'évenement mais aussi effectué deux présentations :

Avec une cinquantaine de participants sur les deux jours, c'est toujours agréable de rencontrer la communauté francaise autour de Debian. Merci donc à l'association Debian France d'avoir organisé cette conférence.