Ah mais Yaml, couplé avec Jinja2, c'est le PHP des années 2000 all-over-again.
PHP c'est - à l'origine - un préprocesseur de HTML.
Sauf que c'est incidemment un langage turing-complet.
Et on est passé du templating sympa au templating crados pour dépasser le templating, puis à l'application web mal foutue bourrée de trous et impossible à maintenir, et enfin aux applications PHP modernes qui sont quand même mieux faites, mais n'ont rigoureusement plus rien à voir avec le pré-processing des origines.
Et là, quand on fait du Ansible avancé, on se retrouve à voir des trucs qui ressemblent au passage du templating sympa, au templating crados.
Par pur chance on a les modules, généralement en Python, qui permettent de ralentir le passage à l'application ansible mal foutue fondée sur un langage de templating descriptif...
Et franchement, faire de la programmation en Yaml/Jinja2 c'est du pur masochisme, sadique pour le reste de l'équipe.
Sauf qu'il faut trouver le bon curseur entre complexificatifier son module pour gérer plein de cas, et traiter des cas différents depuis un bout de programmation Yaml/Jinja2, ce qui n'est pas toujours d'une complète évidence.
Au bout du compte, dès qu'on commence à vraiment gérer des choses compliquées en Ansible, c'est terriblement difficile à lire et à maintenir :(
Alors passer des arguments depuis un Job Jenkins à un playbook Ansible, qui appelle des rôles, et eux-mêmes des modules internes, c'est un champs de mine terrifiant à débugger pour savoir pourquoi cette p$£*% de variable a pas la bonne valeur là, bigre !
En plus j'ai une question subsidiaire :
La syntaxe du Python est basée sur l'indentation, et ça rend presque forcément le code lisible, qu'on aime ou pas, le code Python se ressemble et avec de l'habitude on arrive même à lire le code de Pierre T.
La syntaxe de Yaml est basée sur l'indentation, et ça rend presque forcément le résultat illisible, qu'on aime ou pas, le code Yaml se ressemble, et même avec de l'habitude il faut s'y reprendre à plusieurs fois pour bien savoir quelle est la structure représentée.
Pourquoi ?
Ou plutôt : Comment avoir autant raté son design ?
Comment réussir au final à être moins lisible que du bête JSON qui n'impose rien en terme de présentation du code ?
Bref, Ansible, si je pouvais m'en passer, ça serait volontiers.
cela dit, le journal est clair et bien présenté, j'approuve totalement, merci JulienG !
[^] # Re: il faudrait le réécrire <s>en Rust</s> !
Posté par Yth (Mastodon) . En réponse au journal Test de vie et Ansible : un exemple de réalisation pour mieux comprendre l'outil. Évalué à 7.
Ah mais Yaml, couplé avec Jinja2, c'est le PHP des années 2000 all-over-again.
PHP c'est - à l'origine - un préprocesseur de HTML.
Sauf que c'est incidemment un langage turing-complet.
Et on est passé du templating sympa au templating crados pour dépasser le templating, puis à l'application web mal foutue bourrée de trous et impossible à maintenir, et enfin aux applications PHP modernes qui sont quand même mieux faites, mais n'ont rigoureusement plus rien à voir avec le pré-processing des origines.
Et là, quand on fait du Ansible avancé, on se retrouve à voir des trucs qui ressemblent au passage du templating sympa, au templating crados.
Par pur chance on a les modules, généralement en Python, qui permettent de ralentir le passage à l'application ansible mal foutue fondée sur un langage de templating descriptif...
Et franchement, faire de la programmation en Yaml/Jinja2 c'est du pur masochisme, sadique pour le reste de l'équipe.
Sauf qu'il faut trouver le bon curseur entre complexificatifier son module pour gérer plein de cas, et traiter des cas différents depuis un bout de programmation Yaml/Jinja2, ce qui n'est pas toujours d'une complète évidence.
Au bout du compte, dès qu'on commence à vraiment gérer des choses compliquées en Ansible, c'est terriblement difficile à lire et à maintenir :(
Alors passer des arguments depuis un Job Jenkins à un playbook Ansible, qui appelle des rôles, et eux-mêmes des modules internes, c'est un champs de mine terrifiant à débugger pour savoir pourquoi cette p$£*% de variable a pas la bonne valeur là, bigre !
En plus j'ai une question subsidiaire :
La syntaxe du Python est basée sur l'indentation, et ça rend presque forcément le code lisible, qu'on aime ou pas, le code Python se ressemble et avec de l'habitude on arrive même à lire le code de Pierre T.
La syntaxe de Yaml est basée sur l'indentation, et ça rend presque forcément le résultat illisible, qu'on aime ou pas, le code Yaml se ressemble, et même avec de l'habitude il faut s'y reprendre à plusieurs fois pour bien savoir quelle est la structure représentée.
Pourquoi ?
Ou plutôt : Comment avoir autant raté son design ?
Comment réussir au final à être moins lisible que du bête JSON qui n'impose rien en terme de présentation du code ?
Bref, Ansible, si je pouvais m'en passer, ça serait volontiers.
cela dit, le journal est clair et bien présenté, j'approuve totalement, merci JulienG !