Planète AFPy RSS

[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.

Mathieu 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. I use a simple series of alias to deal with that:

david@perseus:~salt/$ cat sourceme.sh
#!/bin/bash

export SALTROOT=`dirname $(readlink -f $0)`
alias salt="/usr/bin/salt -c $SALTROOT/etc/salt "
alias salt-key="/usr/bin/salt-key -c $SALTROOT/etc/salt "
alias salt-master="/usr/bin/salt-master -c $SALTROOT/etc/salt "
alias salt-api="/usr/bin/salt-api -c $SALTROOT/etc/salt "
alias salt-call="/usr/bin/salt-call -c $SALTROOT/etc/salt "
alias salt-run="/usr/bin/salt-run -c $SALTROOT/etc/salt "
alias salt-cloud="/usr/bin/salt-cloud -c $SALTROOT/etc/salt "
david@perseus:~salt/$ source sourceme.sh
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 membre de 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 extention, à 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 ça connexion, des informations sur les dernier jobs.

La liste des minions pouvant être longue il y a la possibilité de filtre 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é (publics) ou privés. Pour les minions sélectionnés il est possible dans 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 communication et donc c'est le serveur qui ce connecte aux clients ce qui peut impliquer de paramétrer ssh avec des proxy, le cas typique est l'accès au 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 nom 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 de DDN à présenté l'utilisation de Salt dans le cadre du déploiement et maintient des produits de DDN de stockage type big data et S3. Les clients de DDN déploient quelques RPM et produisent une configuration qui va pousser sur l'ensemble des nœuds (via SSH) les masters et les minions pour déployer toute la stack (Zookeeper, HBase, Hadoop, memcache, etc) puis pour la surveiller et l'orchestrer. À noter que l’environnement déployé est multi-master, au plus 2 ou 3 master afin de minimiser certaines latences. DDN a développé un ensemble d'outils (*ctl) qui forment une couche d'abstraction à Salt, afin de gérer le stockage offert par les 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é, la parallélisation, la consistance dans ce qui est déployé, le 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 !

[carlchenet] Liens intéressants Journal Du pirate semaine #15

Publié le 2015-04-09 22:11:31
Suivez-moi aussi sur Diaspora* ou Twitter  ou sur Identi.ca Pour cette 15è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 ! Proxmox : mise en place de 2 nœuds en Haute disponibilité(HA) Backup Checker 1.7 :…

[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.

[carlchenet] Liens intéressants Journal Du pirate semaine #14

Publié le 2015-04-02 22:00:09
Suivez-moi aussi sur Diaspora* ou Twitter  ou sur Identi.ca Pour cette 14è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 ! Hublin, vidéos et réunions en ligne en mode Libre Hacker les voitures connectées ? C’est…

[carlchenet] Liens intéressants Journal Du pirate semaine #13

Publié le 2015-03-26 23:00:34
Suivez-moi aussi sur Diaspora* ou Twitter  ou sur Identi.ca Pour cette 13è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 ! Evqueue, un ordonnanceur de tâches libre et open source LDAPS : OpenLDAP et GnuTLS Image…

[carlchenet] On a une sauvegarde de la base de données ? Elle a 6 mois, inutilisable

Publié le 2015-03-25 23:00:37
Suivez-moi aussi sur Diaspora* ou Twitter  ou sur Identi.ca Péremption des données Quel informaticien n’a pas été confronté à la péremption des données ? Vos données sont trop vieilles, inutilisables. Les causes peuvent être multiples : schémas des données ayant évolués, format de fichiers incompatibles ou delta trop important avec l’existant. Le cas est particulièrement…

[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

[carlchenet] Unverified backups are useless. Automatize the controls!

Publié le 2015-03-23 23:00:28
Follow me on Identi.ca  or Twitter  or Diaspora* Unverified backups are useless, every sysadmins know that. But manually verifying a backup means wasting time and resources. Moreover it’s boring. You should automatize it! Backup Checker is a command line software developed in Python 3.4 on GitHub (stars appreciated :) ) allowing users to verify the integrity of…

[carlchenet] Liens intéressants Journal Du pirate semaine #12

Publié le 2015-03-19 23:22:51
Suivez-moi aussi sur Diaspora* ou Twitter  ou sur Identi.ca Pour cette 12è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 ! Docker Compose remplace Fig Installation d’un cluster de stockage CEPH Censure administrative du Web en…

[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.

[carlchenet] Le Journal Du Pirate : votre source d’informations pour le Logiciel Libre francophone

Publié le 2015-03-11 23:00:21
Suivez-moi aussi sur Diaspora* ou Twitter  ou sur Identi.ca De très bons articles en français sont écrits tous les jours par la communauté francophone du Logiciel Libre, que ce soit via des blogs de passionnés, les sites incontournables de la communauté, les sites ou blogs d’entreprises. Pour s’y retrouver dans ce fourmillement, le Journal Du…

[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.

[carlchenet] Verify your backups… or lose them all

Publié le 2015-03-08 23:00:52
Follow me on Identi.ca  or Twitter  or Diaspora* As a good sysadmin, you thought you had backups for your server but you didn’t verify them before the major migration you attempted? When you need them, they’re empty or full of useless files. And now it’s too late… You won’t guess how often this situation occurs. Backup Checker…

[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...

[afpyro] AFPyro à Bruxelles (BE) - vendredi 6 Mars

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

Un Meetup/AFPyro aura lieu le vendredi 6 Mars à partir de 19h à la Mort Subite - Rue Montagne-aux-Herbes Potagères 7, Brussels.

Pour s’inscrire: http://www.meetup.com/Belgium-Python-Meetup-aka-AperoPythonBe/events/220506641/

En plus des Francophones, des Néerlandophones seront également présents.

Chacun pourra parler sa langue pendant le drink, par contre, les présentations seront en anglais pour être compréhensibles de tous.

Les présentations

  • AI: Curious Actors by Michael
  • Write and prod an efficient REST API with API-Hour in 5 minutes by Ludovic
  • Tool discovery : Plumbum by Fabien
  • Python Belgium Association by Stephane

Prérequis

Pour plus d’intéractions pendant les présentations, vous pouvez venir avec votre laptop, en ayant installé au préalable:

  • wrk si vous voulez essayer de faire tomber le daemon API-Hour de Ludovic
  • plumbum et un serveur distant afin de tester les scripts proposés par Fabien

[sciunto] Don du mois : pitivi

Publié le 2015-03-05 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.

Ce mois-ci (en fait le mois précédent, mais je n'ai pas eu le temps de faire le billet), ce fût pitivi, $5. Pitivi est un logiciel graphique de montage video. Les raisons sont les suivantes :

  • Un logiciel qui a de l'ambition.
  • Il a pour objectif de combler un manque réel dans le logiciel libre et c'est la source d'un reproche que j'entend fréquemment.
  • J'ai pu obtenir de l'aide des devs quand j'ai bêtement raté ma compilation.
  • La campagne n'a pas encore atteint son objectif et elle débloquera des nouvelles fonctionnalités.

Même si je n'utilise pas ce logiciel fréquemment, il m'a rendu quelques services et il est clairement utile selon moi pour les utilisateurs de solutions libres.

Pour donner à pitivi.

[AFPy Salt-fr] Compte rendu du sprint chez Logilab

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

Juste un petit post pour dire que le sprint sur Salt a rassemblé 7 personnes dans les locaux de Logilab et que nous en avons bien profité et réussi à produire quelques contributions à salt (patches de codes, réflexions sous forme de tickets, etc).

Participants au sprint Salt 2015

Merci à tous les participants d'être venus contribuer et échanger.

Le compte rendu détaillé en anglais est publié sur un blog de Logilab : A report on the Salt Sprint 2015 in Paris

[AFPy-Nantes] Un meetup pour fêter le printemps !

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

Lors de notre prochain meetup, le 24 mars à 19h à la Cantine, deux sujets très pythoniques vous seront proposés par nos orateurs :

  • Présentation d'asyncio (par Gaël) : La bibliothèque Python 3 asyncio fournit une infrastructure pour écrire du code concurrent mono-threadé en utilisant les coroutines, multiplexer des entrées-sorties à travers des sockets ou d'autres ressources, faire tourner des clients et serveurs réseaux, ...
  • Tests unitaires en python (par Thomas) : Python nous offre par défaut des outils terriblement pratiques pour la mise en place de tests automatisés. Nous aborderons la question de l'utilité et de la pertinence de ces tests unitaires, la mise en oeuvre basique du module unittest. Nous expliquerons ensuite le sujet des fixtures, puis nous irons un peu plus loin, avec le concept de Factory. Enfin, nous présenterons certains modules de tests alternatifs.

Nous espérons vous compter aussi nombreux que d'habitude à ce meetup ainsi qu'au verre qui s'en suivra.

Rejoignez-nous sur le chan IRC de l'AFPy Nantes ou inscrivez vous sur la liste de diffusion . :)

À bientôt !

[carlchenet] On vient de perdre le serveur, t’as vérifié les sauvegardes récemment ? ooooooooups

Publié le 2015-03-03 23:32:01
Suivez-moi aussi sur Identi.ca  ou Twitter  ou Diaspora* Le titre évoque une situation malheureusement bien connue des sysadmins. Pour éviter cette situation, Backup Checker est un programme en ligne de commande codé en Python permettant le contrôle automatisé de l’intégrité d’archives (tar, gz, bzip2, lzma, zip) et de la cohérence des fichiers à l’intérieur des…

[afpyro] AFPyro à Lyon - mercredi 25 février

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

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

Une présentation sur la programmation multi-agents sera donnée pa Sébastien Floc’h.

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] Un MOOC en français sur Python

Publié le 2015-02-23 11:41:37
Le premier MOOC en français dédié à l'apprentissage du langage Python a été annoncé sur FUN, la plateforme de MOOC du ministère de l’enseignement supérieur.

[AFPy Salt-fr] Sprint Salt en marge de la SaltConf

Publié le 2015-02-18 23:00:00

Que diriez vous de venir faire un petit sprint en marge de la SaltConf (qui a prévu un sprint le mercredi 4 mars 2015 en soirée) dans les locaux de Logilab ? Celui-ci aurait donc lieu le même jour, le mercredi 4 mars, de 9h à 18h.

L'idée est d'avoir une vrai session de travail où l'on finisse la journée avec des contributions à salt (documentation, code, tests, etc). On pourra aussi en profiter pour discuter technique et échanger sur nos pratiques.

En 2013, Logilab avait déjà fait un sprint saltstack, qui malgré des problèmes d'électricité s'était plutôt bien passé.

Pour qu'on puisse savoir le nombre de participants en avance, merci de remplir le framadate (avec possibilité de participer sur IRC, mais bon, c'est pas idéal).

[AFPy Salt-fr] Compte rendu Salt Meetup Paris - février 2015

Publié le 2015-02-15 23:00:00

La communauté Salt française (ou plutôt francilienne) s'est réunie dans les locaux parisiens de Dailymotion pour son premier meetup de l'année, autour de trois présentations. Voici un compte rendu (très court) pour vous renvoyer vers les références.

David Douard

Utiliser salt dans des docker

David Douard de Logilab a fait une rapide présentation sur l'utilisation de salt dans un conteneur docker, par exemple pour tester des configurations salt.

Cette présentation s'est déroulée en deux parties :

  • un présentation rapide de docker
  • une démonstration de l'utilisation de salt dans un docker, avec :
    • la configuration requise pour lancer un salt-master local pour piloter les minions lancés dans des conteneurs,
    • la présentation d'un Dockerfile qui produit une image docker minimal, basée sur une Debian jessie, avec un salt-minion installé et lancé par supervisord,
    • un exemple de test de configuration d'un apt-cacher à partir de la formula existante.

Découper ses states/pillar salt

Paul Tonelli, de Heuritech, nous a fait une présentation sur la bonne manière de sécouper ses states et pillars salt pour installer un salt-master chez un client, et a parlé des bonnes pratiques d'organisation du code salt.

Le support de sa présentation sont disponibles ici.

SaltPad

saltpad

Boris Feld de Tinyclues nous a refait une présentation rapide de son projet saltpad, une interface web pour piloter salt, sous forme d'une démonstration de l'outil.

Discussions

Des discussions se sont engagées suites à ces présentations, notament sur :

  • qui utilise, et comment, les environnements dans une configuration salt,
  • état et stabilité des modules dockerio récement arrivés dans salt,
  • état de la salt-api et utilisation des ACLs

Ces discussions pourraient être le sujet de présentations et de discussions plus avancées lors d'un prochain meetup.

Conclusion

Merci à Dailymotion d'avoir acceuilli et apporté à boire, et fourni les pizzas.

Pour le prochain meetup (avril), votez pour une date sur framadate et n'hésitez pas à inscrire une proposition de présentation ou de lieu sur le pad d'organisation.

[afpyro] Afpy à Pau le mercredi 11 Février

Publié le 2015-02-11 00:00:00

Un afpyro aura lieu à Pau le 11 Février à 20h30.

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

jpcw nous fera une petite présentation sur les décorateurs en Python et on causera librement de différents sujets autour de python.

Voir la map

[AFPy Salt-fr] Annonce : Meetup Salt Paris chez Dailymotion - Fevrier 2015

Publié le 2015-02-10 23:00:00

Le meetup de février aura lieu dans les locaux de Dailymotion au 140 boulevard Malesherbes, Paris 17e, métro Wagram ou Malesherbes.

Dailymotion

David Douard de Logilab présentera "Faire du Salt dans et avec des docker".

Il reste encore des places pour faire des présentations éclairs. Contactez nous sur la liste pour nous faire une proposition de présentation.

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


View Larger Map

[carlchenet] Backup Checker 1.0, the fully automated backup checker

Publié le 2015-02-09 23:01:21
Follow me on Identi.ca  or Twitter  or Diaspora* Backup Checker is the new name of the Brebis project. Backup Checker is a CLI software developed in Python 3.4, allowing users to verify the integrity of archives (tar,gz,bz2,lzma,zip,tree of files) and the state of the files inside an archive in order to find corruptions or intentional of accidental…

[AFPy-Nantes] Un petit barcamp ?!

Publié le 2015-02-09 23:00:00

Après les conférences très appréciées du mois de janvier, qui nous ont permis de bien commencer l'année 2015, on continue avec un BarCamp mardi 24 février, encore et toujours à la Cantine !

L'idée sera donc de proposer puis de voter pour quelques thèmes qui deviendront des ateliers / tables rondes, auxquelles tout participant peut s'inscrire, peu importe son niveau de connaissance du sujet. Les différentes discussions pourront donner lieu à des petits compte-rendus afin que toute la communauté profite de ce qui s'est dit ou fait.

Comme d'habitude, ceux qui le souhaitent pourront prolonger l'évènement 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 :)

N'hésitez pas à vous inscrire ici pour que nous ayons un aperçu du nombre de participants : inscription au meetup.

À bientôt !

[raspberry-python] from python import tourism

Publié le 2015-02-06 21:06:00
 Quel est le lien entre Python et le tourisme? On explore le thème sur 3DFutureTech.

Francois
@f_dion

[afpy.org] PyconFR'15 : Où nous emmèneras-tu cette année ?

Publié le 2015-02-06 07:55:43

[afpyro] AFPyro à Bruxelles (BE) - le 31 Janvier

Publié le 2015-01-31 00:00:00

Dear Pythonista friends, write down in your agenda the date of the next AFPyro!

The next Aperos Python Belgium will take place on saturday, January 31st in Brussels, during the FOSDEM conference that takes place at ULB from 31st January to 1st February.

In addition to the regulars of AFPyro, we are also pleased to meet the attendees of FOSDEM using Python.

As usual, you can come just for drinking and sharing one (or many) drinks or if you wish, you can also register for the meal that follows, in a near place, at “Chez Léon” for 20:30, rue des Bouchers 18, B-1000 Brussels.

Meeting from 19:45, on first floor of Delirium cafe, Impasse De La Fidélité 4, 1000 Brussels.

If you are a FOSDEM attendee, you can meet us at the Python devroom, after the end of lightning talks, (H.1301 room) to go to Delirium cafe together.

Please sign up in order to book the place: http://doodle.com/ngdeesgbr6dcx3f5

Further information about the next AFPyros in Belgium: Aperos Python Belgium


Amis Pythonistes, notez dans vos agendas la date du prochain AFPyro !

Le prochain Aperos Python Belgium se tiendra le samedi 31 Janvier à Bruxelles, lors du FOSDEM qui se tient à ULB du 31 Janvier au 1 Février.

En plus des habitués de l’AFPyro, nous attendons également avec plaisir les participants du FOSDEM qui utilisent Python.

Comme chaque fois, vous pouvez venir juste pour l’apéro et partager un (ou des) verres, ou si vous le souhaitez, vous inscrire également pour le repas qui suivra, “Chez Léon” à 20h30, rue des Bouchers 18, B-1000 Bruxelles.

Rendez-vous à partir de 19h45, au premier étage du Délirium café, Impasse De La Fidélité 4, 1000 Brussels.

Si vous participez au FOSDEM, nous vous donnons rendez-vous à la salle Python-devroom, après la fin des lightning talks, (salle H.1301), afin d’aller au Délirium café ensemble.

Pour dimensionner au mieux la réservation, merci de vous inscrire sur: http://doodle.com/ngdeesgbr6dcx3f5

Toutes les infos des prochains AFPyros en Belgique: Aperos Python Belgium

[afpyro] AFPyro à Lyon - mercredi 28 janvier

Publié le 2015-01-28 00:00:00

Un Afpyro aura lieu le mercredi 28 janvier à partir de 19h à l’Antre Autre - 11 rue Terme - 69001 Lyon.

Une présentation sur l’utilisation et les dernières fonctionnalités de Radicale sera donnée par Guillaume Ayoub.

L’Antre Autre est un lieu où nous pouvons discuter autour d’un verre, et, pour ceux qui le souhaitent, prendre un repas.

Pour se rendre à l’Antre Autre :

  • en métro : arrêt Hôtel de Ville
  • en bus : lignes C13 et C18 arrêt Mairie du 1er ou lignes 19, C14 et C3 à l’arrêt Terreaux
  • en vélo’v : stations Place Sathonay, Carmélites Burdeau, Place de la paix

[tarek] Charity Python Code Review

Publié le 2015-01-27 19:23:00

Raising 2500 euros for a charity is hard. That's what I am trying to do for the Berlin Marathon on Alvarum.

Mind you, this is not to get a bib - I was lucky enough to get one from the lottery. It's just that it feels right to take the opportunity of this marathon to raise money for Doctors without Borders. Whatever my marathon result will be. I am not getting any money out of this, I am paying for all my Marathon fees. Every penny donated goes to MSF (Doctors without Borders).

It's the first time I am doing a fundraising for a foundation and I guess that I've exhausted all the potentials donators in my family, friends and colleagues circles.

I guess I've reached the point where I have to give back something to the people that are willing to donate.

So here's a proposal: I have been doing Python coding for quite some time, wrote some books in both English and French on the topic, and working on large scale projects using Python. I have also gave a lot of talks in Python conferences around the world.

I am not an expert of any specific fields like scientific Python, but I am good in "general Python" and in designing stuff that scales.

I am offering one of the following service:

  • Python code review
  • Slides review
  • Documentation review or translation from English to French

The contract (gosh this is probably very incomplete):

  • Your project have to be under an open source license, and available online.
  • I am looking from small reviews, between 30mn and 4 hours of work I guess.
  • You are responsible for the intial guidance. e.g. explain what specific review you want me to do.
  • I am allowed to say no (mostly if by any chance I have tons of proposals, or if I don't feel like I am the right person to review your code.)
  • This is on my free time so I can't really give deadlines - however depending on the project and amount of work I will be able to roughly estimate how long is going to take and when I should be able to do it.
  • If I do the work you can't back off if you don't like the result of my reviews. If you do without a good reason, this is mean and I might cry a little.
  • I won't be responsible for any damage or liability done to your project because of my review.
  • I am not issuing any invoice or anything like that. The fundraising site however will issue a classical invoice when you do the donation. I am not part of that transaction nor responsible for it.
  • Once the work will be done, I will tell you how long it took, and you are free to give wathever you think is fair and I will happily accept whatever you give my fundraising. If you give 1 euro for 4 hours of work I might make a sad face, but I will just accept it.

Interested ? Mail me! tarek@ziade.org

And if you just want to give to the fundraising it's here: http://www.alvarum.com/tarekziade

[AFPy-Nantes] Compte-rendu des conférences : Pyramid, Générateurs et co-routines

Publié le 2015-01-26 23:00:00

Pour ce premier meetup de janvier, deux sujets ont été présentés devant une quarantaine de personnes visiblement intéressées et attentives. Vous trouverez dans cet article un résumé de ce qui a été proposé, ainsi que les liens vers les présentations.

Pyramid

Intervenant : Gaël

Pyramid est un framework web développé en Python. On peut le classer entre Bottle (plus minimaliste) et Django (plus gros et plus monolithique). Il est nativement WSGI, facilement extensible et laisse beaucoup de souplesse dans les choix techniques et la conception.

Vous verrez dans les slides qu'un classique "Hello World", servi en HTTP, est très simple à réaliser.

Le premier composant à appréhender est le configurateur, qui permet de configurer une application Pyramid (et notamment de gérer les routes).

Le routeur a la particularité de pouvoir fonctionner de deux manière différentes :

  • par mapping des URLs sur des vues
  • en mode traversal (les différents fragments de l'URL permettent traverser des classes).

Le routeur permet aussi classiquement de faire de la résolution d'URL, ce qui évite à avoir à répéter des URLs dans les templates par exemple.

Un autre concept assez intéressant du framework est l'utilisation des exceptions. Il est notamment possible de lever des exceptions HTTP ce qui permet de gérer les erreurs sous forme de codes du protocole HTTP (500, 403).

Le concept de factory permet de récupérer/travailler sur un objet avant qu'une vue ne soit invoquée, ce qui rend le code de la vue plus simple. Une factory peut être factorisée et utilisée dans plusieurs vues.

Le rendu d'une vue se fait via par l'intermédiaire d'une renderer et une vue peut être associée à plusieurs renderer (par exemple un rendu json et un rendu HTML via une template). On pourrait aussi avoir plusieurs renderers utilisant des moteurs de templates différents (Chameleon, Jinja, Mako, ...). Il est aussi possible de créer son propre renderer (par exemple pour renvoyer un fichier csv, un pdf, ...).

Le concept de tween permet d'intercepter une requête, puis la réponse pour analyser ou modifier l'une ou l'autre. Un cas pratique classique est l'utilisation d'une barre de debuggage permettant d'analyser le comportement de l'application.

Un système d'évènements permet d'associer une fonction à un évènement. Par exemple : BeforeRender est déclenché avant le rendu d'une template et laisse la possibilité d'injecter des données dans le context passé à la template.

Par ailleurs, Pyramid est modulaire et peut être facilement étendu via la fonction magique includeme. Il est aussi possible d'étendre l'objet request pour lui ajouter des méthodes par exemple, ce qui peut s'avérer pratique dans certains cas.

Beaucoup de modules supplémentaires sont fournis nativement :

  • Gestion de l'authentification et d'autorisations
  • Gestion et service des fichiers statiques
  • Gestion des sessoins
  • Gestion du cache HTTP
  • Gestion de prédicats de vue
  • Gestion de trasaction étendue (par exemple pour éviter un envoi de mail si une requête SQL a précédemment échoué)
  • ...

L'écosystème de Pyramid est assez riche et varié ; plus de 250 packages sont indiqués comme étant compatibles Pyramid sur pypi.

Il existe entre autres des CMS basés sur Pyramid : notamment substanced (basé sur la ZODB) et kotti.

Les slides de la présentation sont disponibles ici : Présentation de Pyramid

Générateurs et coroutines

Intervenant : Hugo

Les itérateurs / iterables

Le concept d'itérable est simplement une généralisation du concept de séquence ou de liste. Un itérable est défini par le fait qu'il est possible d'itérer dessus, par exemple dans une boucle for ... La syntaxe [] permet de définir ce qu'on appelle une liste en compréhension. L'iterable est un concept pratique mais il a le défaut de stocker tous ses éléménts en mémoire.

Les générateurs

Un générateur est un itérable qui a la particularité de générer les résultats à la volée. Syntaxiquement une expression génératrice peut s'écrire de la même manière qu'un itérable classique, en remplaçant les [] par des ().

Dans un générateur, on utilise le mot clé yield à la place de return. La première différence est que l'appel de la fonction renverra non pas un résultat mais un générateur, sans que la fonction soit exécutée. La fonction est exécutée à partir du moment où on itère sur le générateur. Le premier appel à la méthode next permet d'exécuter la fonction jusq'au premier yield. À l'exécution du yield, le générateur rend la main à la fonction appelante et s'arrête (mais l'état de son exécution est enregistré). Dans la fonction appelante, chaque appel de la méthode next relance donc une exécution du générateur, de l'état où il s'était arrêté jusqu'au yield suivant.

Plusieurs intérêts notables :

  • l'évaluation paresseuse limite l'allocation mémoire
  • elle permet aussi de travailler avec une vision "flux de données" (en chainant plusieurs générateurs comme on chaine des commandes unix par exemple cat foo.txt | grep bar)
  • possibilité de faire du pseudo-asynchrone de manière synchrone

Les co-routines

Une co-routine est à peu prêt la même chose qu'un générateur à la différence près qu'elle dispose d'une méthode supplémentaire send qui permet à la fonction appelante d'envoyer des données à la co-routine. Cela permet d'influer sur son comportement depuis la fonction appelante.

La vision est inversée : dans une chaine de co-routines, la fonction appelante pousse les données vers la fonction appelée. Il est aussi possible de diffuser des données à plusieurs co-routines.

L'application principale des co-routines est de faire de la programmation pseudo-asynchrone tout en gardant une lisibilité proche du code synchrone classique. L'autre avantage est que la co-routine est "maitre" de son état et sait à quel endroit et dans quel état elle peut être interrompue et reprendre son exécution.

Le mot clé yield from, arrivé en Python 3, permet de faire de la délégation de générateurs, c'est à dire de créer une sorte de tunnel bidirectionnel entre un générateur et un sous-générateur.

Les slides de la présentation sont disponibles ici : Générateurs et co-routines

Merci à tous pour votre présence, on se retrouve au prochain barcamp le 24 mars !

[sciunto] Don du mois : archlinux

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

Je trouve intéressante l'idée de Sam et Max de présenter les organisations pour lesquelles on a donné quelques euros (il n'y a pas de petit don). Je me lance donc aussi dans l'idée.

Ce mois-ci, ce fût archlinux, $5. Les raisons sont les suivantes :

  • Grande qualité et rapidité des mises à jour, je n'ai jamais eu de problème majeure, au pire quelques petits désagréments qui se sont résolus très vite.
  • Wiki clair et à jour, on y trouve beaucoup d'informations pertinentes et de qualités.
  • Forum agréable, mes rares questions ont trouvé réponse, les dev de la distribution prennent le temps de répondre.
  • Enorme choix de paquets, notamment grâce à AUR auquel je participe. Pouvoir faire mes propres paquets est une raison qui motive mon choix pour cette distribution.
  • J'utilise cette distribution depuis 4 ou 5 ans maintenant. L'installation n'est faire qu'à l'achat de ma machine.
  • J'ai la dernière version de tous les composants, je ne me pose aucune question lorsque j'utilise une lib ou un soft pour mon travail.

Je donne donc à archlinux pour cette satisfaction quotidienne.

Pour donner à archlinux.

[cubicweb] CubicWeb roadmap meeting on January 8th, 2015

Publié le 2015-01-12 16:28:00

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

Here is the report about the January 8th, 2015 meeting.

Christophe de Vienne (Unlish) and Aurélien Campéas (self-employed) joined us to express their concerns and discuss the future of CubicWeb.

Versions

Version 3.18

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

Version 3.19

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

Version 3.20

This version has been released a few days ago. It has not been deployed on production systems yet.

Its main features are:

  • virtual relations: a new ComputedRelation class can be used in schema.py; its rule attribute is an RQL snippet that defines the new relation.

  • computed attributes: an attribute can now be defined with a formula argument (also an RQL snippet); it will be read-only, and updated automatically.

    Both of these features are described in CWEP-002, and the updated "Data model" chapter of the CubicWeb book.

  • cubicweb-ctl plugins can use the cubicweb.utils.admincnx function to get a Connection object from an instance name.

  • new 'tornado' wsgi backend

  • session cookies have the HttpOnly flag, so they're no longer exposed to javascript

  • rich text fields can be formatted as markdown

  • the edit controller detects concurrent editions, and raises a ValidationError if an entity was modified between form generation and submission

  • cubicweb can use a postgresql "schema" (namespace) for its tables

  • cubicweb-ctl configure can be used to set values of the admin user credentials in the sources configuration file

For details read list of tickets for CubicWeb 3.20.0.

We would have loved to integrate the pyramid cube in this release, but the debian packaging effort needed by the pyramid stack is quite big and is acceptable if we target jessie only (at decent price).

Version 3.21

For now, the roadmap for 3.21 is still the complete removal of the dbapi, the merging of Connection and ClientConnection.

Integrate the pyramid cube to provide the pyramid command if the pyramid framework can be imported.

Integration of CWEP-003 (FROM clause for RQL) and CWEP-004 (cubes as standard python packages) is being discussed.

Version 4.0

We expect to accelerate development of CubicWeb 4, which exact roadmap is still to be discussed, but we may already want:

  • be pyramid-based (remove twisted, auth management, etc.),
  • do not have anything left of old dbapi and ClientConnection,
  • integrate squareui as main (and only) web-ui "template" or remove web generation (almost) completely from cubicweb-core and provide it only through the cube system.

Agenda

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

Open Discussions

Refactoring the documentation

Christophe de Vienne suggested to completely revamp the documentation and intends to lead this effort.

Training material

Aurélien Campéas asks if Logilab would be willing to share its training material under a free license to help interested parties organize and sell trainings.

Towards making squareui the default rendering engine for cubicweb

We are expecting to be able to use squareui/bootstrap as "rendering engine" for our forge applications (like http://www.cubicweb.org and http://www.logilab.org) as soon as possible. However to achieve to goal, there are still too many "visual bugs", some of which may require a discussion.

Among others:

  • put the ctxtoolbar component in the <nav> div
  • each box component should have an icon (what API for this?)
  • we cannot easily make the left column of the main template responsive-aware (requires to change the html flow), so it's probably best to take inspiration from things like http://wrapbootstrap.com/preview/WB0N89JMK
  • facet boxes are a mess, there is no simple solution to have a "smart layout"

Migration

  • AppObjects should not be loaded by default
  • Have a look at Alembic the migration tool for SQLAlchemy and take inspiration from there.

[AFPy-Nantes] Premier meetup Python 2015 !

Publié le 2015-01-06 23:00:00

Pythonistes nantais, attaquons l'année 2015 comme il se doit avec un meetup dès la fin de ce mois de janvier, le 27, toujours à partir de 19h à la Cantine.

Pour partir du bon pied, deux présentations vous seront proposées :

  • Pyramid : Pyramid est un framework python léger et pleinement compatible WSGI. Nous présenterons les principaux concept du framework. Création de projet, dispatching vs traversing, rendu de template, sécurité, événements, intégration d'application WSGI tierce.
  • Générateurs & co-routines : Durant cette présentation il sera question du langage Python en tant que tel et en particulier de deux concepts voisins : les générateurs, qui permettent une expression "paresseuse" et les co-routines, qui introduisent un style de programmation relativement méconnu. Après une présentation des aspects syntaxiques, nous pourrons échanger sur les cas d'utilisation possibles de ces concepts.

Nous espérons donc vous compter nombreux parmi nous le 27 janvier à la Cantine, ainsi pour le verre qui s'en suivra probablement :).

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 . :)

À bientôt !

[raspberry-python] L'étonnant Python: à grande échelle

Publié le 2015-01-02 23:30:00

Perception

De temps a autres, j'entends dire des choses complètement ridicules:

"Ah oui vous utilisez Python. Je connais, c'est un langage de programmation pour écrire des petits scripts, ce n'est pas utilisable à grande échelle.

(En fait il y avait 2 autres points encore plus ridicule dans cette conversation, j'y reviendrai plus tard)

Réalité

Une connaissance travaille chez Bank Of America sur le programme Quartz. Ils sont passes de 0 a 5000 développeurs Python et des millions (plus de 10) de lignes de code en quelques années seulement. On parle de la même échelle pour YouTube. Les projets de 10 millions+ de lignes de code Python sont rares bien sur, mais ce n'est pas du a une raison technique, mais plutôt parce que l'on accomplis beaucoup en peu de lignes de code.

François
@f_dion

[AFPy-Nantes] Meetup Python du 23 décembre : boire un verre !

Publié le 2014-12-19 23:00:00

Ce mardi 23 décembre, nous proposons au pythonistas de Nantes de se retrouver pour prendre un verre.

Le rendez-vous est à 19h au Delirium Tremens, 19 allée Baco à Nantes.

Certains seront absents, le système de distribution du Père Noël semble-t'il repose sur Python (ce qui explique peut-être qu'il dépasse celui d'Amazon écrit en Perl !).

Joyeuses fêtes !