Fichiers identifiés dans la description :

• lib/ansible/modules/system/group.py

Si ces fichiers sont inexacts, veuillez mettre à jour la section component name de la description ou utilisez la commande de bot !component .

cliquez ici pour l'aide du bot

cc @sfromm
cliquez ici pour l'aide du bot

J'ai commencé à recevoir cet avertissement, mais je n'ai trouvé aucune référence dans le guide de portage et aucune référence sur la manière ou les éléments à corriger.

la plupart de mes avertissements proviennent de ec2.py, où l'instance_id utilisait le - (par exemple : i-033f62b586143dff7 ) et les régions (par exemple : eu-central-1c ) , nous n'avons donc pas vraie solution pour ceux-ci

Enfin, cela a cassé certains de mes playbooks, où j'ai utilisé when: ansible_hostname in groups['varnish'] et le ansible_hostname est varnish-eu-central-1c-001 .
Dans le passé, cela fonctionnait bien, maintenant je dois utiliser inventory_hostname pour obtenir varnish_eu_central_1c_001 et obtenir un match contre le groups['varnish']

Cela nécessite donc au moins et de toute urgence un avertissement dans le guide de portage indiquant que inventory_hostname et groups[] peuvent renvoyer des données différentes

Quel était le raisonnement derrière la suppression du tiret des noms de groupe ? J'ai vraiment du mal à trouver une bonne raison à cela, d'autant plus que cela nécessitera beaucoup de refactorisation du code.

@ssbarnea D'une part, nous faisons un effort pour autoriser uniquement les noms de variables et autres clés similaires, qui sont des identifiants Python valides. Pour expliquer un peu plus les noms de groupe, cela pose un problème aux utilisateurs qui essaient d'utiliser la "syntaxe à points" telle que groups.foo-group , qui ne fait pas ce que l'utilisateur attend. Le nombre de problèmes et de demandes d'assistance causés par de petits problèmes comme ceux-ci nous a amenés à rechercher des noms de sécurité pour nous assurer que de tels problèmes ne se produisent pas.

Ceux qui souhaitent conserver ce que nous considérons comme des caractères invalides peuvent désactiver cette fonctionnalité.

Que devons-nous faire pour désactiver cette fonctionnalité ? Nos scripts de déploiement Ansible locaux sont jonchés de noms de groupes contenant des tirets. Nous ne les utilisons pas avec la notation par points, bien sûr. Mais les changer tous serait une tâche vraiment monumentale. Je préférerais me retirer et en même temps encourager mon équipe à éviter d'utiliser des traits d'union à l'avenir et, si possible, à convertir les traits d'union en traits de soulignement, bien que cette dernière partie ne soit pas toujours aussi simple qu'il y paraît.

Alors, met-on simplement force_valid_group_names = false dans ansible.cfg ? Cela semble juste basé sur https://github.com/ansible/ansible/commit/d241794daa6d413e6447890e2a4f11e0d818cf0e#diff -fd24ad93fbc32f454761746c1ac908f2

Que devons-nous faire pour désactiver cette fonctionnalité ? Nos scripts de déploiement Ansible locaux sont jonchés de noms de groupes contenant des tirets. Nous ne les utilisons pas avec la notation par points, bien sûr. Mais les changer tous serait une tâche vraiment monumentale. Je préférerais me retirer et en même temps encourager mon équipe à éviter d'utiliser des traits d'union à l'avenir et, si possible, à convertir les traits d'union en traits de soulignement, bien que cette dernière partie ne soit pas toujours aussi simple qu'il y paraît.

Alors, met-on simplement force_valid_group_names = false dans ansible.cfg ? Cela semble juste basé sur d241794#diff-fd24ad93fbc32f454761746c1ac908f2

export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=never ou export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore -- ce dernier n'est pas encore dans la doc : https://github.com/ansible/ansible/pull/57318

Merci Jacques. Étant donné que les gens abordent ce problème pour suivre le message d'avertissement, j'inclus des informations qui, selon moi, peuvent être utiles :

Pour désactiver la transformation automatique du nom de groupe ≥2.10 de manière plus portable/permanente jusqu'à ce que vous soyez prêt à supprimer les groupes non valides de votre inventaire, ajoutez force_valid_group_names = never à la section [defaults] INI de ansible.cfg .

Pour voir tous les groupes et caractères invalides qui déclenchent l'avertissement (peut-être pour que vous puissiez les cibler pour une élimination progressive), vous pouvez faire quelque chose comme ce no-op de CLI ansible :

ansible-inventory -vvvv --host=localhost 2>&1 | grep replacing

Ces caractères invalides sont (au 04/06/2019) définis comme une constante, INVALID_VARIABLE_NAMES , dans :
https://github.com/ansible/ansible/blob/devel/lib/ansible/constants.py#L119
comme '^[\d\W]|[^\w]' ,
c'est-à-dire : any leading non-alpha character OR any character other than alpha-numeric and underscore .
(j'espère avoir bien compris)

Si vous trouvez les avertissements de dépréciation ennuyeux, vous pouvez également les désactiver définitivement pour toute commande ansible- ou la commande ad-hoc ansible en ajoutant deprecation_warnings = False au même [defaults] de ansible.cfg , mais je vous le déconseille (puisque vous risquez de manquer des nouvelles importantes), et utilisez plutôt des variables d'environnement shell en ligne comme celle-ci :
ANSIBLE_DEPRECATION_WARNINGS=False ansible-inventory --host=localhost

L'analyse d'inventaire [WARNING] s ne disparaîtra cependant pas. Il n'y a pas de configuration ou de variable d'environnement spécifique pour désactiver tous les avertissements (encore ?), mais si cela vous dérange vraiment, vous pouvez simplement envoyer tous les stderr à /dev/null (insérer les mises en garde "meilleures pratiques" ici) :

2>/dev/null ansible-inventory --host=localhost

J'espère que cela aide quelqu'un, quelque part.

Je ne trouve que les messages d'avertissement de dépréciation ennuyeux lorsqu'ils ne fournissent pas de chemin de migration. Étant donné que l'espace est limité et que la remédiation nécessitera probablement une mise à jour, je trouverais très utile de fournir des liens vers des tickets pouvant documenter des solutions, des solutions de contournement,...

Une approche comme celle-ci pourrait économiser du travail supplémentaire nécessaire pour améliorer les messages d'avertissement incomplets car nous n'aurions pas à mettre à jour le message, le rétroporter vers quelques versions en arrière.

PS. La désactivation des avertissements de dépréciation est quelque chose que je ne recommanderais à personne, peut-être seulement si un projet est déjà confronté à son destin ultime ;)

J'ai commencé à recevoir cet avertissement, mais je n'ai trouvé aucune référence dans le guide de portage et aucune référence sur la manière ou les éléments à corriger.

la plupart de mes avertissements proviennent de ec2.py, où l'instance_id utilisait le - (par exemple : i-033f62b586143dff7 ) et les régions (par exemple : eu-central-1c ) , nous n'avons donc pas vraie solution pour ceux-ci

Enfin, cela a cassé certains de mes playbooks, où j'ai utilisé when: ansible_hostname in groups['varnish'] et le ansible_hostname est varnish-eu-central-1c-001 .
Dans le passé, cela fonctionnait bien, maintenant je dois utiliser inventory_hostname pour obtenir varnish_eu_central_1c_001 et obtenir un match contre le groups['varnish']

Cela nécessite donc au moins et de toute urgence un avertissement dans le guide de portage indiquant que inventory_hostname et groups[] peuvent renvoyer des données différentes

Je voudrais faire écho à la déclaration concernant l'avertissement généré par le script d'inventaire dynamique EC2 . J'ai remarqué qu'il existe un paramètre de configuration ec2.ini pour désactiver le regroupement des hôtes par instance_id ( group_by_instance_id = False ), mais un paramètre qui n'a pas résolu l'avertissement pour moi comme je l'avais prévu - je me suis assuré que je vidé le cache d'inventaire local.

Des solutions de contournement pour l'inventaire dynamique EC2 en particulier ?

Ces caractères invalides sont (au 04/06/2019) définis comme une constante, INVALID_VARIABLE_NAMES , dans :
https://github.com/ansible/ansible/blob/devel/lib/ansible/constants.py#L119
comme '^[\d\W]|[^\w]' ,
c'est-à-dire : any leading non-alpha character OR any character other than alpha-numeric and underscore .
(j'espère avoir bien compris)

Cela me semble exact. Vous devez soumettre un docs PR avec cette information.

Si vous trouvez les avertissements de dépréciation ennuyeux, vous pouvez également les désactiver définitivement pour toute commande ansible- ou la commande ad-hoc ansible en ajoutant deprecation_warnings = False au même [defaults] de ansible.cfg , mais je vous le déconseille (puisque vous risquez de manquer des nouvelles importantes), et utilisez plutôt des variables d'environnement shell en ligne comme celle-ci :
ANSIBLE_DEPRECATION_WARNINGS=False ansible-inventory --host=localhost

Cependant, l'analyse d'inventaire des [WARNING] s ne disparaîtra pas. Il n'y a pas de configuration ou de variable d'environnement spécifique pour désactiver tous les avertissements (encore ?), mais si cela vous dérange vraiment, vous pouvez simplement envoyer tous les stderr à /dev/null (insérer les mises en garde "meilleures pratiques" ici) :

L'option ignore fournit cette fonctionnalité. Docs PR ici : https://github.com/ansible/ansible/pull/57318

À partir de la version 2.8.2, cet avertissement d'obsolescence sera écrasé si vous définissez explicitement l'un des choix.

Où l'équipe de développement d'ansible discute-t-elle de ce type de décisions ? Il est très difficile pour nous, utilisateurs, de comprendre le raisonnement. S'il s'agit d'un pur raisonnement de "style python", plutôt que d'un raisonnement pratique, cela pourrait valoir la peine d'être reconsidéré ? Si un tiret dans les noms de groupe casse des choses dans les futures versions d'ansible, cela pourrait plutôt être un problème avec la mise en œuvre, plus que le nom d'un groupe ?

Pour moi, cela ressemble plus à un changement cosmétique qu'à quelque chose qui a été bien pensé.

Un nom de groupe n'est pas un nom de variable, c'est son contenu. Un trait d'union/tiret n'est qu'un caractère, qui s'avère également être un moyen extrêmement populaire de regrouper des informations dans une convention de dénomination. Comparé au point d'exclamation ou à l'étoile, il n'a pas de signification particulière dans une clause limite.

Le coût pour atténuer ce problème est énorme, étant donné que des milliers de sites doivent non seulement changer les noms de groupe dans les inventaires, mais aussi passer en revue tous leurs playbooks et rôles locaux, et les tester à nouveau.

S'il y a un moyen pour les "paysans" de faire entendre leur voix, j'aimerais donner mon avis et essayer de comprendre comment cette idée est née.

J'ai fini par comprendre que le changement a été apporté à ansible parce que les utilisateurs ont fait des erreurs telles qu'essayer d'utiliser groups.group-name plutôt que groups['group-name'] . AIUI, c'est un changement dans le seul but de réduire les problèmes de support. (Je suis personnellement opposé au changement.)

L'ancien comportement ne disparaîtra pas ; il deviendra simplement indisponible sans choisir explicitement l'ancien comportement.

Triste d'entendre.

Mon cas d'utilisation est que j'intègre la commande "ansible-inventory" dans un fichier Vagrant, d'une manière où il est impoli de mettre les choses dans ansible.cfg, et qu'il serait utile de pouvoir remplacer le comportement en tant qu'option de ligne de commande (pas de variable d'environnement).

