Le huitième Ansible Contributor Summit, évènement organisé par Red Hat et dédié aux échanges entre la core team Ansible et la communauté, s’est déroulé ce dimanche 29 mars 2020. Intégré initialement à la conférence foss‑north hébergée à Göteborg, l’évènement a eu lieu à l’aide de vidéoconférences et d’IRC.
Lorsque la situation sanitaire le permettra, un évènement sera à nouveau organisé en Europe pour que la communauté s’y rencontre, étant donné que les précédents Contributor Summits ont pris place aux États‑Unis.
Cette dépêche résume une partie des discussions ayant eu lieu lors de cet évènement.
Sommaire
L’évènement a débuté à 13 h UTC + 2 et s’est terminé vers 19 h UTC + 2. Sur la cinquantaine d’inscrits, un peu plus de trente participants étaient présents, notamment une quinzaine d’employés Red Hat et une quinzaine de membres de la core team, l’intersection de ces deux ensembles étant composée d’une dizaine de personnes.
Les journaux IRC ainsi que les notes sont disponibles. Contrairement à cette dépêche, ces deux liens référencent l’ensemble des sujets discutés.
Cet Ansible Contributor Summit est suivi de deux jours de hackaton.
Les collections
Les collections Ansible, ainsi que leur impact sur l’ensemble du projet, ont occupé une partie importante des échanges.
Jusqu’à la version 2.9 incluse, le dépôt Git d’Ansible contient l’ensemble des modules et greffons. À partir de la version 2.10, la grande majorité des modules et greffons sont déplacés dans d’autres dépôts Git. Cette version expurgée est appelée ansible-base
. Une soixantaine de modules — par exemple, ceux liés à l’exécution de commandes ou à l’installation de paquets — et greffons ne sont pas déplacés. Au niveau du projet Ansible, la migration aux collections n’est pas complètement terminée.
Disponibles à partir de la version 2.10 qui n’a pas encore été publiée, les collections sont des ensembles de ressources Ansible : modules, greffons et rôles.
Les collections ont notamment pour objectifs de :
- faciliter la publication et la réutilisation de modules (plus simplement qu’en copiant ces modules dans un rôle) ;
- permettre la publication de versions des modules et greffons plus fréquemment et indépendamment des publications d’Ansible ;
- résoudre le problème d’espace de noms qui ne permettait pas d’utiliser deux modules différents avec un nom identique ; chaque ressource possède un identifiant en trois parties : nom d’organisation Ansible Galaxy, nom de la collection et nom de la ressource ;
- faciliter la maintenance en répartissant les pull-requests entre différents projets.
Trois collections supportées par la core team ont été publiées : netcommon
, posix
et windows
. Il n’est pas prévu de créer des collections mélangeant des ressources supportées par la core team et des ressources maintenues par la communauté.
Le code source des collections peut être hébergé sous l’organisation GitHub ansible-collections ou sur d’autres forges logicielles. La publication des collections sur Ansible Galaxy est requise.
Alicia Cozine a présenté une version en cours de développement du site Web de la documentation. La question des journaux des changements des collections n’est pas encore résolue.
L’introduction des collections ne devrait rien changer pour les utilisateurs installant Ansible via pip
: ansible-base
et les collections contenant les modules et greffons présents dans la version 2.9 seront contenus dans le paquet Python Ansible publié sur PyPi généré à l’aide du projet ACD.
Ansible Community Distribution (ACD)
Le contenu de la distribution communautaire Ansible ainsi que son processus de publication ne sont pas finalisés, les outils liés à la construction du paquet sont en train d’être développés par Toshio Kuratomi. Il est possible de tester ces développements à l’aide de la commande suivante :
python3.8 -m pip install --user --upgrade -i https://toshio.fedorapeople.org/ansible/acd/ ansible
AWX
Matt Davis a présenté l’impact des collections sur AWX, une interface Web à Ansible. Actuellement, AWX prend en charge les environnements virtuels personnalisés ainsi que les collections à l’aide d’un fichier collections/requirements.yml
.
À terme, la notion d’environnement d’exécution sera ajoutée au projet AWX. Ces environnements d’exécution :
- remplaceront les environnements virtuels personnalisés ;
- seront basés sur des conteneurs ;
- contiendront Ansible, ansible-runner et les collections.
Dans un second temps, l’interface Web sera modifiée afin de permettre la gestion des environnements d’exécution.
Documentations relatives aux collections
- statut du projet ;
- présentation & FAQ ;
- documentation pour les utilisateurs ;
- documentation pour les développeurs de ressources.
molecule 3
Sorin Sbarnea a présenté les nouveautés de la dernière version de molecule, un outil permettant de tester les playbooks et rôles Ansible.
Un pilote molecule gère la création et la destruction des ressources utilisées par les tests (par exemple : conteneurs ou machines virtuelles). La majorité des pilotes ont été déplacés du dépôt Git de molecule vers des dépôts dédiés, par exemple le pilote OpenStack. Il ne reste que trois pilotes dans le dépôt molecule : delegated
, docker
et podman
. Le pilote par défaut reste docker
. L’objectif de cette réorganisation est de faciliter la maintenance et le développement des évolutions du cœur du projet. Un pilote molecule est un simple paquet Python avec un point d’entrée spécifique.
Par défaut, Ansible remplace testinfra
au niveau de l’étape des tests (verifier). testinfra
est toutefois recommandé pour les cas d’usage avancé. goss
est toujours disponible.
La commande molecule matrix <sequence>
permet de lister l’ensemble des étapes d’une séquence donnée.
Il est possible de spécifier des valeurs par défaut au fichier molecule.yml
en utilisant le fichier $HOME/.config
ou $REPO/.config
.
À noter que le projet pytest-molecule
permet d’exécuter plusieurs scénarios molecule en parallèle.
ansible-lint
ansible-lint
est utilisé pour évaluer la qualité des rôles publiés sur https://galaxy.ansible.com. Le projet est entièrement communautaire et maintenu par Sorin Sbarnea sur son temps libre.
Depuis la version 4.2, tous les fichiers YAML sont analysés, alors qu’il était auparavant nécessaire d’utiliser une commande du type ansible-lint $(find . -type f -name ".yml" -o -name ".yaml")
.
Communauté et statistiques
Gregory Sutcliffe a présenté différentes statistiques, notamment celles relatives aux contributions relatives aux collections.
Canaux IRC
Le projet Ansible utilise notamment les canaux IRC suivants (en anglais, sauf le 3ᵉ) sur le réseau Freenode :
- #ansible, pour les questions liées à l’utilisation d’Ansible ;
- #ansible-devel, dédié aux échanges relatifs au développement du projet ;
- #ansible-fr, canal en français avec un ratio participants/membres de la core team intéressant ;
- #ansible-molecule, spécifique au projet molecule ;
- #ansible-awx, consacré au projet AWX ;
- #ansible-community, dédié aux discussions liées à la communauté.
D’autres canaux IRC existent et sont listés dans la partie Groups de la page Community.
# Merci !
Posté par Nicolas Quiniou-Briand . Évalué à 1.
Bonjour,
Merci pour ce résumé très clair de cet événement, les vidéos des échanges sont disponibles ici : https://www.youtube.com/playlist?list=PL0FmYCf7ocraJzcnE3-VwVozQ0Zt7vm7z
Nicolas Quiniou-Briand
# CLA non merci
Posté par Benjamin Henrion (site web personnel) . Évalué à 1.
https://github.com/apigee/ansible/blob/master/CONTRIBUTING.md
Signer un CLA pour pouvoir contribuer, non merci.
[^] # Re: CLA non merci
Posté par Pilou . Évalué à 2.
Le fichier pointé n'existe pas dans le dépôt Git du projet Ansible et son contenu semble ne jamais y avoir été présent.
Le dépôt officiel du projet Ansible contient ce paragraphe, qui est présent dans les sources depuis 2012 (version 0.8):
Quels sont les problèmes/inconvénients de ce texte ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.