Gil Cot ✔ a écrit 5730 commentaires

C'est ce qu'il dit, je crois. Il y a RCS qui est actif sur son tél (et surtout intégré à l'appli utilisé) et donc court-circuite le fonctionnement habituel des MMS (utilisation du même réseau que les SMS.) Du coup, pas en mode data donc pas de messages plus plus.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Réveil à 5h23… Mais effectivement pas dormi dans un lit (s'assoupir dans un fauteuil en attendant qu'un process finisse et en se disant qu'on ferme les yeux cinq minutes mais en avoir pour quatre heures) triste vie de nolife (:

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

je ne fais pas la course à la performance, le sequentiel me va très bien !

T'inquiètes, je fais parfois ce genre de boucle. C'est juste que le séquentiel c'est bien ici quand le nombre de machines se compte sur le bout des doigts et que la commande ne prend pas une plombe (ça c'est un autre souci mais qui entre en compte proportionnellement au nombre d'hôtes.)
Le parallélisme offert par ces outils est intéressant quand on doit faire de la masse (ou grande échelle) mais est quand même limité pour ne pas pomper toutes les ressources (déjà sur la machine d'exécution, il est bon de limiter le nombre de sous-processus fork en fonction de la RAM et du CPU, et ne pas oublier que plus on a de connexions établies plus on consomme de bande passante à l'instant et au détriment des autres)

Et du coup, pour répondre à

et les quelques fois où je me suis motivé à apprendre Ansible

Pour faire la même chose avec Ansible, avec ta liste de $hosts définie dans un fichier $hostslist (comme pour les autres outils mentionnés, avec une machine par ligne) :

ansible '*' -i "$hostlist" -m command -a "$cmd"

Il est possible d'utiliser ta liste $hosts sans passer par un fichier, mais ce n'est pas la méthode préconisée (et pas bien documentée mais on trouve la trace quelque part dans la documentation officielle.)

Petit détail quand même qui peut avoir son importance, c'est bon pour des commandes toutes simples car les redirections et tubes ne seront pas permises ainsi. Pour faire sauter ces garde-fous, c'est encore un autre module.

ansible '*' -i "$hostlist" -m shell -a "$cmd"

Il y a un troisième encore plus permissif que je n'évoquerai pas.
Et sinon, bien entendu faire gaffe aux variables d'environnement et ce genre de choses surprenantes.
En tout cas tu as maintenant le mode d'emploi pour la prochaine fois. Bien que, comme dit ailleurs, je trouve qu'il y a peu d'intérêt à te farcir Ansible si c'est juste pour ce genre de besoin ponctuel. Et parlant d'ailleurs, tu peux rajouter le tricorder (pas de rapport avec ST…) à la liste

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

À noter que le même exemple

$ salt-ssh '*' cmd.run 'echo "run on all hosts"'
$ salt-ssh 'backend' cmd.run 'echo "run on specific host"'

équivaut en fait à

$ ansible '*' -m command -a 'echo "run on all hosts"'
$ ansible 'backend' -m command -a 'echo "run on specific host"'

Après, l'utilisation du module command/cmd.run est une forme très basique qui se rapproche de ([pd]?s|d)sh évoqué récemment avec juste en prime une sortie familière quand on utilise déjà l'outil. C'est un poil plus intéressant quand on peut utiliser les autres modules.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Faut rien présupposer et juste déléguer à SSH :) Y a(ura) toujours des solutions et c'est aux usagers/admins de faire leurs choix.

• prompt pour la phrase de passe → ssh-agent
• prompt pour le mot de passe → sshpass

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Semblerait que ce soit pour le fun

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

J'arrive trop tard ('dredi) pour proposer elf.ic

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Au début c'est viral… Passé le temps d'enthousiasme confiné, ça devient lassant. Enfin, ça rentre dans le paysage (certaines personnes ne remarquent même plus) ou ça agace…

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

C'est mensonger d'affirmer qu'en décrivant l'état on n'est pas déjà en train de coder, et tu n'abordes pas l'éventuelle complexité du changement d'état qui demande beaucoup d'actions à automatiser (puisque «coder» ou «scripter» fait peur…)