Habituellement, de tels changements sont dus à de bonnes intentions, mais peuvent ne pas toujours conduire au résultat que l'on a en tête.

Mon problème avec ce changement est que les noms de groupe deviennent maintenant quelque peu "spéciaux" - les tirets sont autorisés dans les noms d'hôte, mais pas dans les noms de groupe, ce qui le rend un peu étrange compte tenu du début d'un playbook dans la section hosts: Je pourrais écrire des noms d'hôte et/ou de groupe.

L'explication donnée par @sivel est-elle vraiment la seule raison de ce changement ? Qu'en est-il de hosvars['foo-host'] alors ? J'espère que personne n'envisage de faire des tirets des caractères invalides dans les noms d'hôte d'inventaire également...
Outre hostvars il existe une tonne d'autres exemples où la "notation par points" ne peut pas être utilisée, il faut donc savoir quand utiliser quelle forme restera. Je trouve plutôt arbitraire de distinguer les noms de groupe.

Bien que l'argument de la notation par points soit une excuse quelque peu valable, je ne vois pas cela résoudre vos problèmes de support sans améliorer la documentation. Si vos utilisateurs font quelque chose de stupide, votre documentation n'est pas adéquate. Tout ce que les développeurs ont réussi à faire, c'est s'aliéner beaucoup d'utilisateurs. Les noms de groupe que je considère comme des valeurs de chaîne arbitraires. Honnêtement, restreindre aux caractères alphanumériques et aux traits de soulignement est un peu pénible, en particulier lorsque les RFC du nom d'hôte autorisent les tirets, les points, etc. Si les traits de soulignement étaient la norme de facto pour les conventions de nommage, je ne pense pas que ce serait un problème. Les tirets sont largement utilisés pour les chaînes de descripteurs. Si vous souhaitez réduire votre volume d'assistance, essayez de résoudre le problème de la notation par points dans une autre direction ; créez un script de validation que vos équipes de support peuvent fournir qui vérifie les problèmes de meilleures pratiques et fournit des avertissements ou des conseils à titre d'exemple. Mettez à jour votre documentation sur la mise en garde par points pour qu'elle soit grande, en gras, rouge, clignotante, peu importe... De tels cas d'assistance finissent par être des appels d'une minute si votre documentation couvre déjà le problème. Répondez au téléphone, voyez le problème, fournissez le lien doc, c'est fait.

Les tirets dans les noms de groupe sont à la fois un INI valide et un YAML valide, je ne vois pas pourquoi, en tant qu'utilisateur, je devrais renommer tous mes groupes simplement parce que les noms ne peuvent pas être utilisés comme noms de variables Python ?

Remettant également en question la justification de cette décision de déprécier - dans les noms de groupe. Ne pas pouvoir utiliser de tirets dans l'inventaire dynamique keyed_groups était déjà assez ennuyeux, mais devoir renommer tous nos groupes dans nos fichiers d'inventaire et les commandes ansible-playbook -l ... juste pour éviter d'hypothétiques problèmes de support liés à la syntaxe est ça va être douloureux.

FWIW, nous avons une convention pour nommer les groupes de rôles comme foo_server , et les groupes d'hôtes comme foo-dev ou foo-test . Presque 100% de notre utilisation d'Ansible est constituée de commandes telles que ansible-playbook -l foo-dev , ce changement demandera donc beaucoup d'efforts pour lutter contre la mémoire musculaire.

Je ne sais pas si l'ajout d'un autre moi 2 ici encouragera un renversement de cette décision spécifique, mais j'ai tendance à être d'accord avec les détracteurs de l'exigence selon laquelle les noms de groupe doivent être des identifiants Python valides.

Veuillez prendre en charge les traits d'union avec les lettres, les chiffres et les traits de soulignement dans les noms de groupe (mais je n'ai rien contre les points non plus) !

Nous utilisons beaucoup de tirets dans les noms de groupe. Les deux pour regrouper des noms comme celui-ci :

[server-3x]
server-31.example.com
server-32.example.com
server-33.example.com

et à _abuser_ l'inventaire pour conserver la liste des hôtes au même endroit (au lieu de conserver les noms d'hôtes dans différents fichiers var) comme ceci :

[prometheus_node-exporter_cluster1:children]
server-3x
server-5x
````
We use such groups in templates like this:

