Gil Cot ✔ a écrit 6272 commentaires

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.

Je préfère déjà :-D Ce n'est plus Y est râté et P est mieux alors qu'ils font la même.

Et pour le coup une syntaxe ouvrante/fermante est plus lisible (même si parfois marginalement).

Qu'entends-tu par « syntaxe ouvrante/fermante » ? Les formatages à la C par oppositions aux formatages par indentation ?

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.

Ansible est allé dans ce sens avec les roles et différentes include…
Mais intrinsèquement, les structures de données sont complexes et les host_vars/group_vars permettent un certain découpage (et pourtant je continue à en voir qui foutent tout dans un fichier d'inventaire ini qui contient déjà une ou deux centaines de machines)

[…] Et là parfois tu te demandes bien pourquoi tu n'es pas en train de coder directement en Python.
[…] Est moins évidente, mais permettrait d'éviter la « programmation en Jinja2 ».

C'est souvent que le problème est mal posé ou son approche l'est. (Parfois j'ai l'impression que les gens pratiquent le « pourquoi faire simple quand on peut faire compliqué ? » et c'est encore plus vrai quand on se met martèle en tête que Ansible est un langage de programmation …sauf que là c'est le début du masochisme)
Mais il y a des cas effectivement pas simples qui indique qu'on a atteint les limites d'Ansible de base : il faut soit créer ses propres modules ou y aller directement dans le langage qu'on maîtrise, sinon on fait des playbooks difficiles à maintenir et qui en plus vont rapidement vous péter au visage.

Dans ton exemple, il n'y a pas de Jinja2. Et l'alternative que tu préconises, indique que tu as plutôt besoin de Fabric ou Nuka ou similaire.

Je suis bien d'accord avec ce qui suit :

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.

C'est d'autant plus dommage que l'utilisation d'Ansible ne t'enferme pas, et que l'esprit unixien veut qu'on utilise l'outil qui va bien dans l pléthore qu'on a à disposition. C'est toujours une erreur de faire une fixette sur un outil spécifique.

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 ?

Il y a un besoin qu'il rempli bien et il n'y a pas de raison de changer cela. Pourquoi vouloir que ça fasse le boulot d'autres outils ? On doit arrêter avec les fixettes windowsienne ; la seule évolution que j'attends perso de ces diverses solutions est qu'elles puissent (mieux) communiquer entre elles de sorte à pouvoir être complémentaires.

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

Un linter qui va avec ça.

Je l'ai mentionné dans un autre commentaire :

pip install yamllint
# c'est générique et servira pour tout YAML qu'on trouve ci et là
# par défaut c'est assez strict et je ne pense pas que l'exemple passe
pip install ansible-lint
# c'est très laxiste sur le YAML, comparativement à l'autre
# ça vérifie les bonnes pratiques émises au fil du temps

Je mets ça en place aussi dans mes CI/CD.

Bref quand on superpose des syntaxes existantes, on obtiens pas le meilleur de chaque monde, mais le pire. On crée un nouveau format qui n'est que partiellement pris en charge un peu partout et cette prise en charge partielle et par effet goodenought ralenti fortement l'émergence d'outils agréables à utiliser.

Je dis justement que ça ne ralenti par certaines personnes (comme moi qui ne recherche pas de syntaxe particulière) mais sinon c'est bien une nouvelle syntaxe…
On peut faire le même parallèle pour DocBook et d'autres comparé à XML au sens générique. J'ai des collègues qui ont du mal parce-que n'ayant pas de syntaxe spécifique alors que moi non.
On peut faire le même parallèle pour tous les DSL (aussi bien celui de Puppet que celui de Structurizr avec lequel je travaille actuellement.)

Et non la solution n'est pas de tripatouiller les fichiers de syntaxes de ton éditeur, tu va avoir un truc qui marchote plus ou moins. La solution c'est d'utiliser le LSP proposé par le projet, mais voila son développement n'a commencé que l'an dernier pour un projet qui a 10 ans.

Ça revient au même pour moi. Si tu utilises lsp, bah il faut créer les fichiers de syntaxe lsp (ou attendre que quelqu'un fasse le tripatouillage pour toi.)
Ensuite j'ai donné des exemples pour Vim qui ont cinq à sept ans d'existence.

En tout cas si je regarde les playbook les mieux notés d'ansible galaxy, ils appliquent tous la règles "on ne quotes que les chaines pour les quel c'est nécessaire". Bon est pour aller plus loin encore c'est aussi la règle qui est utilisée dans le dépôt de playbooks servant à illustrer les bonnes pratiques pointées par la doc d'ansible comme quoi.

La « bonne habitude » est de « juste mettre les quotes pour les chaînes de caractères. » Beaucoup d'erreurs auxquels j'ai répondu sur le forum étaient juste liées à ça : on a pris le raccourci autorisé par YAML et on n'a pas compris ce qui a merdé. Que de temps perdu en n'ayant pas fait les choses correctement dès le départ ?

Quel est le problème avec l'indentation ?

Seconde et troisième lignes (« become: yes et tasks: ») ; ça m'a piqué les yeux …et ça rend l'interprétation ambigüe (est-ce bien au même niveau que hosts: webservers ou au niveau de l'élément de liste - hosts: webservers ? certains diront qu'il y a une espace, mais comme pour Python il est mieux d'avoir un nombre paire d'espaces et surtout le même partout hors on en est à 2 sous tasks…)

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

Comme tu dis les noms sont trompeurs et ma remarque est qu'on devrait fuir tous ces flous artistiques/politiques (donc bannir toutes les universités américaines si c'est leur cas). Pourquoi ne pas juste appeler un chat un chat et donc parler de legal comity ? Utiliser le mot éthique là où il n'y en a point (que du juridique et de l'image marketing) c'est du même acabit que le green washing et ces manipulations ne devraient pas avoir leur place en sciences…

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