Décrire l'état c'est dire : « à cette étape, s'assurer de l'existence du répertoire trucmuch »
Le coder, ce serait faire en shell : mkdir trucmuch (si tu dois faire la même chose que Ansible sous le capot, il faudrait d'abord vérifier si le répertoire existe et sinon le créer, et tracer les actions que tu fais etc. en général les gens qui disent que c'est plus simple et plus rapide de faire un script ne font pas les trois quarts de ce à quoi ils/elles comparent mais bon)
Dans le premier cas (descriptif) tu n'indiques que l'état final recherché (et dans un format qui parle à plus de gens que les personnes qui codent.) Dans le second cas (impératif) tu indiques les différentes commandes (et donc t'adresses aux gens qui comprennent le langage de scripting utilisé.) La personne qui lit ton playbook ne se préoccupe pas de l'implémentation ; ce n'est pas une question de coder ou scripter qui ferait peur, c'est juste que ce n'est pas le lieu. Bien sûr que le changement d'état est complexe et justement quand tu fais de la description d'état tu n'abordes pas la difficulté sous-jacente : donc tu ne codes pas…

Et je dis que son inventaire est moisi, celui de puppet est bien mieux pour ça. Ansible pour mon cas c'est «codez un inventaire dynamique, regardez le code source pour la doc de l'api» (et encore, y'a des trucs qui étaient pas dispos à l'époque, et la doc est plus complète qu'elle ne l'était)
Puppet a des mécanismes qui me permettent de dire sur l'hôte A «prend le cluster X et le cluster Z», et sur le B «cluster Y et Z». Sans écrire de plugins et python ou ruby ou autre…

C'est bien que admettes qu'il y a de plus en plus de plugins d'inventaire …plus le temps passe et plus t'en as. C'est bien aussi de faire le parallèle qu'un autre outil qui a pratiquement le double de son âge ait plus de plugins d'inventaire déjà prêts.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Et chaque fois qu'on creuse (en tout cas la majorité des questions que je croise sur les forums) c'est parce-que en pratique on veut mal l'utiliser (souvent comme un langage de script que ça n'est pas —on reboucle.)
Sinon, tant qu'à scripter tu pourrais proposer des modules « mieux » faits.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Ce n'est pas du mépris et ton exemple ne fait que redire ce que je dis : ça n'impose rien (malheureusement pour toi). Et je dis aussi que c'est dans l'esprit unixien qui ne contraint pas : il faut bien apprendre à utiliser les commandes sinon le système n'empêche pas root de faire rm -rf / contrairement à un autre qui veut te contraindre et te demandant dix validations pour supprimer un fichier anodin ou parfois en te refusant carrément de le faire pour une raison obscure. Donc pas de warning quand tu utilises le module command à ta guise car tu es sensé avoir lu la fichue doc^[1] et savoir ce que tu fais…
Tu arrives toi-même à la conclusion que \$job-1 on faisait ce qu'il ne fallait pas faire et ce n'est pas du mépris que de faire ce triste constat (qui concerne beaucoup d'entreprises…)^[2]

PS : Si tu veux t'assurer que les bonnes pratiques sont respectées dans tes playbooks, passe ansible-lint dessus… Mais, encore une fois, tu resteras libre de ne pas suivre ses avertissements et consignes.

[1] Doc qui te dit justement de bien chercher s'il n'y a pas un meilleur module, un module dédié, et que celui-là ne doit s'utiliser qu'en dernier recours… Doc aussi disponible hors ligne mais beaucoup l'ignorent.

[2] C'est du même acabit quand les boîtes développent en C (zéro garde-four) au lieu d'utiliser Ada ou Java ou Rust par exemple.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

(-: mieux Tant

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Le journal dit :

il pourrait y avoir des utilisateurs de a.out non conscient de la prochaine apocalypse et n'ont pas fait connaître leur objection. Si ces utilisateurs n'ont pas connaissance ou ne veulent pas utiliser le wrapper de Cook,

Et j'en connais qui sont dans le cas (n'ont pas connaissance). Faut que je trouve le temps de les recontacter (anciens clients) pour leur demander de tester le wrapper ou de se résoudre à ne plus mettre à jour (sécurité bonjour) ou de migrer la crèmerie. il s'agit aussi, d'un vieux soft (en plus critique, raison pour laquelle j'avais alerté dessus) tout coff (jeu de mot volontaire) dont ils n'ont pas les sources (et comme c'est fermé et le propriétaire aux abonnés absents depuis belle lurette il serait temps que les gens comprennent les vertus du libre ?) Mais bon, je me fait pas trop d'illusion car ce client a aussi quelques vieux Unix non à jour dans son placard (heureusement pour moi, je ne serai pas là pour voir la catastrophe.)

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Le framework va plus loin que « tout va bien » et « quelque chose s'est mal passé » puisqu'il distingue :

• (ok) l'état est nominal et je ne fais aucune modification (c'est là la notion d'idempotence)
• (changed) l'état n'était pas celui désiré et les actions d'alignement ont été entreprises et se sont bien passées : ça correspond au rc=0
• (failed) l'état n'était pas celui désiré et les actions de correction ont été entreprises mais ne sont pas bien passées : ça correspond au rc≠0
• (skipped) l'état nominal n'a pas été vérifié et c'est voulu/demandé
• (unreachable) rien n'a pu être fait parce-qu'il y a des soucis de connectivité, là c'est pas voulu/demandé.

Et le framework unifie la présentation (fini les commandes dont les retours ne sont pas homogènes) et le fonctionnement (un module est une charge utile avec le même mode de fonctionnement global hormis les détail d'action) et permet normalement le test à blanc comme tu l'as mentionné (dry run)

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

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 ?

Je rencontre pas mal de code Python pas aussi lisible qu'on nous le vend, tout comme on peut retrouver la même structuration dans d'autres langages qui ne l'imposent pas, Mais là n'est pas le débat.
Je lis le YAML avec la même difficulté/facilité que Python, du coup j'ai du mal à comprendre comment l'un serait illisible et l'autre lisible alors qu'il n'y a pas de différence conceptuelle. Pire, dire que JSON est plus lisible me laisse perplexe.

Ceci est du JSON

{"ints":{"odd":[1,3,5],"even":[2,4,6]},"str":"foo\nbar","ok":true}

Un autre commentaire se plaignait des lignes interminables et des \n pourtant c'est bien ce que tu trouves plus lisible…
Ceci n'est pas du JSON comme l'indique https://www.json.org/json-en.html ; il s'agit d'une/un représentation/formatage pour tenter de le rendre digeste (c'est fait par un formatter et il faut le rectifier en retour pour que l'application qui va le désérialiser l'accepte et surtout le traite bien…)

{
   "ints":{
      "odd":[
         1,
         3,
         5
      ],
      "even":[
         2,
         4,
         6
      ]
   },
   "str":"foo\nbar",
   "ok":true
}

Par contre, cette représentation est bien du YAML que tu trouves illisible… (enfin, pour être canonique faudrait rajouter le « document start » au début)

Comme c'est prévu pour être lu et écrit par les humains, et ne pas être « developpers centrist » on peut alternativement juste écrire (et penser à corriger les indentations) :

---
   "ints":
      "odd": [
         1,
         3,
         5
      ]
      "even": [
         2,
         4,
         6
      ]
   "str": "foo\nbar"
   "ok": true

Est-ce le fait que ce soit à portée des non geeks qui le rend compliqué ? Parce-que ce qui a été fait por les hash/map/dict put s'appliquer aussi aux listes/tuples (une des syntaxe de liste de Markdown et d'autres) :

---
"ints":
   "odd":
      - 1
      - 3
      - 5
   "even":
      - 2
      - 4
      - 6
"str": "foo\nbar"
"ok": true

C'est vrai que c'est gonflé de se mettre à la portée des gens lambdas, parce-que même true peut s'écrire True ou yes, et que avec juste un mot avec ces chaîne de caractères ne prêtant pas à confusion on peut carrément se passer de guillemets (c'est même recommandé, comme ça on ne met pas d'identifiant aevc des symboles problématiques –sous cette forme, pas de deux-points par exemple et les linters refusent les espaces et tout ce qui n'est pas lettre ou chiffre)

---
ints:
   odd:
      - 1
      - 3
      - 5
   even:
      - 2
      - 4
      - 6
str: "foo\nbar"
ok: yes

Sapristi, c'est devenu trop simple (ou plutôt trop compliqué pour Yth et devnewton.)
Pourtant ça semble vachement pythonique (tant qu'on n'utilise pas de truc exotérique) et on peut même mettre des commentaires dis donc. Ça devient trop compliqué en ne ressemblant plus à du tout C…

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

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.

Je me permets de ne pas être entièrement d'accord.
Ce n'était pas un préprocesseur au sens des SSG (i.e. Statics Site Generator comme Hugo et Jeckill pour les plus connus) et autres convertisseurs de Markdown (ou autre en HTML ou XHTML).
C'était un générateur de pages web et un outil de traitement de formulaires comme les CGI (i.e. Common Gateway Interface qui étaient souvent écrit en PERL mais aussi en C ou en Bash —j'en ai fait) : le terme préprocesseur est utilisé parce-que le serveur web devait le lancer avant de passer le résultat généré au client web. Il est normal que ce soit un langage de programmation complet (ou plutôt le devienne à partir de sa version 3) : on a la même chose avec Python ou Ruby pour faire des sites web « all-over-again »

YAML c'est de la bête description, comme on ferait avec du SGML (les pages purement HTML, sans scripting dynamique, décrivent du contenu et ne sont pas des langages de programmation) ou du XML (c'est pour décrire et anoter des données, faut normalement se tourner vers XLT pour les manipuler et une feuille de style pour bien afficher les données.)
Jinja2 c'est un moteur de template relativement simple, dans la lignée de Mustache : ça permet de générer du contenu en y plaçant des données tirées d'un dictionnaire JSON ou YAML (ce qui en fait un choix cohérent, en plus du fait que ce fut d'abord conçu pour l'écosystème Python même si le principe a été rapidement repris dans d'autres langages parfois avec un nom différent qui peut se justifier par les adaptations au langage –et donc éviter les confusions…) Ce n'est pas un langage de programmation (c'est pourquoi je dis que c'est simple et simplet, en tout cas comparé à d'autres avant lui) et beaucoup s'en sont plaint. Bon, il y a quand même une toute petite logique (boucle for et structure if) qui est reprise du langage (Python ici, mais chaque langage l'ayant adopté adapte cette partie à sa syntaxe) …mais ce n'est pas ce qui va permettre d'écrire une appli et il est un peu surfait de comparer ça à PERL/PHP/Python/Ruby/etc.

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.

Comme utiliser une syntaxe de description et un système de templating n'est pas faire de la programmation, c'est en effet masochiste. Encore une fois (je ne le dis pas pour toi mais juste par rapport aux autres commentaires que j'ai écrit et qui me donnent l'impression de me répéter), ce (couple) n'est pas un langage de programmation et on ne fait pas de codage avec l'outil ! Arrêtons de vouloir planter des clous avec des tournevis…

Les modules n'ont pas non plus à être (très) complexes : il faut garder la philosophie Unix de faire KISS, fonctionnel et répondant aux cas identifiés …quitte à avoir plusieurs modules (une tâche un outil) ; exemple que donne le projet (il y a le ping pour le manchot et le diablotin, mais win_ping pour la Fenêtre ; il y a un module par type de gestionnaire de paquets…)
Dès que l'on commence à de la « programmation Yaml/Jinja2 » de Sioux (les cas de contrôle prévus ne sont pas vraiment de la programmation) c'est signe qu'on : utilise mal l'outil, que le problème est mal posé, etc.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

J'ai des besoins ponctuels de reproduire des commandes simples sur une liste de cibles,

Pour ça (balancer des commandes sur une liste de machines), il y a encore plus simple depuis des lustres (en tout cas existaient longtemps avant Fabric) :

• Parallel SSH (commandes pssh ou parallel-ssh et d'autres) https://doc.ubuntu-fr.org/pssh et https://www.tecmint.com/execute-commands-on-multiple-linux-servers-using-pssh/
• Distributed SSH (commande dssh) https://sourceforge.net/projects/dsh/ et https://github.com/malensek/dssh
• Dancer's shell (commande dsh) https://www.tecmint.com/using-dsh-distributed-shell-to-run-linux-commands-across-multiple-machines/

et j'ai fini soit par un script Bash soit par le faire à la main.

Avec l'utilitaire parallel pour ne pas faire du séquentiel ? Ou diverses astuces et de l'huile de coude ? https://www.baeldung.com/linux/processing-commands-in-parallel

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

C'est pour ça que je rappelle que ça n'impose rien (pour son malheur parfois/visiblement.) Même pour ces deux, il est clairement dit que c'est pour dépanner (cas d'une machine sans Python ou cas où il n'existerait pas de module adapté, deux points qui sont de moins en moins vrais aujourd'hui…) Même pour ces deux, le soin a été pris de donner les moyens de faire les choses proprement (et là on arrive au fait que je dis que c'est un cadriciel pour faire facilement de l'idempotence) mais rien n'est imposé (et du coup des sanguoins n'utilisent pas les conditionnements prévus – creates/removes/etc.)

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Petite correction : Salt-stack utilise aussi YAML et Jinja mais avec un paradigme un peu différent.

Petit rappel : Ansible a été pensé pour utiliser des choses existantes, éprouvées et connues de ces auteurs (à un moment on fait un choix…) Donc

• SSH comme transport au lieu de réinventer quelque avec toutes les contraintes, inconvénients et avantages. Mais ce choix a aussi ses bons et mauvais côtés qui sont connus et maîtrisés par les admins sys et la plupart des devs…
• YAML comme langage de description d'états au lieu de se lancer dans un DSL maison. Cela permet d'avoir des recettes lisibles par des humains et auto-documentées tout en favorisant l'usage de JSON sous le capot…
• Python comme langage pour les modules …parce-que justement c'est présent partout (y avait aussi l'alternative PERL mais comme il faut faire des choix et que ce n'était certainement pas connu des équipes qui ont créé l'outil, ou pas assez, en plus d'être un peu en perte de vitesse tandis que l'autre en gagne.)

C'était (et ça reste encore) le plus simple. Tiens, Salt a fait les mêmes choix de briques/technos…

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Il y a beaucoup de magie dans le Yaml d'Ansible, mais alors vraiment trop, à tel point que ce n'est pas du Yaml standard.

C'est quoi du YAML standard ??? Parce-que je n'ai pas vu ce qui est rajouté par Ansible qui serait rejeté par un validateur YAML (je passe tous mes playbooks, et plus généralement tous mes fichiers YAML sous yamllint et je n'ai jamais rien vu de non standard dans Ansible, donc j'aimerais satisfaire ma curiosité.)

Parfois on a du texte sans guillemet, et parfois il faut mettre des guillemets alors que ça ne sera pas du texte (!).

La règle c'est que tu mets le texte entre guillemets, point. YAML offre la possibilité, par mauvaise facilité de ne pas mettre de guillemets : ce que tu considères comme la règle est en fait l'exception voir une mauvais pratique parce-que tu vas faire faire des interprétations fausses…
Et si on a pris le temps de lire la foutue doc, Ansible met en garde contre ce qu'ils appellent les YAML gotchas !

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Conclure par :

Je préfère encore écrire des scripts shell…

Après s'être plaint que :

• l'idée qu'on lance les playbooks localement, sans pouvoir facilement suivre qui a exécuté quoi, avec quels diffs locaux…

Bref, n'avoir rien compris à l'affaire.
L'outil se dit simple parce-que n'imposant rien (là où Puppet par exemple impose une façon de s'organiser.) Tu peux faire des lancements locaux (et faire tout presque comme tu continuerais à faire avec tes scripts) ou tout centraliser (ce qu'il faudrait faire quand on travaille en équipe.) Forcément, comme ça contraint pas (et en cela ces fidèle à la philosophie unixienne), on a vite fait de voir des gens faire n'importe quoi puis raconter des conneries.

Même en mode perso, j'ai tous mes lancements qui sont journalisés (c'est une bête ligne de configuration qui n'est pas imposée.) Et quand je doit utiliser Ansible en entreprise je demande qu'il y a un serveur commun d'administration (à défaut d'avoir un AWX) où j'active cette journalisation.

Pour les diffs locaux, ça fait des lustres qu'il y a l'option --diff à côté duquel tu es visiblement passé. Partout où je suis passé, je l'ai toujours manqué dans la documentation qui va bien (tout les playbooks n'en ont pas besoin mais pour certains j'estime qu'il faut et c'est consigné noir sur blanc.)

• sa syntaxe (coder en yaml… faut être maso),

Cette mécompréhension fait qu'on appréhende l'outil de la plus mauvaise manière qui soit. Ce n'est pas du codage mais de la description : il faut se le répéter jusqu'à ce que ça rentre sinon on va faire et dire n'importe quoi. Tu décris des états, tu ne les codes pas (enfin, tu codes si tu écris toi-même les modules sous-jacent.)
La documentation (bien qu'exécutable, d'où la comparaison avec les recettes) n'est pas du code (ni de la littérature remarque.) On décrit des étapes et non la mécanique sous-jacente (si on veut vraiment faire l'analogie avec la programmation, c'est du descriptif comme SQL ou Prolog et non de l'impératif comme Java ou Rust ou Haskell ou même tes scripts shell…)

Et on était contraints de compléter ansible par des scripts qui remplissaient de l'inventaire automatiquement : sans ça, impossible de représenter proprement une ressource de plus haut niveau (les clusters PostgreSQL dans mon cas)

Ce n'est pas un gestionnaire d'inventaire, au contraire ça s'appuie sur un inventaire. Ceci dit, j'ai déjà fait des playbooks pour mettre à jour divers types d'inventaires.)
J'ai l'impression que vous avez passé le temps à utiliser des outils sans vraiment les comprendre, ce qui est vraiment dommage. (ça s'applique à tout, même aux scripts shells : les gens qui viendront juste les lancer sans comprendre ce qu'ils/elles font iront aussi de ce genre de réponses.)

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Et les logs "tout sur la même ligne avec des \n au milieu", une horreur à lire.

Bah, c'est du vrai format JSON (et oui, c'est une horreur à lire mais le couple n'est pas Ansible pour le coup.)

Perso, j'utilise le callback plugin YAML (et oui, on tape dessus pour la forme mais c'est prévu pour être lu par des humains…)

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Tout à fait. Ce n'est pas juste pour remplacer les scripts (comme j'ai lu ailleurs) mais aussi un cadriciel .