{% set _hostgroup = [_service, _job, _cluster]|join('_') %}
{% set _hostlist = groupes[_hostgroup]|d([])|sort %}
{% si _hostlist %}
{% pour l'hôte dans _hostlist %}
...
```

Nous n'utilisons pas de points uniquement pour faire des différences visibles entre les noms de groupe et d'hôte.

Le mot INVALID dans TRANSFORM_INVALID_GROUP_CHARS ne donne aucune certitude qu'il est possible de continuer à les utiliser à long terme.

Si l'intention est d'éviter d'utiliser ces caractères, il vaut mieux les appeler caractères _UNSAFE_, afficher un avertissement et laisser les utilisateurs décider s'ils voient cet avertissement ou non. Mais n'interdisez ou ne remplacez jamais ces caractères !

Les utilisateurs doivent a) désactiver cet avertissement (en utilisant un mot-clé tel que ALLOW_UNSAFE_GROUP_CHARS), b) changer leurs noms de groupe (si possible) ou c) simplement vivre avec cet avertissement. La plupart choisiront de toute façon entre les deux premières options.

Je pense également que cela est inutile, car un tiret "-" est un caractère délimiteur standard utilisé dans presque tous les types d'outils informatiques, et essayer de se conformer à une "religion" semble contraignant !!!

L'ancien comportement ne disparaîtra pas ; il deviendra simplement indisponible sans choisir explicitement l'ancien comportement.

Je ne serais pas aussi préoccupé par cette dépréciation s'il était réellement possible d'opter pour les tirets dans les noms de groupe. Cela pourrait alors être compréhensible du point de vue d'un nouvel utilisateur.

Cependant, l'avertissement de dépréciation implique que l'option TRANSFORM_INVALID_GROUP_CHARS=never va disparaître dans Ansible 2.10, et nous devrions donc commencer à renommer tous nos groupes avant la sortie d'Ansible 2.10 ?

[AVERTISSEMENT DE DÉPRÉCATION] : les paramètres TRANSFORM_INVALID_GROUP_CHARS sont définis pour autoriser les caractères incorrects dans les noms de groupe par défaut, cela changera, mais sera toujours configurable par l'utilisateur lors de la dépréciation. Cette fonctionnalité sera supprimée dans la version 2.10. Les avertissements de dépréciation peuvent être désactivés en définissant deprecation_warnings=False dans ansible.cfg.

De plus, l'utilisation du plugin d'inventaire dynamique keyed_groups force la transformation des noms de groupe, même si TRANSFORM_INVALID_GROUP_CHARS=never est défini : https://github.com/ansible/ansible/blob/db0fe4b1884e6bb9c25e970c7585abb7edd9d664/lib/ansible/ plugins/inventory/__init__.py#L45 https://github.com/ansible/ansible/blob/db0fe4b1884e6bb9c25e970c7585abb7edd9d664/lib/ansible/inventory/group.py#L39

Comportement désiré

• L'utilisation de TRANSFORM_INVALID_GROUP_CHARS=never doit continuer à être prise en charge à l'avenir

  EDIT : en lisant le code, il semble que l'intention soit de conserver TRANSFORM_INVALID_GROUP_CHARS mais de changer la valeur par défaut en always dans la version 2.10 - dans ce cas, l'avertissement de dépréciation n'est pas très bien formulé : https :/ /github.com/ansible/ansible/blob/db0fe4b1884e6bb9c25e970c7585abb7edd9d664/lib/ansible/inventory/group.py#L50

• L'utilisation de TRANSFORM_INVALID_GROUP_CHARS=never devrait faire taire l'avertissement de dépréciation

  Cela semble déjà possible avec l'option ignore : https://github.com/ansible/ansible/pull/57318

• L'utilisation de TRANSFORM_INVALID_GROUP_CHARS=never devrait également permettre l'utilisation de tirets dans l'inventaire dynamique keyed_groups

  EDIT : c'est clairement pour la compatibilité ascendante pour Ansible 2.7, qui a transformé sans condition les noms de groupe générés. Ce serait formidable d'avoir un opt-out explicite pour cela.

En ce qui concerne les noms de variables, je ne comprends pas pourquoi le format de la clé du dictionnaire devrait-il être égalisé avec la syntaxe du nom de la variable ? AFAIK aucun langage de programmation n'a une telle limitation. En Python, vous pouvez utiliser à peu près n'importe quelle chaîne comme clé de dictionnaire.

Les "groupes" ne sont-ils pas une variable de type dictionnaire et les noms d'hôte et de groupe ne sont que des clés de dictionnaire simples dans Ansible. Ce ne sont pas des propriétés ni des variables elles-mêmes ou le sont-elles ?

Je préfère interdire la syntaxe groups.foo-group que groups["foo-group"]. Si g = "foo-group", alors utilisez-vous groups.g ou groups[g] ?

Utiliser ansible.cfg [default] force_valid_group_names = ignore ou export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore ne semble pas fonctionner sur Ansible 2.8.1. Il donne toujours l'avertissement de dépréciation.

$ ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore ANSIBLE_VAULT_PASSWORD_FILE=vault-password.secret ansible-playbook --diff -i xyz-dev.ini xyz-infra-install.yml -l xyz-dev --check
[DEPRECATION WARNING]: The TRANSFORM_INVALID_GROUP_CHARS settings is set to allow bad characters in group names by default, this will change, but still be user configurable on deprecation. This feature will be removed in version 2.10. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.

Est-ce parce qu'il n'est pas encore répertorié dans les choices valides ? https://github.com/ansible/ansible/blob/v2.8.1/lib/ansible/config/base.yml#L1501

Utiliser ansible.cfg [default] force_valid_group_names = ignore ou export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore ne semble pas fonctionner sur Ansible 2.8.1. Il donne toujours l'avertissement de dépréciation.

$ ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore ANSIBLE_VAULT_PASSWORD_FILE=vault-password.secret ansible-playbook --diff -i xyz-dev.ini xyz-infra-install.yml -l xyz-dev --check
[DEPRECATION WARNING]: The TRANSFORM_INVALID_GROUP_CHARS settings is set to allow bad characters in group names by default, this will change, but still be user configurable on deprecation. This feature will be removed in version 2.10. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.

Est-ce parce qu'il n'est pas encore répertorié dans les choices valides ? https://github.com/ansible/ansible/blob/v2.8.1/lib/ansible/config/base.yml#L1501

Il s'agit d'un bug qui est corrigé dans la prochaine version 2.8.2. Vous pourrez export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore et cela écrasera tous les avertissements.

(L'option ignorer n'est toujours pas documentée : https://github.com/ansible/ansible/pull/57318 )

Cela va casser tout le monde. Mauvaise Décision.

Y aurait-il un moyen de raisonner les responsables à ce sujet ?

Peut-être que l'un des responsables pourrait développer un peu ici, s'il s'agit simplement d'un problème de support ou s'il utilise des constructions python qui ne fonctionnent vraiment pas ?

Je veux juste ajouter ceci assez ennuyeux et l'incapacité de vraiment comprendre le problème était également ennuyeuse, j'ai littéralement dû faire ansible-playbook "insert yaml file here" > output.txt pour comprendre le problème.

D'accord avec la plupart des affiches ici. La suppression des tirets des noms de groupe semble être une décision mal réfléchie, ou une décision de mise en œuvre et non pas sémantiquement.

Ce changement n'a absolument aucun sens pour moi. Les développeurs d'Ansible veulent forcer des milliers et des milliers d'utilisateurs à changer le nom de leur groupe simplement parce qu'ils veulent une syntaxe supplémentaire (pas manquante) pour accéder aux groupes ? C'est une blague ?

Nous utilisons des tirets et des points dans les grandes configurations.
Notre modèle est product-name.environment.datacenter et il rend les choses très claires.
Je ne peux pas imaginer laisser tomber - et . car cela rendrait l'inventaire totalement illisible.

Nous utilisons des plugins d'inventaire ansible qui interrogent la CMDB locale pour les noms de groupe qui contiennent (et contiendront toujours) des tirets. Cela casserait beaucoup de choses si cela devenait invalide à l'avenir.

Nous utilisons des tirets et des points dans les grandes configurations.
Notre modèle est product-name.environment.datacenter et il rend les choses très claires.
Je ne peux pas imaginer laisser tomber - et . car cela rendrait l'inventaire totalement illisible.

Nous utilisons une approche similaire avec un schéma de nommage hiérarchique (inspiré de Java, par exemple org.company.product-name.component).
Ce serait une horreur absolue de devoir revenir aux traits de soulignement.

il h. nous avons également été confrontés à ce problème. nous utilisons intensivement le tiret dans les noms de nos groupes.
Si l'on pouvait expliquer quel problème est dû à l'utilisation du tiret dans un dict, je serais heureux de savoir

Je répète principalement ce que d'autres ont dit, mais je voulais ajouter quelques éléments. Je pense que si ce changement est mis en œuvre, le drapeau autorisant les tirets devrait être conservé et maintenu. Bien que je comprenne que Python attend des traits de soulignement, les tirets sont couramment utilisés pour les noms d'hôtes et les noms de groupes d'hôtes. Dans notre environnement, nous générons l'inventaire de manière dynamique à partir des hôtes et des groupes d'hôtes de notre annuaire LDAP/Kerberos. Je le mentionne car bien qu'il nous soit possible de changer les noms d'hôte et de groupe, ce n'est pas préférable.

Que devons-nous faire pour désactiver cette fonctionnalité ? Nos scripts de déploiement Ansible locaux sont jonchés de noms de groupes contenant des tirets. Nous ne les utilisons pas avec la notation par points, bien sûr. Mais les changer tous serait une tâche vraiment monumentale. Je préférerais me retirer et en même temps encourager mon équipe à éviter d'utiliser des traits d'union à l'avenir et, si possible, à convertir les traits d'union en traits de soulignement, bien que cette dernière partie ne soit pas toujours aussi simple qu'il y paraît.

Alors, met-on simplement force_valid_group_names = false dans ansible.cfg ? Cela semble juste basé sur d241794#diff-fd24ad93fbc32f454761746c1ac908f2

Test sur Ansible 2.8.2, ce paramètre INI ne fonctionne pas comme prévu, je pense, cela ne fera que supprimer l'AVERTISSEMENT DE DÉPRÉCATION, alors que ce que je veux, c'est qu'Ansible utilise mes groupes avec des tirets sans se plaindre.

Voici les résultats sans :

[AVERTISSEMENT DE DÉPRÉCATION] : les paramètres TRANSFORM_INVALID_GROUP_CHARS sont définis pour autoriser les caractères incorrects dans les noms de groupe par défaut, cela changera, mais sera toujours configurable par l'utilisateur lors de la dépréciation. Cette fonctionnalité sera supprimée dans la version 2.10. Désapprobation
les avertissements peuvent être désactivés en définissant deprecation_warnings=False dans ansible.cfg.
[AVERTISSEMENT] : des caractères non valides ont été trouvés dans les noms de groupe mais n'ont pas été remplacés, utilisez -vvvv pour voir les détails

Et avec le paramètre défini sur "false" dans ansible.cfg :

[AVERTISSEMENT] : des caractères non valides ont été trouvés dans les noms de groupe et remplacés automatiquement, utilisez -vvvv pour voir les détails

Utiliser ansible.cfg [default] force_valid_group_names = ignore ou export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore ne semble pas fonctionner sur Ansible 2.8.1. Il donne toujours l'avertissement de dépréciation.

$ ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore ANSIBLE_VAULT_PASSWORD_FILE=vault-password.secret ansible-playbook --diff -i xyz-dev.ini xyz-infra-install.yml -l xyz-dev --check
[DEPRECATION WARNING]: The TRANSFORM_INVALID_GROUP_CHARS settings is set to allow bad characters in group names by default, this will change, but still be user configurable on deprecation. This feature will be removed in version 2.10. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.

Est-ce parce qu'il n'est pas encore répertorié dans les choices valides ? https://github.com/ansible/ansible/blob/v2.8.1/lib/ansible/config/base.yml#L1501

Il s'agit d'un bug qui est corrigé dans la prochaine version 2.8.2. Vous pourrez export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore et cela écrasera tous les avertissements.

(L'option ignorer n'est toujours pas documentée : #57318 )

Mais s'agit-il simplement d'écraser des avertissements, ou cela nous permettra-t-il de continuer à utiliser des tirets en groupe ?
Ce n'est pas très clair.

Je suis d'accord avec tous les détracteurs ici.

En plus de casser les manuels de jeu, cela contribue à ce que j'appelle le désordre des conventions dans ansible. Maintenant, les noms d'hôtes et les noms de groupes ont une convention différente, simplement parce que certains débutants isolés tombent sur le problème du trait d'union dans la notation par points ? Devinez quoi ? Ils tomberont encore dessus, et la fonctionnalité aura réussi à mettre les gens en colère et à ne résoudre aucun problème. Bravo.

Les noms de groupe Ansible doivent être capables de respecter la dénomination des groupes du monde réel qu'ils représentent.

Si tous les autres outils appellent un ensemble d'hôtes my-backend-service pourquoi ansible devrait-il forcer les opérateurs à le traduire en my_backend_service pour satisfaire les règles de nommage de python.

C'est un jour vraiment triste aujourd'hui. Lorsqu'un collègue de JR m'a signalé cette dépréciation, je me disais qu'il n'y avait aucun moyen que l'équipe d'Ansible soit si déconnectée de la réalité pour faire un choix aussi égoïste. J'aime absolument Ansible pour ce qu'il peut accomplir (du point de vue de l'utilisateur qui n'a ZÉRO rien à voir avec son écriture en Python). décisions rationnelles. J'espère qu'IBM va rectifier le tir..
OU
Peut-être qu'il y aura un nouvel équivalent GO brillant vers lequel nous pourrons passer.

Comme ce comportement est évidemment très controversé, je me demande si c'est une affaire conclue et cela va être mis en œuvre de toute façon ?

J'apprécierais beaucoup une réponse de la part des personnes à l'origine de cette décision et j'espère que des précisions seront apportées au-delà de "c'est une chose standard python".

Comme ce comportement est évidemment très controversé, je me demande si c'est une affaire conclue et cela va être mis en œuvre de toute façon ?

J'apprécierais beaucoup une réponse de la part des personnes à l'origine de cette décision et j'espère que des précisions seront apportées au-delà de "c'est une chose standard python".

Je suis d'accord avec toi. Tout récemment, le projet "go" s'est retiré d'une proposition impopulaire (voir https://github.com/golang/go/issues/32437#issuecomment-512035919), donc des choses comme celle-ci peuvent (et devraient parfois) être revisitées et éventuellement également reculé.

C'est aussi un sujet et des discussions intéressants, peut-être pas seulement pour ce changement de fonctionnalité. Il est difficile de comprendre comment fonctionne la gouvernance d'Ansible en tant que produit. Peut-être que quelque chose que _quelqu'un_ devrait apporter avec eux sur https://www.ansible.com/ansiblefest ?

Comme beaucoup d'entre nous se grattent la tête, ne comprenant pas comment une chaîne/contenu variable/nom de groupe de quelque manière que ce soit peut poser des problèmes avec les styles de codage python, ce serait bien d'obtenir une réponse ici des responsables, expliquant pourquoi cela poserait un problème.

Je peux comprendre s'ils veulent garder un style de codage pour les noms de variables et les structures, mais le contenu d'un tableau ou d'une variable ?

Voici une discussion rapide sur la notation par points des dicts. C'est possible, mais moche. https://stackoverflow.com/questions/16279212/how-to-use-dot-notation-for-dict-in-python

Le fait qu'il y ait des problèmes de support autour de cela est à mon avis un problème de documentation et non un problème de fonctionnalité. Si quoi que ce soit, je dirais que les noms de groupe ne devraient PAS être des variables.

De même que le fait que ce changement a été mis en œuvre avant qu'aucune documentation ne soit disponible.

Quel est l'impact de ce changement ? Dois-je éditer soigneusement tous mes inventaires ansible pour m'assurer que je n'ai pas de tirets dans les noms de groupe ?

@CMoH IMO, la meilleure solution de contournement pour le moment consiste à ajouter force_valid_group_names = ignore à votre configuration et à exécuter ansible 2.8.2 ou une version ultérieure.

@skyscooby , même ceci est un PITA. La chose qu'il n'est pas possible de mettre cette ligne par défaut dans /etc/ansible.cfg et d'utiliser local ansible.cfg dans les répertoires de playbook pour d'autres configurations. Cela signifie que tous les fichiers ansible.cfg existants doivent être modifiés.

Ou existe-t-il un moyen de configurer des valeurs par défaut globales (sans ajouter une autre variable à l'environnement utilisateur) ?

@Cougar a convenu que ce choix d'Ansible est un PITA..

Votre problème n'est cependant pas unique à ce paramètre. une raison obscure a besoin d'un paramètre spécifique, nous leur demandons d'utiliser la méthode ENV qui laisse le reste des paramètres qu'ils n'ont pas besoin de modifier aux normes de l'entreprise. Nous construisons un conteneur Docker de base avec cette configuration standard et les projets individuels ajoutent simplement des entrées ENV dans leur propre Dockerfile tout en basant leur image du conteneur ansible de base. Tout ansible est exécuté dans le conteneur, nous sommes donc certains que tous les modules pip, versions ansible et outils d'exécution sont identiques de bout en bout.

EDIT : cela nous donne également la possibilité de mettre en scène de nouvelles versions de problèmes d'ansible et de contrôle comme celui-ci avant que tout le monde dans l'entreprise ne soit touché :)

J'ai creusé.

cette fonctionnalité a été initialement ajoutée dans PR https://github.com/ansible/ansible/pull/52748 prétendument pour prendre en charge la demande de fonctionnalité https://github.com/ansible/ansible/issues/40581

une description de l'objectif : https://github.com/ansible/ansible/pull/52748#issuecomment -467976473

première version de CE symptôme (bien que cause différente) : https://github.com/ansible/ansible/issues/51844

Mec, j'ai lu #52748 tellement de fois maintenant.

D'après ce que je comprends, les noms de groupe étaient auparavant nettoyés dans les plugins et le noyau, et quelqu'un (pour une raison quelconque, car je ne comprends toujours pas pourquoi) a décidé que les noms de groupe devraient suivre les conventions de dénomination des variables python.

Donc, #52748 a poussé l'assainissement dans l'inventaire à la place, ce qui casse les choses pour tant de gens. Surtout les personnes qui utilisent des conventions de nommage intelligentes, par exemple dans AWS, Azure, etc., pour mapper les hôtes aux groupes.

Si nous devions utiliser la même convention de nommage/standard pour les noms d'hôtes, nous perdrions certainement notre élan et perdrions des utilisateurs.

Un nom de groupe est un nom, pas une variable. L'utilisation de tirets dans les noms de groupe (tout comme dans les noms d'hôte) est logique. La traduction (assainissement) ne devrait pas avoir besoin d'être effectuée au niveau de l'inventaire (par nous, les utilisateurs), et dans le meilleur des mondes en fait jamais.

Je ne vois vraiment pas l'intérêt d'appliquer cela. La discussion semble couvrir également "." et ":", que certaines personnes aiment utiliser dans les noms de groupe. Personnellement, je ne les utilise pas, mais je ne vois pas non plus l'inconvénient de le faire.

Tant que les fournisseurs de cloud utilisent des tirets dans leurs méta-informations, nous devrions pouvoir les utiliser pour le regroupement. En fait, cela ne devrait même pas être le pilote. Si j'ai envie de nommer un groupe abcde, cela ne devrait pas vraiment être un problème. C'est un délimiteur très utile.

Ce fil ne semble cependant pas attirer l'attention des développeurs ou des mainteneurs. Je pense que nous parlons à des oreilles sourdes.

Devs/Maintainers : S'il vous plaît, assez s'il vous plaît, autorisez les tirets dans les noms de groupe !

Pour clarifier certaines idées fausses, certaines d'entre elles étaient dues à mes erreurs et au fait que les messages initiaux ne sont pas clairs, les dernières versions ont des correctifs à certains des problèmes que les gens continuent de soulever ici, d'autres correctifs sont toujours en cours :

Juste pour dire ceci une fois, clairement, VOUS POURREZ TOUJOURS UTILISER DES TIRTS DANS LES NOMS DE GROUPE ainsi que des points et d'autres caractères qui sont maintenant considérés comme « invalides », mais pas par défaut. Ce "par défaut" est ce qui est déprécié, la valeur par défaut sera "sûr" en 2.11, mais vous aurez toujours une option pour "accepter" l'ancien comportement.

Et pour expliquer comment et pourquoi nous en sommes arrivés là :

Premièrement, les noms de groupe étaient TOUJOURS nettoyés, ils avaient juste des règles différentes et incohérentes, selon le type d'inventaire que vous utilisiez, les scripts étaient partout, les formats YAML et INI faisaient chacun leur propre truc. Le changement majeur était « la centralisation et la normalisation de l'assainissement », cela a été décidé en 2.4 mais n'a été totalement mis en œuvre qu'en 2.8. L'intention était de fournir une norme ou une ligne de base que tous pourraient utiliser en toute sécurité dans Ansilbe, cela dit que nous reconnaissons que de nombreuses personnes utilisent des caractères « non sûrs » ou « invalides » pour les variables, nous avons donc rendu cela configurable, non seulement globalement mais aussi par certains des plugins d'inventaire.

La mise en œuvre initiale a eu quelques problèmes et beaucoup de discussions (non, nous ne décidons pas cela en cachette, nous avons des réunions publiques en irc auxquelles vous êtes tous les bienvenus, https://github.com/ansible/community/blob/master /meetings/README.md) et de nombreux commentaires ont été intégrés (ceux-ci sont également enregistrés afin que vous puissiez revenir en arrière pour voir les discussions et le raisonnement, mais pour éviter la « plongée dans les poubelles de journal », j'expliquerai la plupart des problèmes ci-dessous) . Après la sortie de la version 2.8, nous avons reçu une autre série de commentaires et nous avons corrigé certains bogues, comme toujours une dépréciation, pas seulement lors de l'utilisation de la valeur par défaut et en particulier avec le libellé de la documentation et des avertissements.

• « Pourquoi les noms Python ? »
  Principalement parce qu'Ansible utilise Python et JInja (qui utilise également Python) et certaines utilisations de groupes (principalement dans nos premiers exemples, mais aussi de nombreux tiers) peuvent créer des erreurs dans les playbooks, c'est- stuff: '{{ groups.gropup-name-with-dash ... }}' dire group.name.with.dots . Cela crée de la confusion pour de nombreux utilisateurs qui souhaitent utiliser la fonctionnalité Jinja de « notation par points pour l'accès aux variables » et c'est pourquoi la valeur par défaut devrait être sûre pour tous les utilisateurs. La plupart des personnes sur ce post peuvent ne pas être d'accord avec cela, mais c'est un vrai problème pour beaucoup de gens et ne devrait pas être un « piège » attendant les nouveaux ou les anciens utilisateurs d'Ansible. Ceux qui se « désengagent » sont alors responsables d'éviter l'utilisation interrompue dans d'autres parties d'Ansible.

• « Et si j'aimais que chaque inventaire ait un assainissement différent ? »
  Eh bien, vous pouvez toujours désactiver l'assainissement « central » et activer celui pour votre source d'inventaire spécifique, les nouveaux plugins d'inventaire les plus populaires qui remplacent les anciens scripts ont eu des options ajoutées pour émuler le comportement du script, dans le pire des cas, vous pouvez toujours utiliser les scripts d'inventaire.

• « Pourquoi pas les noms d'hôte/les noms d'hôte sont-ils les prochains ? »
  Comme pour les groupes, la désinfection des noms d'hôtes a toujours existé, mais n'a pas changé, les noms d'hôtes ont des exigences différentes, comme être résolues par DNS
  pour les connexions réseau ou un chemin valide pour les connexions chroot. De plus, heureusement, il existe peu ou pas d'exemples d'utilisation de noms d'hôtes en notation par points, cela n'a pas été une pratique courante et deviendrait un problème si les gens commençaient soudainement à les utiliser, mais contrairement aux noms de groupe, c'est quelque chose que nous avons évité jusqu'à présent. Si cela devient un problème à l'avenir... Je ne vois pas non plus de bonne solution.

Notez que ce ticket spécifique (pas assez bonne description/information) est quelque chose que j'aborde déjà, j'espère l'avoir corrigé bientôt. Quant au reste de la discussion, les développeurs n'utilisent pas Github comme forum, certains tickets y sont liés, le ticket précédent qui est fermé et a également un long fil a été ignoré jusqu'à récemment, principalement parce que les développeurs filtrent les problèmes fermés et attendez-vous à des discussions sur IRC, la liste de diffusion ou de nouveaux problèmes.

J'espère que cela résout tous les problèmes majeurs, comme toujours, nous sommes ouverts à la discussion, n'hésitez pas à passer par ML ou IRC, nous évitons simplement d'utiliser github car ce n'est pas un bon endroit pour de telles choses.

Merci beaucoup pour l'éclaircissement.

Je vous remercie d'avoir pris le temps d'expliquer même s'il aurait été beaucoup plus simple d'arrêter de prendre en charge la notation par points et de déprécier cette prise en charge sur quelques versions. Moins de personnes l'utilisent par rapport au nombre de personnes qui ont des caractères invalides dans leurs noms de groupe. Se la vie

@skyscooby le problème est que ce n'est pas Ansible qui fait ça, c'est Jinja.

Juste pour dire ceci une fois, clairement, VOUS POURREZ TOUJOURS UTILISER DES TIRTS DANS LES NOMS DE GROUPE ainsi que des points et d'autres caractères qui sont maintenant considérés comme « invalides », mais pas par défaut.

OK, c'est bon à savoir, merci pour la précision. Cependant, l'expérience utilisateur doit vraiment être améliorée. Vous avez la "malédiction de la connaissance". Essayez simplement de vous imaginer dans la peau d'un utilisateur qui voit ceci :

[AVERTISSEMENT DE DÉPRÉCATION] : les paramètres TRANSFORM_INVALID_GROUP_CHARS sont définis pour autoriser les mauvais caractères dans les noms de groupe par défaut, cela changera, mais restera
configurable par l'utilisateur lors de l'obsolescence. Cette fonctionnalité sera supprimée dans la version 2.10. Les avertissements de dépréciation peuvent être désactivés en définissant deprecation_warnings=False dans ansible.cfg.
[AVERTISSEMENT] : des caractères non valides ont été trouvés dans les noms de groupe mais n'ont pas été remplacés, utilisez -vvvv pour voir les détails

C'est loin, très loin de

[AVERTISSEMENT DE DÉPRÉCATION] Le nom de groupe « mes-serveurs » contient « - », qui deviendra invalide par défaut à partir d'Ansible 2.11. Définissez force_valid_group_names dans ansible.cfg ou la variable d'environnement ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS sur "ignorer" pour supprimer cela. Voir https://docs.ansible.com/something pour plus d'informations.

... c'est ce que, en tant qu'utilisateur, j'aurais vraiment voulu voir. Cela m'aurait fait gagner plus d'une heure. Maintenant, multipliez par le nombre de personnes qui ont rencontré ou qui rencontreront ce problème.

Avoir des tirets et des points invalides dans les noms de groupe n'est pas une valeur par défaut sensée. Les gens les auront toujours dans leurs noms de groupe. Les obliger à définir encore une autre variable dans un fichier de configuration pour permettre un comportement raisonnable est à mon humble avis indéfendable.

Merci @bcoca pour votre commentaire ci-dessus. C'est très apprécié.

Bien que je ne sois pas satisfait de la décision, je comprends qu'une discussion a eu lieu et qu'une décision a été prise. Si la décision est encore ouverte au débat, elle doit être poursuivie sur la liste de diffusion ou sur irc mais peut ne pas saisir cette question.

Pour le sujet de ce numéro, j'aimerais trouver les informations suivantes dans la documentation officielle et les guides de portage, pour être au courant de ce changement.

• Quels sont les noms de groupe valides par défaut ?
• Que faire pour continuer à utiliser les noms de groupe, y compris les tirets, les traits d'union, les points et les deux-points ?

Parce que nous utilisons des tirets dans tous nos noms de groupe et d'hôte et nous ne changerons pas cela. Je dois donc m'inscrire et modifier mon ansible.cfg chaque fois que je configure une nouvelle installation/environnement. C'est malheureux pour moi, mais je dois y faire face d'une manière ou d'une autre. Au moins je m'attendrais à ce que cela soit documenté en conséquence.

Pour continuer la discussion si ce changement est judicieux ou non, j'ai ouvert un fil dans le groupe Ansible Development.

Meilleures salutations,
Tronde

Je tiens à remercier tous les contributeurs sur cette question. Sur la base de ce que j'ai lu ici, j'ai décidé d'écrire un article de blog https://docs.sbarnea.com/ansible/naming-hosts-and-groups -- J'espère qu'il résumera ce que les utilisateurs doivent faire.

@loop-evgeny Je conviens qu'en tant qu'équipe de base, nous avons la "malédiction de la connaissance" et cela nous empêche de créer des documents et des erreurs utiles à tout le monde. Nous comptons également entièrement sur la communauté pour nous aider à façonner ansible et à le garder simple pour autant d'utilisateurs que possible, donc lorsque les gens ont des recommandations sur l'amélioration de nos documents et de nos messages d'erreur/d'avertissement, je les encourage toujours à nous aider en envoyant un demande de tirage. Le message que vous signalez est contenu dans le fichier suivant et nous vous serions très reconnaissants si vous pouviez nous envoyer un PR avec le changement suggéré ...

https://github.com/ansible/ansible/blob/4ef2545eb5d661566e06629015967c2d1b8924e3/lib/ansible/inventory/group.py#L54 -L55

@jctanner Normalement, je serais heureux de soumettre un PR pour améliorer un programme gratuit et utile que j'utilise. Cependant, l'attitude générale des développeurs d'Ansible vis-à-vis de la convivialité, leur empressement à clore les problèmes de « fonctionnement comme prévu » que je considère comme des bogues évidents (même s'il s'agit de bogues de conception) et le fait qu'Ansible a actuellement 2025 (c'est deux mille !) open PRs me donne très peu confiance que mon travail ne sera pas perdu. Si vous voulez vraiment « compter sur la communauté », comme vous le dites, alors un changement de culture substantiel est nécessaire à mon humble avis.

Hmm.. Cette chance m'a frappé aussi.

Malheureusement, nous utilisons les noms de réseau comme noms de groupe et ce n'est pas facilement modifiable. J'adorerais désactiver le sucre de syntaxe à points pour les noms de groupe car ce n'est rien que j'ai jamais utilisé (bien que je l'utilise avec d'autres variables).

Il serait préférable d'utiliser ansible-playbook whatever.yaml -l some.network.to.use à l'avenir. L'utilisation de tout autre nom que le réseau comme nom de groupe réduirait considérablement le cas d'utilisation.

Salut,
Je suis un peu confus en ce moment. Quelqu'un pourrait-il me dire ce que je dois définir dans ansible.cfg pour autoriser les caractères invalides dans les noms de groupe à l'avenir, s'il vous plaît ?

force_valid_group_names = ignore

Quelle est la future version d'ansible regrading à ce problème ? Est-ce qu'à un moment donné, ansible rejettera tous les tirets dans le nom du groupe sans solution de contournement en utilisant force_valid_group_names ? (sans entendre les commentaires des utilisateurs qui ont souffert du changement et qui n'ont jamais souffert des problèmes en utilisant des tirets dans les noms de groupe)

Désolé Il suffit de lire les commentaires de @bcoca et je suis heureux de voir que je pourrais utiliser un trait d'union si je le souhaite à l'avenir - cela me suffit.

Salut,
Je vois le même avertissement, mais je ne comprends pas ce que je dois changer, et si nous devons le changer.
Est-ce quelque chose lié à python?
Comment résoudre ?

Si j'ignore avec force_valid_group_names = ignore, ce serait avec cela nécessaire, et quand je passerai à Ansible >= 2.10 ?

Salutations,
César Jorge

Si je comprends cela correctement. La seule chose qui est dépréciée est la transformation automatique des noms de groupe. Cela signifie qu'il devrait être tout à fait correct de définir force_valid_group_names = ignore après la 2.10 et au-delà.

Il devrait également être tout à fait acceptable de continuer à utiliser des tirets et tout ce que vous voulez dans les noms de groupe. Ce qu'Ansible ne fera pas à l'avenir, c'est de les désinfecter afin que vous puissiez utiliser la notation pointée même pour les noms de groupe « invalides ». Par exemple:

Votre inventaire contient un groupe nommé foo-bar.xyz . Maintenant, vous voulez écrire un modèle qui crée une liste d'hôtes appartenant à ce groupe :

{% for host in groups['foo-bar.xyz'] %}
{{ host }}
{% endfor %}

N'oubliez pas que la version suivante du modèle ne fonctionnerait pas :

{% for host in groups.foo-bar.xyz %}
{{ host }}
{% endfor %}

C'est parce que le - et le . ont une signification particulière dans ce cas. Cependant, la notation pointée conviendrait parfaitement si votre groupe portait le nom foo_bar_xyz car le modèle devient alors :

{% for host in groups.foo_bar_xyz %}
{{ host }}
{% endfor %}

Ce qui est bien sûr tout à fait correct.

Dans le but de faciliter les choses pour les utilisateurs, Ansible a apparemment toujours fait un peu d'assainissement pour les noms de groupe. Cela signifie qu'il était (et jusqu'à la 2.10 est toujours possible) d'utiliser foo_bar_xyz dans les exemples ci-dessus même si le groupe s'appelle en réalité foo-bar.xyz . Personnellement, je ne pense pas que cela facilite du tout les choses et il semble que l'équipe de base soit désormais d'accord avec cela.
Ainsi, leur prochaine tentative pour résoudre le problème est de rendre impossible l'obtention de noms de groupe "invalides" en premier lieu. Cependant, pour autant que je sache, il sera toujours possible de désactiver cette limitation en définissant force_valid_group_names = ignore .

Pour faire court, il s'agit en fait de deux changements différents qui se sont entremêlés[1]. D'où le nom et le libellé confus de l'avertissement.

Encore une fois, c'est seulement ainsi que je comprends le problème. Corrigez-moi si j'ai tort, s'il-vous plait!

[1] pour plus de détails, voir RFC1925 Paragraphe 2, Point (5)

Je voulais juste laisser mon 2¢ puisque je suis résolument du côté des tirets > des traits de soulignement. Juste en effectuant une recherche rapide sur

Même si ce n'était pas le cas, le fait que je vois des tirets utilisés pour des choses comme des étiquettes de serveur et des groupes dans la nature beaucoup plus souvent que des traits de soulignement signifie que ce sera encore une autre chose que je devrai m'assurer d'ajouter à tous mes et les fichiers ansible.cfg mes clients (j'ai tendance à en avoir un par playbook).

Je n'ai aucun problème avec Ansible à essayer de forcer une valeur par défaut plus stricte où cela améliore l'expérience, mais vous êtes d'abord venu pour les tirets dans mes noms de rôle (et avez parfois autorisé des exceptions singulières pour les rôles plus anciens qui étaient protégés), puis vous êtes venu pour des tirets dans mes collections (elles ne sont autorisées d'aucune manière, forme ou forme), et maintenant vous êtes venu chercher des tirets dans mon inventaire !

C'est une guerre contre les tirets là-bas... et je veux tracer une ligne quelque part - dans ce cas, c'est le seul endroit où il m'est en fait impossible d'empêcher les gens d'utiliser des tirets, car de nombreux fournisseurs d'inventaire dynamique créent des groupes basés sur sur les noms de serveurs et les étiquettes, et de nombreuses organisations (sinon la plupart) semblent étiqueter les choses à l'aide de tirets (par exemple, us-east-1a , pas us_east_1a ).

Ce n'est pas amusant d'avoir une valeur par défaut qui doit presque toujours être remplacée pour que le logiciel fonctionne, mais il semble qu'à partir d'Ansible 2.11, ce sera le cas.

Si tout cela est dû au fait que certains utilisateurs peu familiers avec Jinja2 et Python ne réalisent pas que something.with-some-dashes n'est pas valide, je dirais qu'il est préférable de leur apprendre "s'il y a des tirets, vous devriez utiliser la notation entre crochets pour l'accès dict, par exemple something['with-some-dashes'] . Vous pouvez même mélanger les deux si nécessaire. Ce n'est pas super pur et holistique, mais nous ne sommes pas tous des développeurs Rust ici...

Très bien dit, Jeff. Je suis tout à fait d'accord avec vous ici : ce changement sera tellement perturbateur et, au lieu de simplement nécessiter une migration ponctuelle, il changera le flux de travail d'un grand nombre d'utilisateurs. Ansible ne fonctionnera plus immédiatement.

Les noms d'hôte ne peuvent pas inclure de trait de soulignement, donc dans un monde sain, Inventory_hostname ne serait pas obligé de le faire. Cela signifie que nos inventaires auront désormais l'air assez incohérents, avec des noms d'hôte qui ne peuvent pas contenir de traits de soulignement et des groupes qui ne peuvent pas contenir de tirets.

S'il vous plaît, ne changez pas la valeur par défaut.

https://en.m.wikipedia.org/wiki/Hostname

Salut,
Je suis tout à fait d'accord avec Jeff ici .

Mais comme @bcoca l'a indiqué ci-dessus, la plupart des développeurs ne consultent pas régulièrement ces discussions ici et ce problème n'est peut-être pas le bon endroit pour discuter du changement car il s'agit de la bonne documentation.

Pour discuter, veuillez rejoindre le fil de discussion. Est-ce que changer le paramètre par défaut de TRANSFORM_INVALID_GROUP_CHARS est une bonne idée ? dans Google Groupes.

Grands points Jeff.

Ce n'est pas amusant d'avoir une valeur par défaut qui doit presque toujours être remplacée pour que le logiciel fonctionne, mais il semble qu'à partir d'Ansible 2.11, ce sera le cas.

C'est le gros point à retenir pour moi de toutes ces discussions. Je comprends le problème qui doit être résolu, mais la solution semble être le contraire de ce qui est nécessaire. Cela rend les choses plus faciles pour le support mais difficiles pour les utilisateurs - c'est une solution à l'envers.

Si tout cela est dû au fait que certains utilisateurs peu familiers avec Jinja2 et Python ne réalisent pas que quelque chose.with-some-dashes est invalide, je dirais qu'il est préférable de leur apprendre "s'il y a des tirets, vous devez utiliser la notation entre crochets pour l'accès dict, par exemple quelque chose['avec-quelques-tirets']. Vous pouvez même mélanger les deux si nécessaire.

C'est ici la meilleure solution, ne pas casser des choses qui ont été utilisées pendant des années.

Excellent commentaire de @geerlingguy - sur place !

J'aimerais ajouter qu'en tant qu'utilisateur d'Ansible, pourquoi devrais-je savoir quelle est la syntaxe Python valide ? Ayant utilisé Ansible depuis longtemps maintenant, je comprends qu'Ansible (et ses modules) est écrit en Python, mais pourquoi devrais-je m'en soucier ? Exposer ce fait à l'utilisateur final n'est qu'une mauvaise conception.

Similaire à autoriser uniquement la notation JavaScript/Ruby/.NET/whatever valide pour des éléments tels que les noms d'utilisateur dans une application Web. Pourquoi l'utilisateur final se soucierait-il de la langue dans laquelle l'application est écrite ?

En plus de cela, introduire des changements de rupture est un sujet difficile, j'essaie d'éviter cela si possible. Si je dois apporter un changement, je laisse généralement l'ancien comportement existant par défaut et je laisse les gens opter pour le nouveau comportement. Pourquoi cela n'a-t-il pas été fait ici ? Pourquoi dois-je soit changer ma configuration, soit pire tout mon inventaire ? Pourquoi pas l'inverse ?

Si un système requiert des jetons strictement conformes en interne, alors le système doit générer en interne les jetons et créer une table de recherche qui associe les jetons internes aux données utilisateur. De cette façon, Ansible peut modifier ses règles de jetons au besoin et limiter l'impact sur les utilisateurs. Les utilisateurs doivent pouvoir nommer leur inventaire, leurs rôles, etc. comme ils le souhaitent ou ceux de leurs clients.

Il me semble que ce changement peut avoir l'effet inverse de son effet escompté (pour diminuer les requêtes d'assistance) :

Maintenant, il n'y a pas de délimiteur pris en charge (par défaut) à la fois par les noms d'hôte (qui doivent être résolus par DNS, c'est-à-dire ne pas contenir de traits de soulignement) et les noms de groupe (qui ne doivent pas contenir de tirets).

Devrait certainement être libre de nommer n'importe quel hôte

El mié., il y a 14 ans. 2019 16:16, Christian Pointner [email protected]
description :

Si je comprends ça
https://github.com/ansible/ansible/issues/56930#issuecomment-516863432
correctement. La seule chose qui est dépréciée est l'automatique
transformation des noms de groupe. Cela signifie qu'il devrait être tout à fait correct de définir force_valid_group_names
= ignorer après 2.10 et au-delà.

Il devrait également être tout à fait acceptable de continuer à utiliser des tirets et tout ce que vous
ne veux pas dans les noms de groupe. Ce qu'Ansible ne fera pas à l'avenir, c'est de désinfecter
les afin que vous puissiez utiliser la notation pointée même pour les noms de groupe « invalides ». Pour
Exemple:

Votre inventaire contient un groupe nommé foo-bar.xyz. Maintenant tu veux écrire
un modèle qui crée une liste d'hôtes appartenant à ce groupe :

{% pour l'hôte dans les groupes['foo-bar.xyz'] %}
{{ hôte }}
{% endfor %}

N'oubliez pas que cette version du modèle ne fonctionnerait pas :

{% pour l'hôte dans groups.foo-bar.xyz %}
{{ hôte }}
{% endfor %}

C'est parce que le - et le . ont une signification particulière dans ce cas. Les
la notation pointée serait cependant tout à fait acceptable si votre groupe avait le
nom foo_bar_xyz car le modèle devient alors :

{% pour l'hôte dans groups.foo_bar_xyz %}
{{ hôte }}
{% endfor %}

Ce qui est bien sûr tout à fait correct.

Dans le but de rendre les choses plus faciles pour les utilisateurs, Ansible a apparemment toujours
fait un peu d'assainissement pour les noms de groupe. Cela signifie qu'il était (et jusqu'à 2.10
est toujours) possible d'utiliser foo_bar_xyz dans les exemples ci-dessus même si
le groupe s'appelle en fait foo-bar.xyz. Personnellement je ne pense pas
rend les choses plus faciles et il semble que l'équipe de base soit désormais d'accord
avec ça.
Leur prochaine tentative pour s'attaquer au problème est donc de rendre impossible
les noms de groupe « invalides » en premier lieu. Cependant pour autant que je le comprends
sera toujours possible de désactiver cette limitation en définissant force_valid_group_names
= ignorer.

Pour faire court, ce sont en fait deux changements différents qui ont été
entrelacés[1] les uns avec les autres. D'où le nom et le libellé confus de
l'avertissement.

Encore une fois, c'est seulement ainsi que je comprends le problème. Veuillez me corriger si je suis
tort!

[1] pour plus de détails, voir RFC1925
http://www.faqs.org/rfcs/rfc1925.html Paragraphe 2, point (5)

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/ansible/ansible/issues/56930?email_source=notifications&email_token=AA5N2CJCIELW7JWHC6OJ35DQEQHSPA5CNFSM4HPRGLKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXU3ZKTDN5com,5ZHJKTDN5
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AA5N2CIVT5PLD2QCAGGBK6LQEQHSPANCNFSM4HPRGLKA
.

C'est vraiment une mauvaise décision à mon avis honnête. Et pour la mauvaise raison. Réduire le nombre de demandes d'assistance, vraiment ?

Ansible, en tant qu'outil, ne doit pas imposer de détails spécifiques à la langue à l'utilisateur final. Je suis déjà tellement énervé que Terraform m'impose tout ce Golang au fond de la gorge, maintenant il se passe la même chose ici avec Ansible et le style "pythonic". Ne vous méprenez pas, je travaille assez bien avec Go et Python, mais en ce qui concerne l'infrastructure en tant que code, pourquoi devrais-je m'en soucier ? Et que s'est-il passé avec la promesse d'avoir YAML dictant la forme de la base de code à gérer ? "L'infrastructure en tant que données, que vous pouvez lire et exécuter", j'ai entendu cela tant de fois... Pour autant que je sache, YAML ne se soucie pas du tout des tirets et des traits de soulignement.

BTW, il y a pas mal de choses qui ne prennent pas en charge les traits de soulignement. Noms d'hôte, régions AWS et identifiants pour littéralement tout, pour n'en mentionner que quelques-uns vraiment importants. Bonne chance pour maintenir toutes les exceptions où la transformation n'est pas censée se produire...

Pour les personnes qui viennent ici à la recherche d'une solution rapide pour résoudre ce problème, ajoutez simplement la ligne force_valid_group_names = ignore à votre ansible.cfg et soyez heureux.

D'après ce que j'ai compris, vous ne pouvez de toute façon pas utiliser la notation par points pour les variables avec des espaces, et bien que je ne crée jamais de variables avec des espaces, il existe malheureusement de nombreux fournisseurs qui renvoient des clés de dictionnaire avec des espaces via les réponses de l'API json. L'option sensée me semble passer à la notation entre crochets. Espérons que la définition de force_valid_group_names à ignorer ne causera pas d'effets néfastes plus tard, qui sait quoi d'autre est prévu à l'avenir avec ce changement.

C'est une décision assez terrible, en particulier lorsqu'il s'agit de travailler avec des inventaires dynamiques comme avec Openstack (et AWS).
Les noms d'instance et les clés de métadonnées contenant des « caractères interdits » sont souvent renvoyés en tant qu'éléments d'inventaire et/ou variables de groupe à partir du cloud sous-jacent. Cela va rendre la vie infernale pour de nombreux administrateurs Openstack (et AWS) qui essaient de gérer leurs flottes à l'aide de balises méta et/ou d'ID d'instance comme :
instance-8ca09c33-f255-440f-9544-b0ab318c79d9
méta-os_ubuntu

Les développeurs d'Ansible devraient prendre au sérieux l' opinion de $env-$role-[0..99] . Sommes-nous censés tout renommer pour apaiser nos suzerains Ansible ?

@ssbarnea D'une part, nous faisons un effort pour autoriser uniquement les noms de variables et autres clés similaires, qui sont des identifiants Python valides. Pour expliquer un peu plus les noms de groupe, cela pose un problème aux utilisateurs qui essaient d'utiliser la "syntaxe à points" telle que groups.foo-group , qui ne fait pas ce que l'utilisateur attend. Le nombre de problèmes et de demandes d'assistance causés par de petits problèmes comme ceux-ci nous a amenés à rechercher des noms de sécurité pour nous assurer que de tels problèmes ne se produisent pas.

Ceux qui souhaitent conserver ce que nous considérons comme des caractères invalides peuvent désactiver cette fonctionnalité.

Combien de temps les utilisateurs seront-ils autorisés à désactiver ce comportement ? Y aura-t-il une option de configuration permanente pour désactiver ce comportement dans toutes les versions d'ansible à l'avenir, ou ne sera-t-il pris en charge que jusqu'en 2.11 ? Je serais heureux que l'option soit activée par défaut, tant que j'ai toujours la possibilité de la désactiver.

Si cela devient une restriction stricte dans 2.11+, vous allez probablement vous retrouver à perdre des clients qui sont liés par les contraintes de leur organisation (tous les utilisateurs ansible n'ont pas le pouvoir de dicter les conventions de nommage utilisées par leur entreprise). Il semble que ce changement introduirait également un défi important pour ceux qui utilisent ansible pour gérer l'infrastructure cloud, où les tirets ont tendance à être fortement utilisés.

Juste pour rappeler à ceux qui n'ont pas lu tout le fil ici. Il y a aussi un fil sur la liste de diffusion devel : https://groups.google.com/forum/#!topic/ansible -devel/bjAcM9ferIw

À mon humble avis, ce changement était un très mauvais choix. Les changements de syntaxe de rupture de code dans les versions mineures nous empêchent d'étendre l'utilisation d'Ansible dans notre environnement. Parce que je ne pourrai pas mettre à jour Ansible s'il casse les playbooks de mes utilisateurs.

Mais comme @bcoca l'a indiqué ci-dessus, la plupart des développeurs ne consultent pas régulièrement ces discussions ici et ce problème n'est peut-être pas le bon endroit pour discuter du changement car il s'agit de la bonne documentation.

@Tronde : on pourrait soutenir que les contributeurs ET les clients sont consultés avant que les histoires ne soient écrites pour comprendre l'impact et recueillir des commentaires bien avant que quelqu'un ne code une solution. Comme plusieurs l'ont mentionné ici, il s'agit d'un échec de gestion de produit que nous avons vu plus d'une fois.

À titre d'exemple de la situation que @andyfeller décrit à propos de ce changement :

Nous avons un problème avec cela sur notre site.

Nous utilisons Red Hat Identity Manager comme inventaire externe, nous ne le contrôlons pas, il contient de nombreux groupes d'hôtes avec des tirets au lieu de traits de soulignement. Cela ne sera pas modifié (à cause de toutes les autres choses qui existent en utilisant ces noms).

Alors nous avons besoin:

• Pour configurer Ansible pour maintenir le comportement actuel
• Faire taire l'avertissement de dépréciation
• Faites ceci pour la ligne de commande Ansible et Ansible Tower

FYI PR https://github.com/ansible/ansible/pull/66650 (pas de fourches là-bas) est prévu pour 2.10 (pour le moment), ce qui signifie que toute personne qui voit actuellement cet avertissement le ferait (une fois qu'elle passera à 2.10, en supposant à nouveau que PR est fusionné) commencent à avoir des échecs de playbook à la place (jusqu'à ce qu'ils définissent force_valid_group_names = ignore dans un ansible.cfg ).

Je poste juste pour la visibilité. Je suis toujours fermement derrière mon affirmation précédente selon laquelle il s'agit d'une valeur par défaut hostile à l'utilisateur, car il existe encore de nombreux scripts d'inventaire dynamiques (une partie d'Ansible lui-même ou maintenant déplacés dans des collections « officielles ») qui génèrent des noms de groupe avec des tirets ou autres caractères DNS valides.

Pratiquement toute personne qui utilise Ansible avec AWS devra remplacer la valeur par défaut.

@geerlingguy Est-ce le bon numéro de RP ? On dirait que cela pointe vers ce problème.

Pour info, cela a été discuté lors d'une réunion principale ici , à partir de 19:06:55

@apple4ever oops, mis à jour le lien, c'est https://github.com/ansible/ansible/pull/66650

J'ai donc vu ci-dessus de nombreux commentaires sur des choses qui ont déjà été répondues/démystifiées/etc, alors je vais juste lier ici mon post précédent.

https://github.com/ansible/ansible/issues/56930#issuecomment -516863432

Veuillez ne pas ajouter de nouveaux messages qui n'ajoutent pas de NOUVEAUX éléments de discussion car ils masquent les précédents auxquels on a déjà répondu.

Au fait, où serait un bon endroit pour lier dans la documentation Python à quoi ressemblent les noms de variables valides ? Il y a https://docs.python.org/3/reference/lexical_analysis.html#grammar -token-identifier, mais ce n'est pas vraiment convivial ou lisible pour les personnes sans formation en informatique.

La raison pour laquelle je pose la question est que je ne sais pas si la plainte initiale a effectivement été traitée. Il y a juste un avertissement indiquant qu'il y a quelque chose qui ne va pas, mais il faut beaucoup de recherche pour savoir quoi exactement et comment quelqu'un - s'il le veut ou le peut - pourrait réellement choisir un nom de groupe valide. Je m'attendrais à au moins un message clair "Le nom du groupe foo-bar contient des caractères invalides ( - ). Les noms de groupe valides doivent être des identifiants Python valides (voir https://docs.python.org/??? pour plus d'informations)" message, pas seulement "il y a de mauvais caractères, vérifiez à nouveau avec -vvvv pour savoir lesquels !". Idéalement, cela mentionnerait également que cela peut être désactivé, mais pourrait entraîner d'autres problèmes inattendus (comme rendre très difficile pour Ansible de distinguer les groupes foo-bar , foo.bar et foo_bar ).

Actuellement, il s'agit plutôt d'un message « Vous avez fait quelque chose de mal, réparez-le » sans aucune manière claire de savoir comment procéder, ce qui pourrait également avoir contribué à la forte réponse ici.

@geerlingguy a écrit dans le commentaire 56930 :

(jusqu'à ce qu'ils définissent force_valid_group_names = false dans un ansible.cfg)

La documentation ne mentionne pas 'false' comme valeur valide pour cette clé. J'ai défini la valeur sur "ignorer", ce qui devrait faire l'affaire. Mais est-ce que « false » est un mot-clé invalide ou est-il correct et la documentation n'est pas complète ici ?

@bcoca dans un commentaire précédent :

Juste pour dire ceci une fois, clairement, VOUS POURREZ TOUJOURS UTILISER DES TIRTS DANS LES NOMS DE GROUPE ainsi que des points et d'autres caractères qui sont maintenant considérés comme « invalides », mais pas par défaut. Ce "par défaut" est ce qui est déprécié, la valeur par défaut sera "sûr" en 2.11, mais vous aurez toujours une option pour "accepter" l'ancien comportement.

Vous avez déclaré à plusieurs reprises que le comportement actuel peut être préservé, mais quels sont les paramètres exacts de ansible.cfg requis pour faire cela _maintenant_ et écraser l'avertissement de dépréciation.

J'ai essayé comme @geerlingguy l'a écrit dans le commentaire 56930 :

(jusqu'à ce qu'ils définissent force_valid_group_names = false dans un ansible.cfg)

Ce qui fait échouer mes playbooks lorsqu'il ne trouve pas d'hôtes ou de groupes avec des tirets (ils proviennent d'un plugin d'inventaire que nous avons écrit BTW, les thèses doivent-elles également effectuer la transformation, ou est-ce fait quand Ansible ingère l'inventaire à partir de le plugin ?)

J'ai essayé comme @geerlingguy l'a écrit dans le commentaire 56930 :

(jusqu'à ce qu'ils définissent force_valid_group_names = false dans un ansible.cfg)

Ce qui fait échouer mes playbooks lorsqu'il ne trouve pas d'hôtes ou de groupes avec des tirets (ils proviennent d'un plugin d'inventaire que nous avons écrit BTW, les thèses doivent-elles également effectuer la transformation, ou est-ce fait quand Ansible ingère l'inventaire à partir de le plugin ?)

Cela a été mentionné dans plusieurs commentaires et se trouve dans la documentation . Vous devez utiliser jamais ou ignorer .

Alors, ne sommes-nous tout simplement plus censés utiliser le script d'inventaire dynamique EC2 puisqu'il regroupe tout par « us-east-1 », « us-east-2 », etc. ? Ou y a-t-il un plan pour le mettre à jour ? Je viens de consulter la documentation d'Ansible pour le script d'inventaire dynamique EC2 et le lien pour le télécharger sur Github ne fonctionne plus, donc c'est intéressant.

Je viens de consulter la documentation d'Ansible pour le script d'inventaire dynamique EC2 et le lien pour le télécharger sur Github ne fonctionne plus, donc c'est intéressant.

Voir https://github.com/ansible/ansible/issues/68419

pour ceux d'entre vous qui ne prennent pas la peine de lire le journal IRC, voici la décision, c'est-à-dire pas de décision :

19:15:40 <sivel> I've got to say, that brining this topic up all the time isn't a good use of time
19:15:52 <cyberpear> bcoca nominated it
19:16:07 <felixfontein> I think the aim was to solve this once and for all (like, again :) )
19:16:29 <cyberpear> since bcoca is not here, move on to next topic?
19:16:34 <sivel> honestly, I don't think this is going to be the right forum to make a decision on this
19:16:45 <jillr> +2 moving on
19:16:47 <cyberpear> sivel: what's the correct forum?
19:16:55 <felixfontein> sivel: what is the right forum for making that decision?
19:17:02 <cyberpear> "declaration from Red Hat On High"?
19:17:15 <sivel> I'm going to abstain on that, but this project is not a democracy
19:17:16 <cyberpear> -1 to "declaration from Red Hat On High"
19:17:24 <sivel> too many cooks in the kitchen distract
19:17:45 <sivel> We know the arguments at this point
19:17:59 <sivel> anywho, next topic

oui, quelqu'un a écrit "n'hésitez pas à passer par ML ou IRC". non, "ce projet n'est pas une démocratie".

oui, quelqu'un a écrit "n'hésitez pas à passer par ML ou IRC". non, "ce projet n'est pas une démocratie".

Pour être honnête, cela ne va pas avec l'opensource - Si cela conduit à une voie peu populaire - les gens peuvent le fork, peut-il l'être ?

Je peux voir qu'accepter les relations publiques dans ansible est terriblement lent. Les correctifs semblent évidemment nécessaires et un simple changement, mais cela n'intervient jamais. Heureusement, ansible lui-même est flexible pour permettre aux gens d'utiliser des plugins personnalisés, mais il semble que cela me rendra moins de contributions - ou même plus de tracas pour le faire.

Je me sens un peu triste, vraiment...

@ sunshine69 Je ressens ta douleur. Mais c'est une discussion qui devrait avoir lieu sur IRC ou le Google Group for Ansible Development.

Ce problème n'est pas le bon endroit pour cela. Parce que peu de gens lisent ici.

@ sunshine69 Je ressens ta douleur. Mais c'est une discussion qui devrait avoir lieu sur IRC ou le Google Group for Ansible Development.

Ce problème n'est pas le bon endroit pour cela. Parce que peu de gens lisent ici.

Bien que la discussion puisse être plus productive dans ces autres canaux, la transparence est appréciée pour les personnes qui suivent spécifiquement ce problème. IRC n'est pas la préférence de tout le monde après tout.

Pour info : la suppression de l'obsolescence de TRANSFORM_INVALID_GROUP_CHARS vient d'être fusionnée hier. Il existe des PR de rétroportage pour 2.9 (https://github.com/ansible/ansible/pull/69487) et 2.8 (https://github.com/ansible/ansible/pull/69488) pour y supprimer les avertissements de dépréciation.

Fichiers identifiés dans la description :

• lib/ansible/modules/group.py

Si ces fichiers sont incorrects, veuillez mettre à jour la section component name de la description ou utiliser la commande de bot !component .

cliquez ici pour l'aide du bot

Lorsque j'ai défini force_valid_group_names = ignore l' AVERTISSEMENT a disparu, mais l' AVIS DE DÉPRÉCATION n'a pas disparu.

Enfin, j'ai trouvé dans la documentation : force_valid_group_names = silently qui fera le remplacement et n'obstruera pas la sortie - si c'est ce que vous cherchez à faire.

Néanmoins, tout ce problème aurait pu être évité en premier lieu si des changements inutiles comme celui-ci n'avaient pas été apportés en premier lieu.

@emmm-dee - Pour ce problème particulier, j'ai ouvert https://github.com/ansible/ansible/issues/70908 - notez que ce problème persiste, car il n'y a toujours pas de documentation officielle sur les caractères de groupe "valides" .

merci à @geerlingguy pour vos actions ! C'est vous qui améliorez ansible.

Je travaille pour notre application pour le rebond (démarrage/arrêt) mais je ne suis pas connecté à l'hôte de l'application.

J'ai essayé la commande ping que vous avez envoyée et cela fonctionne...

[ webadmin@vlodjumpts00 ~]$ ping 8.8.8.8

PING 8.8.8.8 (8.8.8.8) 56(84) octets de données.

64 octets à partir de 8.8.8.8 : icmp_seq=1 ttl=112 time=10.6 ms

[ webadmin@vlodjumpts00 ~]$ mirrorlist.centos.org

-bash : mirrorlist.centos.org : commande introuvable

Je veux l'utiliser pour notre organisation .. si j'ai exécuté la commande "ansible all -m ping". face à l'erreur, ci-dessous sont des détails:

[ aa63457@vlodjumpts00 bin]$ ansible all -m ping

changer, mais toujours être configurable par l'utilisateur lors de la dépréciation. Cette fonctionnalité sera supprimée dans la version 2.10. Les avertissements de dépréciation peuvent être

désactivé en définissant deprecation_warnings=False dans ansible.cfg.

RTE3EPAdmin | INACCESSIBLE ! => {

"changed": false,

"msg": "Failed to connect to the host via ssh: ###############################################################################\n# CenturyLink computers and the CenturyLink computer network are CenturyLink  #\n# property. Only authorized persons may use them and only for legal and proper#\n# purposes as determined solely by CenturyLink. You consent to the monitoring #\n# of their use. You must use CenturyLink computers and the network in         #\n# accordance with the CenturyLink Code of Conduct, subject to discipline for  #\n# misuse. Customer use is governed by the CenturyLink Acceptable Use Policy.  #\n###############################################################################\nUse CTL credentials (login/password) on this server.\nAUTH-NOTICE:\nAUTH-NOTICE: Use your cuid as your username\nAUTH-NOTICE:\nPermission denied (publickey,password).",

"unreachable": true

}

localhost | SUCCÈS => {

"ansible_facts": {

    "discovered_interpreter_python": "/usr/bin/python"

},

"changed": false,

"ping": "pong"

}

S'il vous plaît aidez-moi... ce dont j'ai besoin pour le faire. En fait, nous n'avons pas de fichier UN/PWD for hosts pour connecter la machine hôte.

localhost ansible_connection=local

[RTE3VFO]

RTE3VFOAdmin ansible_host=vlddwblasts001.test.intranet

RTE3VFOManaged ansible_host=vlddwblasts002.test.intranet

[RTE3EP]

RTE3EPAdmin ansible_host=vlddwblasts002.test.intranet

RTE3EPManaged ansible_host=vlddwblasts003.test.intranet

[RTE3RES]

RTE3RESAdmin ansible_host=vlddwblasts003.test.intranet

RTE3RESAManged ansible_host=vlddwblasts004.test.intranet

[RTE3ORCH]

RTE3ORCHAdmin ansible_host=vlddwblasts004.test.intranet

RTE3ORCHManaged ansible_host=vlddwblasts005.test.intranet

[RTE3EASE]

RTE3EASEAdmin ansible_host=vlddwblasts005.test.intranet

RTE3EASEManged ansible_host=vlddwblasts006.test.intranet

[RTE3RTS]

RTE3RTSAdmin ansibke_host=vlddwblasts006.test.intranet

[EASE-ASR-Test2:enfants]

RTE3VFO

RTE3EP

RTE3RES

RTE3ORCH

RTE3EASE

RTE3RTS

et la structure du répertoire est :

[ webadmin@vlodjumpts00 ansible]$ pwd

/etc/ansible

[ webadmin@vlodjumpts00 ansible]$ ll

84 au total

-rw -------- 1 webadmin webadmin 607 12 juillet 2017 1

-rw-r--r-- 1 webadmin webadmin 17910 19 sept. 09:55 ansible.cfg

-rw-r--r-- 1 root root 19985 8 décembre 2019 ansible.cfg.rpmnew

-rw------- 1 webadmin webadmin 213 3 juillet 2017 easyasr-rte2-ease.yml

-rwxr-xr-x 1 webadmin webadmin 1034 19 sept. 09:16 easy-hosts

-rwxr-xr-x 1 webadmin webadmin 1647 19 sept. 10:50 hôtes

-rw -------- 1 webadmin webadmin 2679 3 juillet 2017 hosts.bkp

-rw------- 1 webadmin webadmin 273 6 juillet 2017 lineinsfile_tst.yml

drwx ------ 4 webadmin webadmin 4096 2 novembre 2017 playbooks

drwxr-xr-x 3 root root 19 décembre 8 2019 rôles

-rwxr-xr-x 1 webadmin webadmin 7321 2 novembre 2017 servmix_hosts

-rw------- 1 webadmin webadmin 208 19 sept. 10:55 test.yml

-rw------- 1 webadmin webadmin 122 19 sept. 10:54 vars.yaml

Nous ne sommes pas connectés directement à l'hôte... connectez-vous d'abord à notre serveur de saut et à l'hôte ssh...

le serveur de saut est le port "vmdcltctws217" utilisant =22, type de connexion=ssh

puis entrez avec notre UN/PWD

après cela, nous avons fait sudo pour la connexion au serveur hôte.

sudo su - easysqa

puis serveur hôte ssh comme ..

vlddwblasts001.test.intranet

puis nous exécutons la commande start/stop à partir d'ici.

S'il vous plaît aidez-moi, pour quoi puis-je le faire?