De plus, POSIX demande un compilateur C99, aujourd'hui on est bientôt à C23, ce serait dommage de rester sur des anciennes versions juste pour être 100% POSIX compliant.

C'est pas une lecture un peu biaisée ? Et justifiée par la course à la nouvelle ? :-)
POSIX n'impose pas de version/marque/éditeur de compilateur, et ne peut pas demander d'utiliser qu'un compilo C99. Tu peux utiliser C23 ou plus ; c'est juste que tu dois pouvoir compiler avec tout compatible C99 (cela inclus ta nouvelle version de compilateur si elle n'a pas cassé la compatibilité) pour être 100% POSIX.

Une bonne partie des développeurs sensés activent tôt ou tard les warnings (options -W de gcc/clang) qui n'est évidemment pas couvert par POSIX et donc ton utilisation non portable.

Tu sous-entends que, pour toi, les avertissements du compilateur sont incompatibles avec POSIX ? Le but n'était pourtant pas d'avoir une liste figée d'options mais d'avoir un minimum syndical qui fonctionne de manière identique (bien sûr, quand on veut faire portable on se retient d'utiliser des choses qui ne le sont pas, mais de là à conclure que la norme dit que ça ne doit pas exister ça me laisse sans voix.) :-)

POSIX stipule l'option -o de disponible donc quiconque voulait un nom de fichier prédictif devrait l'utiliser de toute manière.

L'un n'empêche pas l'autre et il y a (malheureusement) un nom par défaut stipulé. Il faudrait appeler à une évolution dans la prochaine évolution de POSIX au lieu de juste dire que aux gens qui suivent les règles que ce n'est pas recevable.
Ceci dit, on devrait effectivement/explicitement faire -o a.out (je me méfie toujours des choses implicites car elles peuvent casser et faire perdre du temps) ; sauf que ça n'empêche pas la problématique actuelle de demeurer. :-)

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

La doc d'introduction met l'accent sur la facilité de prise en main …ce qui peut être au détriment des bonnes pratiques :-S Probablement le prix à payer pour la bonne affiche (j'allais dire « pour être vendeur » avant de me rappeler que ce n'est pas vendu), en tout cas on ne cherche pas à décourager par certaines considérations.

Ainsi, je ne trouve pas très propre le YAML qui devrait ressembler plutôt à

- hosts: "webservers"
  become: yes
  tasks:
    - name: "install Apache server"
      yum:
        name: "httpd"
        state: latest

On va dire que je chipote, mais :

• Avoir une indentation correcte et cohérente est, comme avec Python, plus facile à lire et limite les erreurs.
• Il faut, systématiquement mettre les chaînes entre « quotes » pour ne pas donner l'impression comme on l'a vu que tantôt il en faut parfois par magie ou sans raison.
• Je ne fais exception que pour différencier les mots clés de l'outil : "latest", "directory", etc. Par contre, dans tous les cas, en ne quotant pas "yes" je différencie bien le booléen de la chaîne de caractères (et certains linters veulent même qu'on utilise carrément "true" et rien d'autre)
• Utiliser "latest" montre bien que l'outil n'impose rien et qu'on peut l'utiliser pour mettre à jour aussi sans trop de prise de tête, mais cette option va à l'encontre des bonnes pratiques si on veut être idempotent…

Maintenant, venons au cas de Jinja2, où encore on a marché sur les bonnes pratiques au profit de la facilité… car l'utilisation de "content" dans le module copy est vraiment à réserver au dernier recours. Et dans cet exemple précisément, on était dans un cas où il aurait fallut faire appel au module template… Tout cela illustre mon propos (l'outil est permissif, ce qui permet de le prendre en main facilement mais avec le revers de pouvoir faire aussi des choses pas proprettes…) Le « FAST » dans le titre indique que les petites violations des bonnes pratiques sont assumées et ça me va : vite fait ne peut être toujours 100% bien fait…

Je reviens au point qui préoccupe. Comme les éditeurs font de la coloration syntaxique pour du YAML c'est donc du YAML pur qui est vu et mis en évidence. Pour répondre à ton/ta besoin/demande, il faudrait rajouter une déclinaison qui serait la prise en compte du DSL… Pour faire une analogie, quand tu ouvres un document XHTML dans un éditeur qui le voit comme du XML, ça va certes reconnaitre qu'il y a des balises et des attributs et pouvoir indiquer les imbrications etc. Mais contrairement à un éditeur HTML pur, ça ne reconnait pas la sémantique qui lui permettrait de distinguer les balises valides des balises farfelues, et reconnaître proprement JS et CSS dedans. C'est exactement ce qu'il manque avec la prise en compte de Jinja2 dans du YAML (et c'est valable aussi si on utilise quelque autre mécanisme : j'ai perso déjà eu à faire des modèles YAML avec des variables shell mais les éditeurs ne savaient pas mettre ces intrus en évidence.)
Je pense/espère que l'éditeur que tu utilises te permets de définir assez facilement ton fichier de coloration syntaxique. Auquel cas, il te faudra partir de celui du YAML et adapter jusqu'à obtenir ton bonheur. Perso, j'utilise essentiellement Vim mais n'ayant pas eu le besoin, je n'ai pas spécialement creusé la question. Je trouve cependant pearofducks/ansible-vim et chase/vim-ansible-yaml (ou erikzaadi/vim-ansible-yaml entre autres) qui mettent en évidence des éléments du DSL. Je n'ai pas testé car je reste plus avec le fonctionnement de base et quelques réglages. Il y a divers approches avec cet éditeur (on parle par exemple de rocannon/vim-assimilate/vim-polyglot par exemple.)

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

Mais le lectorat ici aurait râlé et se serait senti trompé si on avait parlé de PF ; pas simple la vie.

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

Ce que tu décris indique que c'est une université et des gens à bannir de partout …parce-que le comité d'éthique est plutôt un commité juridique, et que quand bien même on teste un human workflow on se cache derrière le fait de faire de la technique.

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

Je te confirme que tu as bonne mémoire pour AIM d'AOL, je ne sais plus pour ICQ de Mirabilis.
Je confirme aussi que Google a été moteur (probablement ce qui a motivé d'autres à faire des expérimentations ?) et a contribué Jingle (si j'ai bonne mémoire) puis s'est effectivement suicidé. Bizarrement, les autres ne veulent pas en tirer les bonnes leçons…

Pour le dernier point (sur les specs des autres services) tu soulèves un point crucial que je n'avais pas anticipé. En tout cas, pour la partie technique, XMPP permet déjà d'être concrètement et réellement interopérable et le reste n'est qu'excuses…

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

On est d'accord si tu ne le demandes pas toi-même. :-)
Maintenant que tu découvres sshpass, tu vois qu'il n'y a pas de raison de ne prendre que la moitié de la lib (enfin c'est caricatural mais tu vois ce que je veux dire.) ;-) Faut juste bien insister que l'outil ne gère pas le prompt et doit fonctionner sans cette interruption.

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

Tout à fait ça. Et c'est d'autant plus pervers que nombre d'usagers, si j'en crois les commentaires sur HN, finissent par claquer la porte pour ces concurrents justement. Ici, on a des projets qui ont plein d'usagers/comptes pour seulement une poignet d'actifs et du fait de la politique de facturation de Gitlab sont en train de songer à passer à Github… Beaucoup qui avaient franchi le pas lors du rachat par µ$ sont en train de le regretter et de vouloir faire demi-tour.
Ton commentaire me fait dire qu'on sait ce qu'il faut faire mais qu'on préfère la vision à court terme…

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

Ce n'est pas faux. Je pointais surtout du doigt le fait qu'au lieu d'aller dans le sens de la standardisation, la tendance était plutôt de s'enfermer et de rompre l'interopérabilité de trucs ouverts (puis de crier que ça marche pas…)

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

Si il y a besoin de réduire quand la boite grandit, ça va donner quoi quand la croissance va retomber.

Comme là ?
Faut toujours se gaver avant que ça tombe …comme Mandriva une fois côté.

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

Feux Facebook Messenger (je présume vu que l'entreprise tente plutôt de pousser Whatsapp mais peut-être que ça survivra) et Google Talk (qui a fait place à Hangout qui est en train de virer à autre chose) par exemple (et il y en a plein d'autres comme ça) ont bien utilisé XMPP à un moment, preuve que ça marche ou peut marcher… Mais une fois qu'ils estiment avoir assez de poids (de compte dans leur réseau, chez eux) ça commence à saboter l'interopérabilité puis par la supprimer. Assurément le problème n'est pas technique (au pire il leur suffirait d'ouvrir les specs de leur proto qui est si bien et mieux pour que d'autres puissent se joindre à eux pour un monde meilleur.) Il faut arrêter de gober ou servir l'excuse technique alors qu'il s'agit purement de choix idéologiques et financiers.

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

[troll]
On y vient tout doucement, depuis le temps que j'attends que la discussion semi philosophique dérive façon scientologie quantique
[/troll]

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

C'est le contraire :
il ne faut pas voter, même par hasard, pour des assoiffé(e)s de pouvoir (et qui donc s'avèrent toujours aptes à la dictature) ;
il faut rechercher la personne qui fera le boulot (c'est vrai qu'en France on en est loin vu que le vote est pour une tête et non un programme, et qu'en prime on vote plutôt contre quelqu'un depuis des décennies.)

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

Il y a toujours des candidats… Juste la façon de découvrir et choisir les candidats qui change : ici, la candidature n'est associé au volontariat mais à la recherche d'adéquation entre le poste et son occupant(e), mais en prime on se refuse par tout volontariat motivé par l'appât du pouvoir (ou du gain dans une entreprise.) En somme, comme dans certains pays plus au nord, les élu(e)s sont des fonctionnaires et non des psychopathes qui ont un agenda personnel qui ne cadre pas avec le bien commun. (les mêmes, en effet, qui mettent en place l'arsenal pour se faire rembourser une campagne de mensonges qui ne devrait pas avoir lieu d'être.)

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

C'est le coup de la mère qui ressemble à la fille ça.

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

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