URL: https://linuxfr.org/news/ansible-contributor-summit-mars-2020 Title: Ansible Contributor Summit (mars 2020) Authors: Pilou Ysabeau, Xavier Teyssier, Misc, Davy Defaud et Benoît Sibaud Date: 2020-03-30T06:41:05+02:00 License: CC by-sa Tags: ansible Score: 4 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](https://foss-north.se/2020/)_ hébergée à [Göteborg](https://fr.wikipedia.org/wiki/G%C3%B6teborg), 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. ---- ---- L’évènement a débuté à 13 h UTC + 2 et s’est terminé vers 19 h UTC + 2. Sur la [cinquantaine d’inscrits](https://etherpad.openstack.org/p/ansible-contributor-summit-gothenburg-2020), 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](https://docs.ansible.com/ansible/devel/community/committer_guidelines.html#people)_, l’intersection de ces deux ensembles étant composée d’une dizaine de personnes. Les [journaux IRC](https://meetbot.fedoraproject.org/ansible-community/2020-03-29/ansible_contributor_summit_2020.2020-03-29-10.50.log.html) ainsi que les [notes](https://meetbot.fedoraproject.org/ansible-community/2020-03-29/ansible_contributor_summit_2020.2020-03-29-10.50.html) 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](https://github.com/ansible/ansible/tree/stable-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`](https://github.com/ansible-collections/overview#q-what-exactly-is-ansible-base-for-and-what-does-it-contain). Une [soixantaine de modules](https://github.com/ansible/ansible/tree/devel/lib/ansible/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](https://github.com/ansible-collections/overview#timeline). Disponibles à partir de la version 2.10 qui n’a pas encore été publiée, les collections sont des ensembles de ressources Ansible : [modules](https://docs.ansible.com/ansible/devel/reference_appendices/glossary.html#term-modules), [greffons](https://docs.ansible.com/ansible/devel/plugins/plugins.html) et [rôles](https://docs.ansible.com/ansible/devel/reference_appendices/glossary.html#term-roles). 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](https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html#embedding-modules-and-plugins-in-roles)) ; - 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_](https://galaxy.ansible.com/ansible) 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](https://github.com/ansible-collections/)_ ou sur d’autres forges logicielles. La [publication](https://docs.ansible.com/ansible/latest/dev_guide/developing_collections.html#publishing-collections) des collections sur [Ansible Galaxy](https://galaxy.ansible.com/) est requise. [Alicia Cozine](https://github.com/acozine) a présenté une version en cours de développement du [site Web de la documentation](http://docs.testing.ansible.com/collections/index.html). La question des journaux des changements des collections n’est [pas encore résolue](https://github.com/ansible-collections/overview/issues/18). 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](https://pypi.org/project/ansible/) 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](https://gist.github.com/abadger/1f14caded92117fbd3036842c875701c), les outils liés à la construction du paquet sont [en train d’être développés par Toshio Kuratomi](https://github.com/abadger/misc-work/tree/master/ansible/build_acd). 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](https://github.com/nitzmahone) a présenté l’impact des collections sur [AWX](https://github.com/ansible/awx), une interface Web à Ansible. Actuellement, AWX prend en charge les [environnements virtuels personnalisés](https://github.com/ansible/awx/blob/devel/docs/custom_virtualenvs.md) ainsi que les collections à l’aide d’un [fichier `collections/requirements.yml`](https://github.com/ansible/awx/blob/devel/docs/collections.md). À 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](https://github.com/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](https://github.com/ansible-collections/overview/blob/master/status.rst) ; - [présentation & FAQ](https://github.com/ansible-collections/overview/blob/master/README.rst) ; - [documentation pour les utilisateurs](https://docs.ansible.com/ansible/latest/user_guide/collections_using.html) ; - [documentation pour les développeurs de ressources](https://docs.ansible.com/ansible/latest/dev_guide/developing_collections.html). # molecule 3 [Sorin Sbarnea](https://github.com/ssbarnea) 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](https://github.com/ansible-community/molecule-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`](https://github.com/philpep/testinfra) au niveau de [l’étape des tests](https://molecule.readthedocs.io/en/latest/configuration.html#verifier) (_verifier_). `testinfra` est toutefois recommandé pour les cas d’usage avancé. [`goss`](https://github.com/ansible-community/molecule-goss) est toujours disponible. La commande `molecule matrix ` 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`](https://github.com/ansible-community/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 . 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](https://github.com/GregSutcliffe) a présenté [différentes statistiques](https://stats.eng.ansible.com/apps/), notamment celles relatives aux [contributions relatives aux collections](https://stats.eng.ansible.com/apps/collections/contributors/). # Canaux IRC Le projet Ansible utilise notamment les canaux IRC suivants (en anglais, sauf le 3ᵉ) sur le réseau [Freenode](https://webchat.freenode.net) : - **#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](https://github.com/ansible/community#groups).