Trop simple, trop compliqué...
Ton exemple est trop simple pour représenter un cas réel.
La réalité te confronte rapidement à des structures de données un poil plus complexe qu'un dictionnaire de deux listes de trois éléments, avec deux clé/valeur au bout.
Et là... Là ça devient très vite illisible.
Mais en vrai, du Python avec de forts degrés d'indentations et sans découpage du code, c'est insupportable aussi. En fait n'importe quel langage.
Et pour le coup une syntaxe ouvrante/fermante est plus lisible (même si parfois marginalement).
Sauf que, pour des états, des structures de données, la complexité peut être normale, alors que dans du code source, la normalité est de faire des fonctions, de la factorisation, pour garder des ensembles cohérent de code assez petits, et sans trop de niveaux d'imbrication.
Et un include task bidule en yaml ansible, qui exploite des variables héritées sans prendre de paramètres, te donne rapidement un sac de fichiers imbitables à dérouler.
Donc tu fais quoi ? Tu essaies d'être plus explicite, de passer des paramètres à tes sub-tasks, de faire de boucles, ... de programmer ta description d'état...
Et tu sors du templating descriptif pour entrer dans le templating crados.
Et là parfois tu te demandes bien pourquoi tu n'es pas en train de coder directement en Python.
La différence entre :
tasks:
- name: "install Apache server"
yum:
name: "httpd"
state: latest
Et :
tasks(name="install Apache server").yum(name="httpd", state="latest")
Est moins évidente, mais permettrait d'éviter la « programmation en Jinja2 ».
Mais bref, je trouve que c'est une dérive qu'on retrouve un peu trop dans Ansible, un peu sur le principe de quand on a un marteau, tous les problèmes ressemblent à des clous, si on a déjà une infra Ansible en place, on a envie de tout faire en Ansible.
Et cette dérive me fait penser au PHP des années 2000.
Le PHP des années 2000 a abouti au PHP 8 d'aujourd'hui, qui est efficace et fonctionnel, rien à dire de ce côté là, donc ce n'était pas forcément un mal en soi, juste une phase d'adolescence brouillonne et qui a laissé des traumatismes.
Mais quelle adolescence aujourd'hui dans Ansible, qui a clairement dépassé le stade de la prime jeunesse ?
Quelle stabilité sera conquise dans le futur, quelle évolution attendre ?
Puisque le côté outil simple et descriptif d'un état clairement énoncé ne suffit pas (sinon on n'aurait pas les dérives que je décris, et décrie), quelle est la réponse ?
Ansible doit-il se contenter d'être un outil de description d'état désiré, ou doit-il évoluer vers un outil de programmation distante comme on peut le voir de plus en plus ?
Et s'il évolue vers un outil de programmation distante, quelle évolution du couple yaml/Jinja2 ? Un autre format plus adapté à côté, ou des hacks imbitable qui finiront par donner un langage de programmation originellement pensé pour faire du templating, et qui deviendra utilisable dans 10 ans ?
Le parallèle avec PHP 3 se fait exactement ici, on est dans la période brouillonne et crados, et on est en train de construire les traumatismes futurs.
Mais quel futur est souhaitable ? Quel futur sera construit ?
[^] # 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é à 3.
Trop simple, trop compliqué...
Ton exemple est trop simple pour représenter un cas réel.
La réalité te confronte rapidement à des structures de données un poil plus complexe qu'un dictionnaire de deux listes de trois éléments, avec deux clé/valeur au bout.
Et là... Là ça devient très vite illisible.
Mais en vrai, du Python avec de forts degrés d'indentations et sans découpage du code, c'est insupportable aussi. En fait n'importe quel langage.
Et pour le coup une syntaxe ouvrante/fermante est plus lisible (même si parfois marginalement).
Sauf que, pour des états, des structures de données, la complexité peut être normale, alors que dans du code source, la normalité est de faire des fonctions, de la factorisation, pour garder des ensembles cohérent de code assez petits, et sans trop de niveaux d'imbrication.
Et un include task bidule en yaml ansible, qui exploite des variables héritées sans prendre de paramètres, te donne rapidement un sac de fichiers imbitables à dérouler.
Donc tu fais quoi ? Tu essaies d'être plus explicite, de passer des paramètres à tes sub-tasks, de faire de boucles, ... de programmer ta description d'état...
Et tu sors du templating descriptif pour entrer dans le templating crados.
Et là parfois tu te demandes bien pourquoi tu n'es pas en train de coder directement en Python.
La différence entre :
tasks:
- name: "install Apache server"
yum:
name: "httpd"
state: latest
Et :
tasks(name="install Apache server").yum(name="httpd", state="latest")
Est moins évidente, mais permettrait d'éviter la « programmation en Jinja2 ».
Mais bref, je trouve que c'est une dérive qu'on retrouve un peu trop dans Ansible, un peu sur le principe de quand on a un marteau, tous les problèmes ressemblent à des clous, si on a déjà une infra Ansible en place, on a envie de tout faire en Ansible.
Et cette dérive me fait penser au PHP des années 2000.
Le PHP des années 2000 a abouti au PHP 8 d'aujourd'hui, qui est efficace et fonctionnel, rien à dire de ce côté là, donc ce n'était pas forcément un mal en soi, juste une phase d'adolescence brouillonne et qui a laissé des traumatismes.
Mais quelle adolescence aujourd'hui dans Ansible, qui a clairement dépassé le stade de la prime jeunesse ?
Quelle stabilité sera conquise dans le futur, quelle évolution attendre ?
Puisque le côté outil simple et descriptif d'un état clairement énoncé ne suffit pas (sinon on n'aurait pas les dérives que je décris, et décrie), quelle est la réponse ?
Ansible doit-il se contenter d'être un outil de description d'état désiré, ou doit-il évoluer vers un outil de programmation distante comme on peut le voir de plus en plus ?
Et s'il évolue vers un outil de programmation distante, quelle évolution du couple yaml/Jinja2 ? Un autre format plus adapté à côté, ou des hacks imbitable qui finiront par donner un langage de programmation originellement pensé pour faire du templating, et qui deviendra utilisable dans 10 ans ?
Le parallèle avec PHP 3 se fait exactement ici, on est dans la période brouillonne et crados, et on est en train de construire les traumatismes futurs.
Mais quel futur est souhaitable ? Quel futur sera construit ?