Salut
merci pour le podcast.
Je n’avais pas suivi la nouveauté ansible et www.jetporch.com/ merci. Je me suis demandé s’il avait prévu de faire autre chose que du YAML. Parce que parfois c’est pas top pour écrire des choses qui se coderaient bien, comme les filtres ansible qui peuvent donner des horreurs pour extraire des clés…
EDIT: j’ai sorti les liens de la syntaxe Markdown sur le texte, on ne vois pas la lien dans Firefox
Exemple d’horreur de syntaxe ansible: How to filter a dictionary in Ansible | by George Shuklin | OpsOps | Medium
Et en parcourant l’article de blog on a des objectifs:
Source: A New IT Automation Project? Moving Beyond Ansible And Keeping The Spirit - An Invitation
« Nobody wants to learn a new language. Folks have a lot of existing automation content. They don’t want to port content to a new system, and they have even less time for something that might feel like programming. People also didn’t want to help build something from scratch and don’t have a lot of time to contribute to a project like they did in 2012 before agile ate IT/DevOps.
»
Donc si le postulat est “Nobody wants’ to learn a new language” effectivement il faudra encore se coltiner du YAML, et non un DSL. Mais il n’est pas exclu que l’on voit apparaître une surcouche dans le future. 
À ce titre DSL ça rappelle HCL le langage de terraform, qui est aussi pénible pour les boucles, et la news de https://opentf.org/ dont vous parlerez sûrement au prochain épisode. 
À suivre,
Sylvain.
1 « J'aime »
Bonjour Sylvain,
J’arrive (très très) longtemps après ce post certes. Il se trouve que j’avais commencé à étudier le code de jetporch afin d’y contribuer mais c’était quelques semaines seulement avant que Michael Dehaan ne décide de tout arrêter. J’ai continué de mon côté puis j’ai préféré adopter une nouvelle approche et je me suis affranchi du code d’origine de jetporch. Mon idée est d’offrir une capacité d’automatisation sous forme de librairie (Rust) et laisser les gens encapsuler ça dans ce qui leur va le mieux pour leur use case particulier (repo). Ma librairie peut s’utiliser soi via du code rust, soit via du YAML.
Ta remarque sur le YAML est très intéressante car je suis moi aussi saturé de YAML à titre pro mais, après avoir cherché comment faire autrement, j’en suis arrivé à la conclusion que ça reste un excellent compromis (en général) entre complexité du code derrière et simplicité d’utilisation pour l’utilisateur final. Mais je suis curieux de savoir à quoi tu penses lorsque tu parles de « surcouche » ?
Salut Romain,
Ah ouais, 2023 quand même, Tu as bien conscience que je ne suis plus vraiment dans le contexte 
Mais je suis curieux de savoir à quoi tu penses lorsque tu parles de « surcouche » ?
Et bien, quand ça devient difficile à gérer et lire, généralement on pilote le tout par un outil.
Qui peut faire appel à un langage spécifique genre:
- Ansible - basé sur YAML
- kubernetes - basé sur YAML (ou Json
)
- HCL le langage de terraform - spécifique, les boucles sont bof à lire
- Docker - Dockerfile
- docker-compose - basé sur YAML
- CI/CD - basé sur YAML, ah non, Jenkins a son propre langage
Jenkinsfile exemple de boucle
- ruby (que je n’utilse plus en ce moment) faisait d’excellent DSL par example Vagrantfile, ou Rakefile
- Makefile - biensûr
- script dédié avec une config (peut-être basée sur YAML mais sans boucle dans le yaml) python, bash, langage compilés plus rapides
Peut-être qu’en 2026, c’est l’anglais et le prompt, le langage de pilotage… 

Mais ça maque un peu de rigueur dans la syntaxe, quoique j’ai lu ici qu’on pouvait renforcer avec du . <opignon_biaisée>J’aime pas trop le XML à taper</opignon_biaisée>
Y a encore des outils qui se configurent même en XML…
Après, je te propose de faire un sujet tout neuf et en rapport avec les DSL ou outils. 