Quels paramètres sont indispensables pour qu'ansible respecte son principe de pouvoir lancer les playbooks à l'infini ? creates et removes. Ils sont optionnels, et guère mis en avant alors qu'ils méritent a minima une place dans le synopsis, voire un warning du type :
if creates is None and removes is None and register is None:
logging.warn("tu fous quoi là ?")
Quand toute une boite utilise un outil, y'a deux options :
- croire que tout le monde apprendra à bien l'utiliser
- avoir un outil contraint
À $job-1, ansible était déjà là, mais l'option 1 n'a jamais été approuvée, «it works don't fix it» (grosso modo). Et ça semble être la norme plus que l'exception en entreprise, ce qui me fait envier l'option 2, la contrainte, ou l'option 1 avec des outils dont la courbe d'apprentissage est un mur dans la face.
[^] # Re: il faudrait le réécrire <s>en Rust</s> !
Posté par Pinaraf . En réponse au journal Test de vie et Ansible : un exemple de réalisation pour mieux comprendre l'outil. Évalué à -1.
J'oubliais de te remercier pour ton mépris.
Prenons une page de la doc :
https://docs.ansible.com/ansible/latest/collections/ansible/builtin/command_module.html
Quels paramètres sont indispensables pour qu'ansible respecte son principe de pouvoir lancer les playbooks à l'infini ? creates et removes. Ils sont optionnels, et guère mis en avant alors qu'ils méritent a minima une place dans le synopsis, voire un warning du type :
Quand toute une boite utilise un outil, y'a deux options :
- croire que tout le monde apprendra à bien l'utiliser
- avoir un outil contraint
À $job-1, ansible était déjà là, mais l'option 1 n'a jamais été approuvée, «it works don't fix it» (grosso modo). Et ça semble être la norme plus que l'exception en entreprise, ce qui me fait envier l'option 2, la contrainte, ou l'option 1 avec des outils dont la courbe d'apprentissage est un mur dans la face.