Maintenant, pour en revenir à la collection de facts on (les programmes qui sont instruits dans ce sens) peut en poser de brutes (ce sont juste de fichiers JSON avec l'extension .fact) ou de dynamiques (fichiers de scripts exécutables avec l'extension .fact et renvoyant du JSON)
https://www.tecmint.com/ansible-variables-and-facts/
https://docs.ansible.com/ansible/latest/collections/ansible/builtin/setup_module.html#parameter-fact_path
OpenShift, par exemple, fournit ce genre de « custom facts »

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

(toutes les yourtes que j'ai vu en photo prennent beaucoup d'espace, se déplacer a donc plus de coût financier et écologique qu'un quartier avec des immeubles en RE 2020)

Quand on parle de pouvoir se déplacer, ne devrait-on pas plutôt comparer aux : caravanes, tinyhouses, camions mobilehomes, etc. ?

Ceci dit, faut-il continuer à s'agglutiner comme des sardines (ou des poules de luxe) créant de fait des surpopulation localisées alors qu'en terme de ration par rapport à la surface habitable il y a de quoi faire ? Ce n'est qu'une question philosophique, pas une colle ni un débat. Je n'ai moi-même pas de réponse.

(édition) PS : Merci pour les liens.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Encore que je ne vois pas pas pourquoi on parle d'un « nouveau motus » vu que les règles sont différentes (il y a sur le site un jeu par jour et non plusieurs manches qui opposent deux adversaires et il n'y a ni présentateur ni boule noire sur le site.)
Ils vont poursuivre aussi le New York Times pour Wordle ? Ou c'est plus simple de taper sur les petits gens qui se bougent et en plus n'en vivent même pas.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume