Archivos identificados en la descripción:

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

Si estos archivos no son precisos, actualice la sección component name de la descripción o use el comando !component bot.

haga clic aquí para obtener ayuda con el bot

cc @sfromm
haga clic aquí para obtener ayuda con el bot

Empecé a recibir esta advertencia, pero no encontré referencias en la guía de portabilidad ni referencias sobre cómo o qué corregir.

la mayoría de mis advertencias son de ec2.py, donde instance_id usó - (por ejemplo: i-033f62b586143dff7 ) y las regiones (por ejemplo: eu-central-1c ), por lo que no tenemos solución real para estos

Finalmente, esto rompió algunos de mis libros de jugadas, donde usé when: ansible_hostname in groups['varnish'] y el ansible_hostname es varnish-eu-central-1c-001 .
En el pasado, esto funcionaba bien, ahora necesito usar inventory_hostname para obtener varnish_eu_central_1c_001 y obtener una coincidencia frente a groups['varnish']

Por lo tanto, esto necesita al menos y con urgencia una advertencia en la guía de migración de que inventory_hostname y groups[] pueden estar devolviendo datos diferentes.

¿Cuál fue el razonamiento detrás de eliminar el guión de los nombres de los grupos? Realmente me cuesta encontrar una buena razón para eso, especialmente porque esto requerirá mucha refactorización de código.

@ssbarnea Por un lado, estamos haciendo un impulso para permitir solo nombres de variables y otras claves similares, que son identificadores de Python válidos. Para explicar un poco más acerca de los nombres de grupos, causa un problema a los usuarios que intentan usar "sintaxis de puntos" como groups.foo-group , que no hace lo que el usuario espera. La cantidad de problemas y solicitudes de soporte causados ​​por pequeños problemas como estos nos ha llevado a buscar nombres de seguridad para asegurarnos de que no ocurran problemas como este.

Para aquellos que quieran conservar lo que consideramos caracteres no válidos, pueden optar por no participar en esta funcionalidad.

¿Qué debemos hacer para optar por no participar en esta funcionalidad? Nuestros scripts de implementación de Ansible locales están llenos de nombres de grupos que contienen guiones. No los usamos con notación de puntos, por supuesto. Pero cambiarlos todos sería una tarea verdaderamente monumental. Preferiría optar por no participar y, al mismo tiempo, alentar a mi equipo a evitar el uso de guiones en el futuro y, cuando sea posible, convertir los guiones en guiones bajos, aunque esa última parte no siempre es tan sencilla como podría parecer.

Entonces, ¿uno simplemente establece force_valid_group_names = false en ansible.cfg? Eso parece correcto según https://github.com/ansible/ansible/commit/d241794daa6d413e6447890e2a4f11e0d818cf0e#diff -fd24ad93fbc32f454761746c1ac908f2

¿Qué debemos hacer para optar por no participar en esta funcionalidad? Nuestros scripts de implementación de Ansible locales están llenos de nombres de grupos que contienen guiones. No los usamos con notación de puntos, por supuesto. Pero cambiarlos todos sería una tarea verdaderamente monumental. Preferiría optar por no participar y, al mismo tiempo, alentar a mi equipo a evitar el uso de guiones en el futuro y, cuando sea posible, convertir los guiones en guiones bajos, aunque esa última parte no siempre es tan sencilla como podría parecer.

Entonces, ¿uno simplemente establece force_valid_group_names = false en ansible.cfg? Eso parece correcto basado en d241794 # diff-fd24ad93fbc32f454761746c1ac908f2

export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=never o export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore - este último aún no está en los documentos: https://github.com/ansible/ansible/pull/57318

Gracias, James. Dado que las personas acuden a este tema para dar seguimiento al mensaje de advertencia, incluyo información que creo que puede ser útil:

Para deshabilitar la transformación automática del nombre de grupo ≥2.10 de forma más portátil / permanente hasta que esté listo para eliminar grupos inválidos de su inventario, agregue force_valid_group_names = never a la sección [defaults] INI de ansible.cfg .

Para ver todos los grupos y caracteres no válidos que activan la advertencia (tal vez para que pueda apuntar a ellos para la eliminación progresiva), puede hacer algo como este no-op de CLI ansible:

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

Estos caracteres no válidos se definen (a partir de 2019-06-04) como una constante, INVALID_VARIABLE_NAMES , en:
https://github.com/ansible/ansible/blob/devel/lib/ansible/constants.py#L119
como '^[\d\W]|[^\w]' ,
es decir: any leading non-alpha character OR any character other than alpha-numeric and underscore .
(Espero haberlo hecho bien)

Si encuentra molestas las advertencias de obsolescencia, también puede deshabilitarlas permanentemente para cualquier comando ansible- o el comando ansible ad-hoc agregando deprecation_warnings = False al mismo [defaults] sección de ansible.cfg , pero no lo recomendaría (ya que puede perderse noticias importantes), y en su lugar use variables de entorno de shell en línea como esta:
ANSIBLE_DEPRECATION_WARNINGS=False ansible-inventory --host=localhost

Sin embargo, el análisis de inventario [WARNING] s no desaparecerá. No hay una configuración específica o env var para desactivar todas las advertencias (¿todavía?), Pero si realmente te molesta, puedes enviar todos los stderr a /dev/null (inserta las advertencias de "mejores prácticas" aquí):

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

Espero que esto ayude a alguien, en algún lugar.

Solo encuentro molestos los mensajes de advertencia de obsolescencia cuando no proporcionan una ruta de migración. Teniendo en cuenta que el espacio es limitado y que es probable que la corrección necesite una actualización, me resultaría muy útil proporcionar enlaces a los tickets que puedan documentar soluciones, soluciones alternativas, ...

Un enfoque como este podría ahorrar el trabajo adicional necesario para mejorar los mensajes de advertencia incompletos, ya que no tendríamos que actualizar el mensaje, exportarlo a algunas versiones anteriores.

PD. Deshabilitar las advertencias de desaprobación es algo que no recomendaría a nadie, tal vez solo si un proyecto ya se enfrenta a su destino final;)

Empecé a recibir esta advertencia, pero no encontré referencias en la guía de portabilidad ni referencias sobre cómo o qué corregir.

la mayoría de mis advertencias son de ec2.py, donde instance_id usó - (por ejemplo: i-033f62b586143dff7 ) y las regiones (por ejemplo: eu-central-1c ), por lo que no tenemos solución real para estos

Finalmente, esto rompió algunos de mis libros de jugadas, donde usé when: ansible_hostname in groups['varnish'] y el ansible_hostname es varnish-eu-central-1c-001 .
En el pasado, esto funcionaba bien, ahora necesito usar inventory_hostname para obtener varnish_eu_central_1c_001 y obtener una coincidencia frente a groups['varnish']

Por lo tanto, esto necesita al menos y con urgencia una advertencia en la guía de migración de que inventory_hostname y groups[] pueden estar devolviendo datos diferentes.

Me gustaría hacerme eco de la declaración sobre la advertencia que genera el script de inventario dinámico de EC2 . Me di cuenta de que hay una configuración de ec2.ini para deshabilitar la agrupación de hosts por instance_id ( group_by_instance_id = False ), pero la configuración que no resolvió la advertencia para mí como había anticipado, me aseguré de borró la memoria caché del inventario local.

¿Alguna solución alternativa para el inventario dinámico de EC2 específicamente?

Estos caracteres no válidos se definen (a partir de 2019-06-04) como una constante, INVALID_VARIABLE_NAMES , en:
https://github.com/ansible/ansible/blob/devel/lib/ansible/constants.py#L119
como '^[\d\W]|[^\w]' ,
es decir: any leading non-alpha character OR any character other than alpha-numeric and underscore .
(Espero haberlo hecho bien)

Me suena acertado. Debe enviar un documento PR con esa información.

Si encuentra molestas las advertencias de obsolescencia, también puede deshabilitarlas permanentemente para cualquier comando ansible- o el comando ansible ad-hoc agregando deprecation_warnings = False al mismo [defaults] sección de ansible.cfg , pero no lo recomendaría (ya que puede perderse noticias importantes), y en su lugar use variables de entorno de shell en línea como esta:
ANSIBLE_DEPRECATION_WARNINGS=False ansible-inventory --host=localhost

Sin embargo, el análisis de inventario [WARNING] s no desaparecerá. No hay una configuración específica o env var para desactivar todas las advertencias (¿todavía?), Pero si realmente te molesta, puedes enviar todos los stderr a /dev/null (inserta las advertencias de "mejores prácticas" aquí):

La opción ignore indocumentada proporciona esta funcionalidad. Docs PR aquí: https://github.com/ansible/ansible/pull/57318

A partir de 2.8.2, esta advertencia de obsolescencia se eliminará si establece explícitamente alguna de las opciones.

¿Dónde discute el equipo de desarrollo de ansible este tipo de decisiones? Es muy difícil para nosotros, los usuarios, entender el razonamiento de esto. Si es un razonamiento puro "estilo pitón", en lugar de un razonamiento práctico, ¿valdría la pena reconsiderarlo? Si un guión en los nombres de los grupos rompe cosas en futuras versiones de ansible, ¿podría ser más un problema con la implementación, más que con el nombre de un grupo?

Para mí, esto suena más a un cambio cosmético, que a algo que se ha pensado bien.

Un nombre de grupo no es un nombre de variable, es el contenido de tal. Un guión / guión es solo un carácter, que también resulta ser una forma extremadamente popular de agrupar información en una convención de nomenclatura. Comparado con el signo de exclamación o la estrella, no tiene un significado especial en una cláusula de límite.

El costo para mitigar este problema es enorme, dado que miles de sitios no solo tienen que cambiar los nombres de los grupos en los inventarios, sino también revisar todos sus libros de jugadas y roles locales, y probarlos todos nuevamente.

Si hay alguna forma de que los "campesinos" hagan oír su voz, me encantaría aportar mi opinión e intentar comprender cómo surgió esta idea.

He llegado a comprender que el cambio se realizó en ansible porque los usuarios cometieron errores, como intentar usar groups.group-name lugar de groups['group-name'] . AIUI, es un cambio puramente con el propósito de reducir los problemas de soporte. (Personalmente me opongo al cambio).

El viejo comportamiento no desaparecerá; simplemente dejará de estar disponible sin elegir explícitamente el comportamiento anterior.

Triste escucharlo.

Mi caso de uso es que estoy incrustando el comando "inventario-ansible" en un archivo Vagrant, de una manera en la que es descortés poner cosas en ansible.cfg, y que ayudaría poder anular el comportamiento como una opción de línea de comando (no variable de entorno).

Por lo general, cambios como este se deben a buenas intenciones, pero es posible que no siempre conduzcan al resultado que uno tiene en mente.

Mi problema con este cambio es que los nombres de grupo ahora se vuelven algo "especiales": se permiten guiones en los nombres de host, pero no en los nombres de grupo, lo que lo hace un poco extraño considerando el comienzo de un libro de jugadas en la sección hosts: Podría escribir nombres de grupos y / o hosts.

¿Es la explicación dada por @sivel realmente la única razón detrás de este cambio? ¿Qué pasa con hosvars['foo-host'] entonces? Espero que nadie esté considerando hacer guiones como caracteres no válidos también en los nombres de host del inventario ...
Además de hostvars hay un montón de otros ejemplos en los que no se puede usar la "notación de puntos", por lo que la necesidad de saber cuándo usar qué formulario permanecerá. Me parece bastante arbitrario señalar los nombres de los grupos.

Si bien el argumento de la notación de puntos es una excusa algo válida, no veo que esto solucione sus problemas de soporte sin mejorar la documentación. Si sus usuarios están haciendo algo estúpido, su documentación no es adecuada. Todo lo que los desarrolladores han logrado es alienar a muchos usuarios. Nombres de grupo que veo como valores de cadena arbitrarios. Restringir a los caracteres alfanuméricos y subrayar honestamente es algo molesto, especialmente cuando los RFC del nombre de host permiten guiones, puntos, etc. Si los subrayados fueran el estándar de facto para las convenciones de nombres, no creo que esto sea un problema. Los guiones se utilizan ampliamente para las cadenas de descriptores. Si desea reducir su volumen de soporte, intente abordar el problema de la notación de puntos desde otra dirección; Cree un script de validación que sus equipos de soporte puedan proporcionar que verifique los problemas de mejores prácticas y proporcione advertencias u orientación como ejemplo. Actualice su documentación sobre la advertencia de notación de puntos para que sea grande, en negrita, roja, intermitente, lo que sea ... Tales casos de soporte terminan siendo llamadas de 1 minuto si su documentación ya cubre el problema. Conteste el teléfono, vea el problema, proporcione el enlace del documento, listo.

Los guiones en los nombres de los grupos son INI válidos y YAML válidos, no veo por qué yo, como usuario, debería tener que cambiar el nombre de todos mis grupos solo porque los nombres no se pueden usar como nombres de variables de Python.

También cuestionando el fundamento de esta decisión de desaprobar - en los nombres de los grupos. No poder usar guiones en el inventario dinámico keyed_groups ya era bastante molesto, pero tener que cambiar el nombre de todos nuestros grupos en nuestros archivos de inventario y comandos ansible-playbook -l ... solo para evitar problemas hipotéticos de soporte relacionados con la sintaxis es va a ser doloroso.

FWIW tenemos una convención para nombrar grupos de roles como foo_server , y grupos de anfitriones como foo-dev o foo-test . Casi el 100% de nuestro uso de Ansible son comandos como ansible-playbook -l foo-dev , por lo que este cambio requerirá mucho esfuerzo para combatir la memoria muscular.

No estoy seguro de si agregar otro yo 2 aquí alentará una reversión de esta decisión específica, pero tiendo a estar de acuerdo con los detractores del requisito de que los nombres de grupo sean identificadores de Python válidos.

Por favor, apoye los guiones junto con letras, números y guiones bajos en los nombres de los grupos (¡pero tampoco tengo nada en contra de los puntos)!

Usamos mucho guiones en los nombres de los grupos. Ambos para agrupar nombres como este:

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

y _abuse_ Inventory para mantener la lista de hosts en un solo lugar (en lugar de mantener los nombres de host en diferentes archivos var) de esta manera:

[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 = groups [_hostgroup] | d ([]) | sort%}
{% if _hostlist%}
{% para el host en _hostlist%}
...
''

No usamos puntos solo para hacer diferencias visibles entre los nombres de grupos y hosts.

La palabra INVALID en TRANSFORM_INVALID_GROUP_CHARS no da ninguna confianza de que sea posible seguir usándolos a largo plazo.

Si la intención es evitar el uso de estos caracteres, mejor llámelos caracteres _UNSAFE_, muestre una advertencia y deje que los usuarios decidan si ven esta advertencia o no. ¡Pero nunca rechace ni reemplace estos personajes!

Los usuarios deben a) silenciar esta advertencia (usando una palabra clave como ALLOW_UNSAFE_GROUP_CHARS), b) cambiar los nombres de sus grupos (cuando sea posible) oc) simplemente vivir con esa advertencia. La mayoría elegirá entre las dos primeras opciones de todos modos.

También siento que esto no tiene sentido, ya que un guión "-" es un carácter delimitador estándar utilizado en casi todos los tipos de herramientas relacionadas con la computadora, y tratar de ajustarse a una "religión" parece constrictivo.

El viejo comportamiento no desaparecerá; simplemente dejará de estar disponible sin elegir explícitamente el comportamiento anterior.

No estaría tan preocupado por esta desaprobación si realmente fuera posible optar por los guiones en los nombres de los grupos. Entonces podría ser comprensible desde la perspectiva de un nuevo usuario.

Sin embargo, la advertencia de obsolescencia implica que la opción TRANSFORM_INVALID_GROUP_CHARS=never desaparecerá en Ansible 2.10, por lo que tendríamos que empezar a cambiar el nombre de todos nuestros grupos antes de que se lance Ansible 2.10.

[ADVERTENCIA DE DEPRECATION]: La configuración de TRANSFORM_INVALID_GROUP_CHARS está configurada para permitir caracteres incorrectos en los nombres de grupo de forma predeterminada, esto cambiará, pero el usuario aún podrá configurarlo cuando esté obsoleto. Esta función se eliminará en la versión 2.10. Las advertencias de obsolescencia se pueden desactivar configurando deprecation_warnings = False en ansible.cfg.

Además, el uso del complemento de inventario dinámico keyed_groups fuerza la transformación de los nombres de los grupos, incluso si se establece TRANSFORM_INVALID_GROUP_CHARS=never : 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

Comportamiento deseado

• El uso de TRANSFORM_INVALID_GROUP_CHARS=never debe seguir siendo compatible en el futuro

  EDITAR: leyendo el código, parece que la intención es mantener TRANSFORM_INVALID_GROUP_CHARS pero cambiar el valor predeterminado a always en 2.10; en ese caso, la advertencia de depreciación no está muy bien redactada: https: / /github.com/ansible/ansible/blob/db0fe4b1884e6bb9c25e970c7585abb7edd9d664/lib/ansible/inventory/group.py#L50

• El uso de TRANSFORM_INVALID_GROUP_CHARS=never debería silenciar la advertencia de obsolescencia

  Esto parece que ya es posible con la opción ignore indocumentada: https://github.com/ansible/ansible/pull/57318

• El uso de TRANSFORM_INVALID_GROUP_CHARS=never también debería permitir el uso de guiones en el inventario dinámico keyed_groups

  EDITAR: esto es claramente por compatibilidad con versiones anteriores de Ansible 2.7, que transformó incondicionalmente los nombres de grupo generados. Sería genial tener una opción de exclusión explícita para esto.

Con respecto a los nombres de las variables, no entiendo por qué se debe igualar el formato de la clave del diccionario con la sintaxis del nombre de la variable. AFAIK ningún lenguaje de programación tiene tal limitación. En Python puedes usar prácticamente cualquier cadena como clave de diccionario.

¿No es "grupos" una variable de tipo diccionario y tanto el nombre de host como el de grupo son simplemente claves de diccionario en Ansible? No son propiedades ni variables en sí mismas, ¿o sí?

Prefiero no permitir la sintaxis de groups.foo-group que de groups ["foo-group"]. Si g = "foo-group", ¿usa grupos.g o grupos [g]?

El uso de ansible.cfg [default] force_valid_group_names = ignore o export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore no parece funcionar en Ansible 2.8.1. Todavía da la advertencia de desaprobación.

$ 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.

¿Esto se debe a que aún no figura en la lista válida choices ? https://github.com/ansible/ansible/blob/v2.8.1/lib/ansible/config/base.yml#L1501

El uso de ansible.cfg [default] force_valid_group_names = ignore o export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore no parece funcionar en Ansible 2.8.1. Todavía da la advertencia de desaprobación.

$ 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.

¿Esto se debe a que aún no figura en la lista válida choices ? https://github.com/ansible/ansible/blob/v2.8.1/lib/ansible/config/base.yml#L1501

Este es un error que se corrigió en la próxima versión 2.8.2. Podrás export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore y eliminará todas las advertencias.

(La opción de ignorar aún no está documentada: https://github.com/ansible/ansible/pull/57318)

Esto va a romper a todos. Mala decisión.

¿Habría alguna forma de razonar con los mantenedores sobre esto?

Quizás uno de los mantenedores podría elaborar un poco aquí, si es solo un problema de soporte o si están usando construcciones de Python que realmente se rompen.

Solo quiero agregar esto bastante molesto y la incapacidad de realmente resolver el problema también fue molesta, literalmente tuve que hacer ansible-playbook "insert yaml file here" > output.txt para resolver el problema.

Coincidir con la mayoría de los carteles aquí. La eliminación de guiones de los nombres de los grupos parece una decisión mal pensada o que se basa en la implementación, no semánticamente.

Este cambio no tiene ningún sentido para mí. ¿Los desarrolladores de Ansible quieren obligar a miles y miles de usuarios a cambiar el nombre de sus grupos solo porque quieren una sintaxis adicional (que no falte) para acceder a los grupos? ¿Eso es una broma?

Usamos guiones y puntos en configuraciones grandes.
Nuestro patrón es product-name.environment.datacenter y deja las cosas muy claras.
No puedo imaginar la caída de - y . ya que eso haría que el inventario fuera totalmente ilegible.

Estamos usando complementos de inventario ansible que consultan la CMDB local para los nombres de grupos que contienen (y seguirán conteniendo) guiones. Se romperían muchas cosas si esto no fuera válido en el futuro.

Usamos guiones y puntos en configuraciones grandes.
Nuestro patrón es product-name.environment.datacenter y deja las cosas muy claras.
No puedo imaginar la caída de - y . ya que eso haría que el inventario fuera totalmente ilegible.

Estamos usando un enfoque similar con un esquema de nomenclatura jerárquico (inspirado en java, por ejemplo, org.company.product-name.component).
Sería un horror absoluto tener que volver a los guiones bajos.

je. también nos enfrentamos a ese problema. estamos usando el guión en los nombres de nuestros grupos de forma intensiva.
Si uno pudiera explicar qué problema se debe al uso del tablero en un dictado, estaría feliz de saber

Principalmente estoy reiterando lo que otros han dicho, pero quería agregar algunas aportaciones. Creo que si se implementa este cambio, la bandera para permitir guiones debería mantenerse y mantenerse. Aunque entiendo que Python espera guiones bajos, los guiones se usan comúnmente para nombres de host y nombres de grupos de hosts. En nuestro entorno, generamos el inventario de forma dinámica a partir de hosts y grupos de hosts en nuestro directorio LDAP / Kerberos. Menciono esto porque, aunque sería posible cambiar los nombres de host y de grupo, no es preferible.

¿Qué debemos hacer para optar por no participar en esta funcionalidad? Nuestros scripts de implementación de Ansible locales están llenos de nombres de grupos que contienen guiones. No los usamos con notación de puntos, por supuesto. Pero cambiarlos todos sería una tarea verdaderamente monumental. Preferiría optar por no participar y, al mismo tiempo, alentar a mi equipo a evitar el uso de guiones en el futuro y, cuando sea posible, convertir los guiones en guiones bajos, aunque esa última parte no siempre es tan sencilla como podría parecer.

Entonces, ¿uno simplemente establece force_valid_group_names = false en ansible.cfg? Eso parece correcto basado en d241794 # diff-fd24ad93fbc32f454761746c1ac908f2

Prueba en Ansible 2.8.2, esta configuración INI no funciona como se esperaba, creo, esto solo eliminará la ADVERTENCIA DE DEPRECACIÓN, mientras que lo que quiero es que Ansible use mis grupos con guiones sin quejarse.

Estos son los resultados sin :

[ADVERTENCIA DE DEPRECATION]: La configuración de TRANSFORM_INVALID_GROUP_CHARS está configurada para permitir caracteres incorrectos en los nombres de grupo de forma predeterminada, esto cambiará, pero el usuario aún podrá configurarlo cuando esté obsoleto. Esta función se eliminará en la versión 2.10. Deprecación
las advertencias se pueden desactivar configurando deprecation_warnings = False en ansible.cfg.
[ADVERTENCIA]: Se encontraron caracteres no válidos en los nombres de los grupos, pero no se reemplazaron, use -vvvv para ver los detalles

Y con la configuración establecida en "falso" en ansible.cfg:

[ADVERTENCIA]: Se encontraron caracteres no válidos en los nombres de los grupos y se reemplazaron automáticamente, use -vvvv para ver los detalles

El uso de ansible.cfg [default] force_valid_group_names = ignore o export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore no parece funcionar en Ansible 2.8.1. Todavía da la advertencia de desaprobación.

$ 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.

¿Esto se debe a que aún no figura en la lista válida choices ? https://github.com/ansible/ansible/blob/v2.8.1/lib/ansible/config/base.yml#L1501

Este es un error que se corrigió en la próxima versión 2.8.2. Podrás export ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS=ignore y eliminará todas las advertencias.

(La opción de ignorar aún no está documentada: # 57318)

Pero, ¿se trata simplemente de aplastar advertencias o nos permitirá seguir usando guiones en grupos?
Esto no está muy claro.

Estoy de acuerdo con todos los detractores aquí.

Además de romper los libros de jugadas, esto contribuye a lo que yo llamo el lío de las convenciones en ansible. Ahora los nombres de host y los nombres de grupos tienen una convención diferente, ¿solo porque algunos principiantes aislados se topan con el tema del guión en la notación de puntos? Adivina qué ? Todavía se tropezarán con él, y la función habrá logrado enojar a la gente y no resolver ningún problema. Bravo.

Los nombres de grupos de Ansible deben ser capaces de respetar el nombre de los grupos del mundo real que representan.

Si todas las demás herramientas llaman a un conjunto de hosts my-backend-service ¿por qué ansible debería obligar a los operadores a traducir eso a my_backend_service para satisfacer las reglas de nomenclatura de Python?

Hoy es un día realmente triste. Cuando un compañero de trabajo de JR me planteó esta desaprobación, pensé que de ninguna manera el equipo de Ansible estaría tan desconectado de la realidad como para tomar una decisión tan egoísta. Me encanta Ansible por lo que puede lograr (desde la perspectiva del usuario que tiene CERO que ver con que esté escrito en Python) La dirección aquí para impulsar los estándares PEP en los usuarios finales me hace perder completamente la fe en la capacidad del equipo de desarrollo central de Ansible para hacer decisiones racionales. Espero que IBM lo solucione ...
O
Tal vez haya un nuevo equivalente de GO brillante al que podamos pasar.

Como este comportamiento es obviamente muy controvertido, me pregunto si esto es un trato hecho y esto se va a implementar en cualquier caso.

Agradecería mucho una respuesta de las personas que están detrás de esta decisión y espero alguna elaboración más allá de "esto es algo estándar de Python".

Como este comportamiento es obviamente muy controvertido, me pregunto si esto es un trato hecho y esto se va a implementar en cualquier caso.

Agradecería mucho una respuesta de las personas que están detrás de esta decisión y espero alguna elaboración más allá de "esto es algo estándar de Python".

Estoy de acuerdo contigo. Recientemente, el proyecto "go" se retiró de una propuesta impopular (consulte https://github.com/golang/go/issues/32437#issuecomment-512035919), por lo que cosas como esta pueden (y a veces deberían) ser revisadas y eventualmente también se echó atrás.

También es un tema y discusiones interesantes, quizás no solo por este cambio de característica. Es difícil averiguar cómo funciona la gobernanza de Ansible como producto. ¿Quizás algo _alguien_ debería traer consigo a https://www.ansible.com/ansiblefest ?

Como muchos de nosotros nos estamos rascando la cabeza, sin comprender cómo una cadena / contenido variable / nombre de grupo de alguna manera puede plantear problemas con los estilos de codificación de Python, sería bueno obtener una respuesta aquí de los mantenedores, argumentando por qué esto plantearía un problema.

Puedo entender si quieren mantener un estilo de codificación para nombres y estructuras de variables, pero ¿el contenido de una matriz o variable?

Aquí hay una discusión rápida sobre la notación con puntos de los dictados. Es posible, pero feo. https://stackoverflow.com/questions/16279212/how-to-use-dot-notation-for-dict-in-python

El hecho de que haya problemas de soporte relacionados con esto es, en mi opinión, un problema de documentación, no de funcionalidad. En todo caso, diría que los nombres de los grupos NO deben ser variables.

Como es el hecho de que este cambio se implementó antes de que la documentación estuviera disponible.

¿Cuál es el impacto de este cambio? ¿Tengo que editar cuidadosamente todos mis inventarios ansible para asegurarme de que no tengo guiones en los nombres de los grupos?

@CMoH IMO, la mejor solución por ahora es agregar force_valid_group_names = ignore a su configuración y ejecutar ansible 2.8.2 o posterior.

@skyscooby , incluso esto es un PITA. Lo que no es posible poner esta línea como predeterminada en /etc/ansible.cfg y usar local ansible.cfg en los directorios del libro de jugadas para otras configuraciones. Esto significa que todos los archivos ansible.cfg que salen deben cambiarse.

¿O hay alguna forma de configurar valores predeterminados globales (sin agregar otra variable al entorno del usuario)?

@Cougar estuvo de acuerdo en que esta elección de Ansible es un PITA.

Sin embargo, su problema no es exclusivo de esta configuración ... experimentamos un dolor similar y ahora desaconsejamos el uso de archivos ansible.cfg por proyecto, ya que la mayoría de las configuraciones se pueden establecer con variables de entorno que anulan la configuración del archivo cfg ... alguna razón oscura necesita una configuración específica, les pedimos que utilicen el método ENV, que deja el resto de las configuraciones que no necesitan cambiar según los estándares corporativos. Construimos un contenedor base docker con esta configuración estándar y los proyectos individuales simplemente agregan entradas ENV en su propio Dockerfile mientras basamos su imagen del contenedor ansible base. Todo ansible se ejecuta dentro del contenedor, por lo que estamos seguros de que todos los módulos pip, versiones ansible y herramientas de tiempo de ejecución son idénticos de un extremo a otro.

EDITAR: esto también nos da la capacidad de presentar nuevas versiones de ansible y controlar problemas como este antes de que todos en la empresa se vean afectados por ellos :)

Hice algunas excavaciones.

esta funcionalidad se agregó originalmente en PR https://github.com/ansible/ansible/pull/52748 supuestamente para respaldar la solicitud de función https://github.com/ansible/ansible/issues/40581

una descripción del objetivo: https://github.com/ansible/ansible/pull/52748#issuecomment -467976473

primera versión de ESTE síntoma (aunque con una causa diferente): https://github.com/ansible/ansible/issues/51844

Hombre, he estado leyendo el número 52748 tantas veces.

Según tengo entendido, los nombres de los grupos se desinfectaron previamente en los complementos y el núcleo, y alguien (por la razón que sea, ya que todavía no tengo claro por qué) decidió que los nombres de los grupos deberían seguir las convenciones de nomenclatura de variables de Python.

Entonces, # 52748 introdujo el saneamiento en el inventario, lo que rompe las cosas para muchas personas. Especialmente las personas que utilizan convenciones de nomenclatura inteligentes, por ejemplo, en AWS, Azure, etc., para asignar hosts a grupos.

Si usáramos la misma convención estándar / de nomenclatura para los nombres de host, seguramente perderíamos impulso y perderíamos usuarios.

Un nombre de grupo es un nombre, no una variable. El uso de guiones en los nombres de los grupos (al igual que en los nombres de host) tiene sentido. La traducción (saneamiento) no debería tener que realizarse a nivel de inventario (por nosotros, los usuarios) y, en el mejor de los mundos, nunca.

Realmente no veo el beneficio de hacer cumplir esto. La discusión parece cubrir también "." y ":", que a algunas personas les gusta usar en los nombres de los grupos. Personalmente no los uso, pero tampoco veo el daño en hacerlo.

Siempre que los proveedores de la nube utilicen guiones en su metainformación, deberíamos poder usarlos para agrupar. En realidad, ese ni siquiera debería ser el conductor. Si tengo ganas de nombrar abcde a un grupo, no debería ser un problema. Es un delimitador muy útil.

Sin embargo, este hilo no parece atraer la atención de los desarrolladores o mantenedores. Creo que estamos hablando para oídos sordos.

Desarrolladores / mantenedores: ¡Por favor, permita guiones en los nombres de los grupos!

Para aclarar algunos conceptos erróneos, parte de ellos se debieron a mis errores y a que los mensajes iniciales no fueran claros, las últimas versiones tienen correcciones para algunos de los problemas que la gente sigue planteando aquí, otras correcciones aún están llegando:

Solo para decir esto una vez, claramente, SIEMPRE PODRÁ USAR GUÍAS EN LOS NOMBRES DE GRUPO, también puntos y otros caracteres que ahora se consideran "no válidos", pero no de forma predeterminada. Este "predeterminado" es lo que está en desuso, el valor predeterminado será "seguro" en 2.11, pero siempre tendrá la opción de "aceptar" el comportamiento anterior.

Y para explicar cómo y por qué llegamos aquí:

Primero, los nombres de los grupos SIEMPRE se desinfectaban, solo tenían diferentes reglas inconsistentes, dependiendo del tipo de inventario que estaba usando, los scripts estaban por todas partes, los formatos YAML e INI hicieron cada uno lo suyo. El cambio principal fue 'centralizar y normalizar el saneamiento', esto se decidió en 2.4 pero no se implementó totalmente hasta 2.8. La intención era proporcionar una norma o línea de base que todos pudieran usar de manera segura en Ansilbe, que decía que reconocemos que hay muchas personas que usan caracteres 'inseguros' o 'inválidos' para las variables, por lo que lo hicimos configurable, no solo globalmente sino también por algunos de los complementos de inventario.

La implementación inicial tuvo algunos problemas y mucha discusión (no, no decidimos esto a escondidas, tenemos reuniones públicas en el irc a las que todos son bienvenidos, https://github.com/ansible/community/blob/master /meetings/README.md) y se incorporaron muchos de los comentarios (estos también se registran para que pueda volver a ver las discusiones y el razonamiento, pero para evitar 'bucear en el contenedor de registros', explicaré la mayoría de los problemas a continuación) . Después de salir en 2.8, obtuvimos otra ronda de comentarios y hemos estado arreglando algunos errores, como siempre obtener una desaprobación, no solo cuando se usa el valor predeterminado y especialmente con la redacción de la documentación y las advertencias.

• '¿Por qué los nombres de Python?'
  Principalmente porque Ansible usa Python y JInja (que también usa Python) y algunos usos de grupos (principalmente en nuestros primeros ejemplos, pero también muchos de terceros) pueden crear errores en los libros de jugadas, es decir, stuff: '{{ groups.gropup-name-with-dash ... }}' o peor a group.name.with.dots . Esto crea confusión para muchos usuarios que desean utilizar la función Jinja de 'notación de puntos para acceso variable' y es por eso que el valor predeterminado debería ser seguro para todos los usuarios. La mayoría de las personas en esta publicación pueden no estar de acuerdo con esto, pero este es un problema real para muchas personas y no debería ser una 'trampa' esperando a los usuarios nuevos o antiguos de Ansible. Aquellos que 'optan por no participar' son responsables de evitar el uso interrumpido en otras partes de Ansible.

• "¿Qué pasa si me gusta que cada inventario tenga un saneamiento diferente?"
  Bueno, aún puede desactivar el saneamiento 'central' y habilitar el de su fuente de inventario específica, los nuevos complementos de inventario más populares que sustituyen a los scripts antiguos tienen opciones agregadas para emular el comportamiento del script, en el peor de los casos, aún puede usar los scripts de inventario.

• '¿Por qué no los nombres de host / son los siguientes nombres de host?'
  Al igual que para los grupos, la desinfección de los nombres de host siempre ha existido, pero no ha cambiado, los nombres de host tienen requisitos diferentes, como ser resolubles por DNS.
  para conexiones de red o una ruta válida para conexiones chroot. Además, afortunadamente, hay pocos o ningún ejemplo de uso de nombres de host en notación de puntos, esto no ha sido una práctica común y se convertiría en un problema si la gente comenzara a usarlos repentinamente, pero a diferencia de los nombres de grupo, esto es algo que hemos evitado hasta ahora. Si se convierte en un problema en el futuro ... tampoco veo una buena solución.

Tenga en cuenta que este ticket específico (descripción / información no suficientemente buena) es algo que ya estoy abordando, espero solucionarlo pronto. En cuanto al resto de la discusión, los desarrolladores no usan Github como foro, algunos tickets se convierten en eso, el ticket anterior que está cerrado y también tiene un hilo largo fue ignorado hasta hace poco, principalmente porque los desarrolladores filtran los problemas cerrados y Espere discusiones en IRC, la lista de correo o nuevos temas.

Espero que esto aborde todos los problemas principales, como siempre estamos abiertos a la discusión, no dude en pasar por ML o IRC, simplemente evitamos usar github ya que no es un buen lugar para tales cosas.

Muchas gracias por la aclaración.

Le agradezco que se haya tomado el tiempo para explicar, aunque hubiera sido mucho más sencillo dejar de admitir la notación de puntos y desaprobar ese soporte en algunas versiones. Menos personas usan eso en comparación con la cantidad de personas que tienen caracteres no válidos en los nombres de sus grupos. Se la vie

@skyscooby el problema es que no es Ansible quien hace eso, es Jinja.

Solo para decir esto una vez, claramente, SIEMPRE PODRÁ USAR GUÍAS EN LOS NOMBRES DE GRUPO, también puntos y otros caracteres que ahora se consideran "no válidos", pero no de forma predeterminada.

Bien, es bueno saberlo, gracias por la aclaración. Sin embargo, la experiencia del usuario realmente debe mejorarse. Tienes la "maldición del conocimiento". Intente imaginarse en la piel de un usuario que ve esto:

[ADVERTENCIA DE DEPRECATION]: La configuración de TRANSFORM_INVALID_GROUP_CHARS está configurada para permitir caracteres incorrectos en los nombres de grupo de forma predeterminada, esto cambiará, pero seguirá siendo
configurable por el usuario en desuso. Esta función se eliminará en la versión 2.10. Las advertencias de obsolescencia se pueden desactivar configurando deprecation_warnings = False en ansible.cfg.
[ADVERTENCIA]: Se encontraron caracteres no válidos en los nombres de los grupos, pero no se reemplazaron, use -vvvv para ver los detalles

Eso es un largo, muy largo camino desde

[ADVERTENCIA DE DEPRECATION] El nombre de grupo 'my-servers' contiene '-', que dejará de ser válido de forma predeterminada a partir de Ansible 2.11. Establezca force_valid_group_names en ansible.cfg o la variable de entorno ANSIBLE_TRANSFORM_INVALID_GROUP_CHARS en "ignore" para suprimir esto. Consulte https://docs.ansible.com/something para obtener más información.

... que es lo que yo, como usuario, realmente hubiera querido ver. Me habría ahorrado más de una hora. Ahora multiplique por eso por el número de personas que tienen o se encontrarán con este problema.

Que los guiones y los puntos no sean válidos en los nombres de los grupos no es un valor predeterminado sensato. La gente siempre los tendrá en los nombres de sus grupos. Requerirles que establezcan otra variable en un archivo de configuración para permitir un comportamiento sensato es en mi humilde opinión indefendible.

Gracias @bcoca por tu comentario anterior. Es muy apreciado.

Aunque no estoy contento con la decisión, entiendo que hubo una discusión y se tomó una decisión. Si la decisión aún está abierta a debate, debería continuarse en la lista de distribución o en el irc, pero es posible que no refleje este problema.

Para el tema de esta edición, me gustaría encontrar la siguiente información en la documentación oficial y las guías de portabilidad, para estar al tanto de este cambio.

• ¿Cuáles son los nombres de grupo que son válidos por defecto?
• ¿Qué hacer para seguir usando nombres de grupo, incluidos guiones, guiones, puntos y dos puntos?

Porque usamos guiones en todos nuestros grupos y nombres de host y no cambiaremos eso. Así que tengo que optar por participar y cambiar mi ansible.cfg cada vez que configuro una nueva instalación / entorno. Eso es lamentable para mí, pero tengo que lidiar con eso de alguna manera. Lo mínimo que esperaría es que esto esté documentado en consecuencia.

Para continuar la discusión sobre si este cambio es prudente o no, abrí un hilo en el grupo de Desarrollo de Ansible.

Atentamente,
Tronde

Quiero agradecer a todos los colaboradores sobre este tema. En base a lo que leí aquí, decidí escribir una publicación de blog https://docs.sbarnea.com/ansible/naming-hosts-and-groups . Con suerte, resumiría lo que los usuarios deben hacer.

@ loop-evgeny Estoy de acuerdo en que nosotros, como equipo central, tenemos la "maldición del conocimiento" y nos inhibe de crear documentos y errores que sean útiles para todos. También confiamos completamente en la comunidad para ayudarnos a dar forma a ansible y mantenerlo simple para tantos usuarios como sea posible, por lo que cuando la gente tiene recomendaciones sobre cómo mejorar nuestros documentos y nuestros mensajes de error / advertencia, siempre los aliento a que nos ayuden enviando un solicitud de extracción. El mensaje que señala se encuentra en el siguiente archivo y le agradeceríamos mucho que nos enviara un PR con el cambio sugerido ...

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

@jctanner Por lo general, me complacería enviar un PR para mejorar un programa gratuito y útil que utilizo. Sin embargo, la actitud general de los desarrolladores de Ansible hacia la usabilidad, su afán por cerrar como "funcionan según lo previsto" problemas que considero errores evidentes (incluso si son errores de diseño) y el hecho de que Ansible actualmente tiene 2025 (eso es dos mil !) las relaciones públicas abiertas me dan muy poca confianza en que mi trabajo no se desperdiciará. Si realmente quieres "confiar en la comunidad", como dices, entonces se necesita un cambio cultural sustancial en mi humilde opinión.

Hmm ... Esa oportunidad también me golpeó.

Desafortunadamente, usamos nombres de redes como nombres de grupos y eso no se puede cambiar fácilmente. Me encantaría optar por no utilizar el azúcar de sintaxis de puntos para los nombres de grupo, ya que no es nada que haya usado nunca (aunque lo uso con otras variables).

Sería preferible utilizar ansible-playbook whatever.yaml -l some.network.to.use en el futuro. El uso de cualquier otro que no sea la red como nombre de grupo reduciría enormemente el caso de uso.

Hola,
Estoy algo confundido en este momento. ¿Alguien podría decirme qué tengo que configurar en ansible.cfg para permitir caracteres no válidos en los nombres de los grupos en el futuro, por favor?

force_valid_group_names = ignore

¿Cuál es la versión futura de ansible que se adapta a estos problemas? ¿En algún momento Ansible rechazará todos los guiones en el nombre del grupo sin una solución alternativa usando force_valid_group_names ? (sin escuchar comentarios de los usuarios que han sufrido por el cambio y que nunca han sufrido los problemas mediante el uso de guiones en los nombres de los grupos)

Lo siento. Solo lea los comentarios de @bcoca y feliz de ver que podría usar guiones si quiero en el futuro, eso es suficiente para mí.

Hola,
Veo la misma advertencia, pero no entiendo qué debería cambiar y si deberíamos cambiarlo.
¿Es algo relacionado con Python?
¿Cómo resolverlo?

Si ignoro con force_valid_group_names = ignore, sería con eso necesario, y cuando actualizo a Ansible> = 2.10?

Saludos,
Cesar Jorge

Si entiendo esto correctamente. Lo único que está en desuso es la transformación automática de nombres de grupos. Esto significa que debería estar bien configurar force_valid_group_names = ignore después de 2.10 y más allá.

También debería estar bien seguir usando guiones y lo que quieras en los nombres de los grupos. Lo que Ansible no hará en el futuro es desinfectarlos para que pueda usar la notación con puntos incluso para nombres de grupos "no válidos". Por ejemplo:

Su inventario contiene un grupo llamado foo-bar.xyz . Ahora desea escribir una plantilla que cree una lista de hosts que pertenecen a ese grupo:

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

Tenga en cuenta que la siguiente versión de la plantilla no funcionaría:

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

Esto se debe a que - y . tienen un significado especial en este caso. Sin embargo, la notación con puntos estaría bien si su grupo tuviera el nombre foo_bar_xyz porque la plantilla se convierte en:

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

Lo cual, por supuesto, está totalmente bien.

En un intento por facilitar las cosas a los usuarios, Ansible aparentemente siempre hizo algunos arreglos para los nombres de los grupos. Esto significa que era (y hasta 2.10 todavía es) posible usar foo_bar_xyz en los ejemplos anteriores, aunque el grupo en realidad se llama foo-bar.xyz . Personalmente, no creo que esto facilite las cosas en absoluto y parece que el equipo central ahora también está de acuerdo con eso.
Entonces, su próximo intento de abordar el problema es hacer que sea imposible tener nombres de grupos "inválidos" en primer lugar. Sin embargo, según tengo entendido, siempre será posible excluirse de esta limitación configurando force_valid_group_names = ignore .

En pocas palabras, en realidad son dos cambios diferentes que se han entrelazado [1] entre sí. De ahí el nombre y la redacción confusos de la advertencia.

Nuevamente, así es solo como entiendo el problema. ¡Por favor corrígeme si estoy equivocado!

[1] para más detalles, véase RFC1925, párrafo 2, punto (5).

Solo quería dejar mis 2 ¢ ya que estoy firmemente del lado de los guiones> guiones bajos. Con solo hacer una búsqueda rápida en

Incluso si ese no fuera el caso, el hecho de que veo guiones utilizados para cosas como etiquetas de servidor y grupos en la naturaleza con mucha más frecuencia que guiones bajos significa que esto será otra cosa que tendré que asegurarme de agregar a todos mis y los archivos ansible.cfg mis clientes (suelo tener uno por libro de jugadas).

No tengo ningún problema con que Ansible intente forzar un valor predeterminado más estricto donde mejore la experiencia, pero primero viniste por los guiones en los nombres de mis roles (y a veces permitiste excepciones singulares para roles más antiguos que estaban exentos), luego viniste por guiones en mis colecciones (no están permitidas de ninguna manera, forma o forma), ¡y ahora has venido a buscar guiones en mi inventario!

Es una guerra contra los guiones ... y quiero trazar una línea en algún lugar; en este caso, es el único lugar donde en realidad me es imposible evitar que las personas usen guiones, ya que muchos de los proveedores de inventario dinámico crean grupos basados ​​en en los nombres y etiquetas de los servidores, y muchas (si no la mayoría) de las organizaciones parecen etiquetar las cosas con guiones (por ejemplo, us-east-1a , no us_east_1a ).

No es divertido tener un valor predeterminado que casi siempre debe anularse para que el software funcione, pero parece que a partir de Ansible 2.11, ese será el caso.

Si todo se debe a que algunos usuarios que no están familiarizados con Jinja2 y Python no se dan cuenta de que something.with-some-dashes no es válido, yo diría que es mejor enseñarles "si hay guiones, debe usar la notación entre corchetes para el acceso a dict, por ejemplo, something['with-some-dashes'] . Incluso puedes mezclar los dos si es necesario. No es súper puro y holístico, pero no todos somos desarrolladores de Rust aquí ...

Muy bien dicho, Jeff. Estoy totalmente de acuerdo con usted aquí: este cambio será muy perturbador y, en lugar de solo requerir una migración única, cambiará el flujo de trabajo de una gran cantidad de usuarios. Ansible ya no funcionará de fábrica.

Los nombres de host no pueden incluir un guión bajo, por lo que en un mundo sano, el nombre de host de inventario no estaría obligado a hacerlo. Esto significa que nuestros inventarios ahora se verán bastante inconsistentes, con nombres de host que no pueden contener guiones bajos y grupos que no pueden contener guiones.

Por favor, no cambie el valor predeterminado.

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

Hola,
Estoy totalmente de acuerdo con Jeff aquí .

Pero como @bcoca dijo anteriormente, la mayoría de los desarrolladores no ven estas discusiones aquí de manera regular y este tema puede no ser el lugar adecuado para discutir el cambio porque se trata de la documentación correcta.

Para debatir, únase al hilo. ¿Es una buena idea cambiar la configuración predeterminada de TRANSFORM_INVALID_GROUP_CHARS? en Grupos de Google.

Grandes puntos Jeff.

No es divertido tener un valor predeterminado que casi siempre debe anularse para que el software funcione, pero parece que a partir de Ansible 2.11, ese será el caso.

Esta es la gran conclusión para mí de todas estas discusiones. Entiendo el problema que debe resolverse, pero la solución parece ser lo contrario de lo que se necesita. Facilita las cosas para el soporte, pero dificulta a los usuarios; esa es una solución al revés.

Si todo se debe a que algunos usuarios que no están familiarizados con Jinja2 y Python no se dan cuenta de que algo. Con-algunos-guiones no es válido, yo diría que es mejor enseñarles "si hay guiones, debe usar la notación entre corchetes para el acceso a dict, por ejemplo algo ['con-algunos-guiones']. Incluso puedes entremezclar los dos si es necesario.

Esta es la mejor solución, no romper cosas que se han utilizado durante años.

Gran comentario de @geerlingguy - ¡

Me gustaría agregar que como usuario de Ansible, ¿por qué debería necesitar saber qué es la sintaxis válida de Python? Habiendo usado Ansible durante mucho tiempo, entiendo que Ansible (y sus módulos) está escrito en Python, pero ¿por qué debería preocuparme por eso? Exponer ese hecho al usuario final es simplemente un mal diseño.

Similar a permitir solo JavaScript / Ruby / .NET / cualquier notación válida para cosas como nombres de usuario en una aplicación web. ¿Por qué le importaría al usuario final en qué idioma está escrita la aplicación?

Además de eso, introducir cambios importantes es un tema difícil, trato de evitar eso si es posible. Si tengo que hacer un cambio, normalmente dejo el comportamiento anterior existente como predeterminado y dejo que las personas opten por el nuevo comportamiento. ¿Por qué no se hizo esto aquí? ¿Por qué tengo que cambiar mi configuración o, peor aún, todo mi inventario? ¿Por qué no al revés?

Si un sistema requiere internamente tokens estrictamente compatibles, entonces el sistema debe generar los tokens internamente y crear una tabla de búsqueda que asocie los tokens internos con los datos del usuario. De esta manera, Ansible puede cambiar sus reglas de token según sea necesario y limitar el impacto en los usuarios. Los usuarios deben poder nombrar su inventario, roles, etc. como ellos o sus clientes consideren conveniente.

Me parece que este cambio puede tener el efecto opuesto al previsto (para disminuir las consultas de soporte):

Ahora no hay un delimitador admitido (por defecto) tanto por los nombres de host (que deberían poder resolverse por DNS, es decir, no contener guiones bajos) como los nombres de grupo (que no deberían contener guiones).

Definitivamente debería ser libre de nombrar cualquier host

El mié., Hace 14 años. 2019 16:16, Christian Pointner [email protected]
escribió:

Si entiendo esto
https://github.com/ansible/ansible/issues/56930#issuecomment-516863432
correctamente. Lo único que está en desuso es el automático
transformación de nombres de grupos. Esto significa que debería estar bien establecer force_valid_group_names
= ignorar después de 2.10 y posteriores.

También debería estar bien seguir usando guiones y lo que sea que
no quiero en nombres de grupos. Lo que Ansible no hará en el futuro es higienizar
para que pueda utilizar la notación de puntos incluso para nombres de grupos "no válidos". Para
ejemplo:

Su inventario contiene un grupo llamado foo-bar.xyz. Ahora quieres escribir
una plantilla que crea una lista de hosts que pertenecen a ese grupo:

{% para host en grupos ['foo-bar.xyz']%}
{{ anfitrión }}
{% endfor%}

Tenga en cuenta que esta versión de la plantilla no funcionaría:

{% para host en groups.foo-bar.xyz%}
{{ anfitrión }}
{% endfor%}

Esto se debe a que el - y el. tienen un significado especial en este caso. los
Sin embargo, la notación punteada estaría bien si su grupo tuviera la
nombre foo_bar_xyz porque la plantilla se convierte en:

{% para host en grupos.foo_bar_xyz%}
{{ anfitrión }}
{% endfor%}

Lo cual, por supuesto, está totalmente bien.

En un intento de facilitar las cosas a los usuarios, Ansible aparentemente siempre
hizo un poco de saneamiento para los nombres de los grupos. Esto significa que fue (y hasta las 2.10
todavía es) posible usar foo_bar_xyz en los ejemplos anteriores aunque
el grupo en realidad se llama foo-bar.xyz. Personalmente no creo que esto
facilita las cosas y parece que el equipo central ahora también está de acuerdo
con ese.
Entonces, su próximo intento de abordar el problema es hacer que sea imposible tener
nombres de grupo "no válidos" en primer lugar. Sin embargo, hasta donde yo lo entiendo
siempre será posible optar por no participar en esta limitación configurando force_valid_group_names
= ignorar.

Para resumir, en realidad son dos cambios diferentes los que se han
entrelazados [1] entre sí. De donde el nombre y la redacción confusos de
la advertencia.

Nuevamente, así es solo como entiendo el problema. Por favor corrígeme si estoy
¡incorrecto!

[1] para obtener más detalles, consulte RFC1925.
http://www.faqs.org/rfcs/rfc1925.html Párrafo 2, punto (5)

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/ansible/ansible/issues/56930?email_source=notifications&email_token=AA5N2CJCIELW7JWHC6OJ35DQEQHSPA5CNFSM4HPRGLKKYY3PNVWWK3TUL52HS4DFVREXG43KNMVN5W63 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AA5N2CIVT5PLD2QCAGGBK6LQEQHSPANCNFSM4HPRGLKA
.

Esta es realmente una decisión equivocada en mi sincera opinión. Y por la razón equivocada. ¿Reducir el número de solicitudes de soporte, de verdad?

Ansible, como herramienta, no debe imponer detalles específicos del idioma al usuario final. Ya estoy tan molesto con Terraform imponiéndome todo ese Golang en la garganta, ahora lo mismo está pasando aquí con Ansible y el estilo "pitónico". No me malinterpretes, trabajo bastante bien tanto con Go como con Python, pero cuando se trata de infraestructura como código, ¿por qué debería importarme? ¿Y qué pasó con la promesa de que YAML dicte la forma del código base a administrar? "Infraestructura como datos, que se puede leer y ejecutar", lo escuché tantas veces ... Hasta donde yo sé, a YAML no le importan en absoluto los guiones y los guiones bajos.

Por cierto, hay muchas cosas que no admiten guiones bajos. Nombres de host, regiones de AWS e ID para literalmente todo, solo por mencionar algunos realmente importantes. Buena suerte manteniendo todas las excepciones donde no se supone que suceda la transformación ...

Para las personas que vienen aquí solo en busca de una solución rápida sobre cómo hacer que esto desaparezca, simplemente agregue la línea force_valid_group_names = ignore a su ansible.cfg y sea feliz.

Tengo entendido que no puede usar la notación de puntos para variables con espacios de todos modos, y aunque nunca creo variables con espacios, desafortunadamente hay muchos proveedores que devuelven claves de diccionario con espacios a través de las respuestas de la API json. La opción sensata para mí parece cambiar a la notación de corchetes. Con suerte, configurar force_valid_group_names para ignorar no causa efectos nocivos en el futuro, quién sabe qué más se planea en el futuro con este cambio.

Esta es una decisión bastante terrible, especialmente cuando se trata de trabajar con inventarios dinámicos como con Openstack (y AWS).
Los nombres de instancia y las claves de metadatos que contienen "caracteres prohibidos" a menudo se devuelven como elementos de inventario y / o variables de grupo desde la nube subyacente. Esto hará que la vida sea un infierno para muchos administradores de Openstack (y AWS) que intentan administrar sus flotas utilizando metaetiquetas o ID de instancia como:
instancia-8ca09c33-f255-440f-9544-b0ab318c79d9
meta-os_ubuntu

Los desarrolladores de Ansible deberían tomarse en serio la opinión de $env-$role-[0..99] . ¿Se supone que debemos cambiar el nombre de todo para apaciguar a nuestros señores Ansible?

@ssbarnea Por un lado, estamos haciendo un impulso para permitir solo nombres de variables y otras claves similares, que son identificadores de Python válidos. Para explicar un poco más acerca de los nombres de grupos, causa un problema a los usuarios que intentan usar "sintaxis de puntos" como groups.foo-group , que no hace lo que el usuario espera. La cantidad de problemas y solicitudes de soporte causados ​​por pequeños problemas como estos nos ha llevado a buscar nombres de seguridad para asegurarnos de que no ocurran problemas como este.

Para aquellos que quieran conservar lo que consideramos caracteres no válidos, pueden optar por no participar en esta funcionalidad.

¿Cuánto tiempo se les permitirá a los usuarios optar por no participar en este comportamiento? ¿Habrá una opción de configuración permanente para deshabilitar este comportamiento en todas las versiones de ansible en el futuro, o solo será compatible hasta la 2.11? Me alegraría que la opción esté activada de forma predeterminada, siempre que siempre tenga la opción de desactivarla.

Si esto se convierte en una restricción estricta en 2.11+, es probable que pierda clientes que están sujetos a las restricciones de su organización (no todos los usuarios de ansible tienen el poder de dictar las convenciones de nomenclatura utilizadas por su empresa). Parece que este cambio también presentaría un desafío significativo para aquellos que usan ansible para administrar la infraestructura en la nube, donde los guiones tienden a ser muy utilizados.

Solo para recordarles a aquellos que no han leído todo el hilo aquí. También hay un hilo en la lista de correo de desarrollo: https://groups.google.com/forum/#!topic/ansible -devel / bjAcM9ferIw

En mi humilde opinión, este cambio fue una mala elección. Los cambios de sintaxis de descifrado de códigos en versiones de lanzamiento menores nos impiden extender el uso de Ansible en nuestro entorno. Porque no podré actualizar Ansible cuando rompa los libros de jugadas de mis usuarios.

Pero como @bcoca dijo anteriormente, la mayoría de los desarrolladores no ven estas discusiones aquí de manera regular y este tema puede no ser el lugar adecuado para discutir el cambio porque se trata de la documentación correcta.

@Tronde : uno podría argumentar que los contribuyentes Y los clientes son consultados antes de que se escriban las historias para comprender el impacto y recopilar comentarios mucho antes de que alguien codifique una solución. Como varios aquí han mencionado, este es un producto que falla en la administración que hemos visto más de una vez.

Como ejemplo de la situación que describe @andyfeller sobre este cambio:

Tenemos un problema con esto en nuestro sitio.

Usamos Red Hat Identity Manager como un inventario externo, no lo controlamos, contiene muchos grupos de hosts con guiones en lugar de guiones bajos. Esto no se cambiará (debido a todas las otras cosas que existen usando esos nombres).

Así que necesitamos:

• Para configurar Ansible para mantener el comportamiento actual
• Silenciar la advertencia de desaprobación
• Haga esto para la línea de comando Ansible y Ansible Tower

FYI PR https://github.com/ansible/ansible/pull/66650 (no hay horquillas allí) está programado para 2.10 (a partir del momento actual), lo que significa que cualquiera que vea esta advertencia actualmente lo haría (una vez que actualice a 2.10, nuevamente asumiendo que PR se fusiona) comienzan a tener fallas en el libro de jugadas en su lugar (hasta que establezcan force_valid_group_names = ignore en un ansible.cfg ).

Solo publicando para visibilidad. Todavía estoy firmemente detrás de mi afirmación anterior de que este es un valor predeterminado hostil para el usuario, ya que todavía hay muchos scripts de inventario dinámicos (alguna parte de Ansible en sí o ahora movidos a colecciones 'oficiales') que generan nombres de grupo con guiones o otros caracteres DNS válidos.

Prácticamente cualquiera que use Ansible con AWS tendrá que anular el valor predeterminado.

@geerlingguy ¿Es ese el número de relaciones públicas correcto? Parece que apunta a este problema.

Para su información, esto se discutió en una reunión principal aquí , a partir de 19:06:55

@ apple4ever oops, actualizó el enlace, es https://github.com/ansible/ansible/pull/66650

Así que he visto arriba muchos comentarios de cosas que ya fueron respondidas / desacreditadas / etc., así que solo voy a vincular aquí mi publicación anterior.

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

No agregue publicaciones nuevas que no agreguen elementos NUEVOS para la discusión, ya que ocultan las anteriores que ya fueron respondidas.

Por cierto, ¿dónde sería un buen lugar para enlazar en la documentación de Python sobre cómo se ven los nombres de variables válidos? Hay https://docs.python.org/3/reference/lexical_analysis.html#grammar -token-identifier, pero eso no es realmente fácil de usar ni legible para personas sin experiencia en informática.

El motivo de la pregunta es que no estoy seguro de si se ha abordado realmente la queja inicial real. Solo hay una advertencia de que algo anda mal, pero se necesita investigar mucho para averiguar qué exactamente y cómo uno, si está dispuesto o puede, podría elegir un nombre de grupo válido. Esperaría al menos un claro "El nombre del grupo foo-bar contiene caracteres no válidos ( - ). Los nombres de grupo válidos deben ser identificadores de Python válidos (consulte https://docs.python.org/??? para obtener más información)" mensaje, no sólo "hay caracteres incorrectos, verifique de nuevo con -vvvv para averiguar cuáles". Idealmente, esto también mencionaría que esto puede desactivarse, pero podría dar lugar a otros problemas inesperados (como hacer que a Ansible le resulte muy difícil distinguir los grupos foo-bar , foo.bar y foo_bar ).

Actualmente es más un mensaje de "Hiciste algo mal, arréglalo" sin una forma clara de cómo proceder, lo que también podría haber contribuido a la fuerte respuesta aquí.

@geerlingguy escribió en el comentario 56930 :

(hasta que establezcan force_valid_group_names = false en un ansible.cfg)

La documentación no menciona "falso" como valor válido para esta clave. Establecí el valor en 'ignorar', lo que debería funcionar. Pero, ¿es 'falso' una palabra clave no válida o es correcta y la documentación no está completa aquí?

@bcoca en un comentario anterior:

Solo para decir esto una vez, claramente, SIEMPRE PODRÁ USAR GUÍAS EN LOS NOMBRES DE GRUPO, también puntos y otros caracteres que ahora se consideran "no válidos", pero no de forma predeterminada. Este "predeterminado" es lo que está en desuso, el valor predeterminado será "seguro" en 2.11, pero siempre tendrá la opción de "aceptar" el comportamiento anterior.

Ha declarado repetidamente que el comportamiento actual se puede conservar, pero ¿cuáles son las configuraciones exactas de ansible.cfg necesarias para hacer esto _ahora_ y aplastar la advertencia de obsolescencia?

Lo intenté como @geerlingguy escribió en el comentario 56930:

(hasta que establezcan force_valid_group_names = false en un ansible.cfg)

Lo que hace que mis libros de jugadas fallen cuando no pueden encontrar hosts o grupos con guiones (provienen de un complemento de inventario que escribimos por cierto, las tesis también tienen que hacer la transformación, o se hace cuando Ansible ingiere el inventario de el complemento?)

Lo intenté como @geerlingguy escribió en el comentario 56930:

(hasta que establezcan force_valid_group_names = false en un ansible.cfg)

Lo que hace que mis libros de jugadas fallen cuando no pueden encontrar hosts o grupos con guiones (provienen de un complemento de inventario que escribimos por cierto, las tesis también tienen que hacer la transformación, o se hace cuando Ansible ingiere el inventario de el complemento?)

Esto se mencionó en varios comentarios y está en la documentación . Debe usar nunca o ignorar .

Entonces, ¿se supone que ya no debemos usar el script de inventario dinámico de EC2, ya que agrupa todo por 'us-east-1', 'us-east-2', etc.? ¿O hay un plan para actualizarlo? Acabo de consultar la documentación de Ansible para el script de inventario dinámico EC2 y el enlace para descargarlo en Github ya no funciona, así que eso es interesante.

Acabo de consultar la documentación de Ansible para el script de inventario dinámico EC2 y el enlace para descargarlo en Github ya no funciona, así que eso es interesante.

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

para aquellos de ustedes que no se molestan en leer el registro de IRC, aquí está la decisión, es decir, ninguna decisión:

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

sí, alguien escribió "siéntase libre de pasar por ML o IRC". no, "este proyecto no es una democracia".

sí, alguien escribió "siéntase libre de pasar por ML o IRC". no, "este proyecto no es una democracia".

Para ser honesto, esto está mal con el código abierto: si conduce a una forma no popular, la gente puede bifurcarlo, ¿se puede bifurcar?

Puedo ver que aceptar relaciones públicas en ansible es terriblemente lento. Los parches parecen obviamente necesarios y un cambio simple, pero nunca entra. Afortunadamente, ansible en sí mismo es flexible para permitir que las personas usen complementos personalizados, sin embargo, parece obsoleto, lo que me hará menos en contribuciones, o incluso más complicado hacerlo.

Sintiéndome un poco triste, de verdad ...

@ sunshine69 Siento tu dolor. Pero esa es una discusión que debería tener lugar en IRC o el Grupo de Google para el Desarrollo Ansible.

Este problema no es el lugar adecuado para ello. Porque para poca gente lee aquí.

@ sunshine69 Siento tu dolor. Pero esa es una discusión que debería tener lugar en IRC o el Grupo de Google para el Desarrollo Ansible.

Este problema no es el lugar adecuado para ello. Porque para poca gente lee aquí.

Si bien la discusión puede ser más productiva en esos otros canales, la transparencia es apreciada por las personas que siguen este tema específicamente. IRC no es la preferencia de todos, después de todo.

Para su información: la eliminación de la obsolescencia de TRANSFORM_INVALID_GROUP_CHARS se fusionó ayer. Hay PR de backport para 2.9 (https://github.com/ansible/ansible/pull/69487) y 2.8 (https://github.com/ansible/ansible/pull/69488) para eliminar las advertencias de desaprobación allí.

Archivos identificados en la descripción:

• lib/ansible/modules/group.py

Si estos archivos son incorrectos, actualice la sección component name de la descripción o use el comando !component bot.

haga clic aquí para obtener ayuda con el bot

Cuando configuré force_valid_group_names = ignore la ADVERTENCIA desapareció, pero el AVISO DE DEPRECACIÓN no desapareció.

Finalmente encontré en los documentos: force_valid_group_names = silently que hará el reemplazo y no obstruirá la salida, si eso es lo que está buscando hacer.

No obstante, todo este problema podría haberse evitado en primer lugar si no se hubieran realizado cambios inútiles como este en primer lugar.

@ emmm-dee: para ese problema en particular, abrí https://github.com/ansible/ansible/issues/70908 ; tenga en cuenta que este problema aún persiste, ya que todavía no hay documentación oficial para los caracteres de grupo _son_ 'válidos' .

¡Gracias a @geerlingguy por tus acciones! Tú eres el que está mejorando el ansible.

Estoy trabajando para nuestra aplicación de rebote (inicio / detención) pero no estoy conectado con el host de la aplicación.

Probé el comando ping, que enviaste y funciona ...

[ webadmin @ vlodjumpts00 ~] $ ping 8.8.8.8

PING 8.8.8.8 (8.8.8.8) 56 (84) bytes de datos.

64 bytes de 8.8.8.8: icmp_seq = 1 ttl = 112 tiempo = 10.6 ms

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

-bash: mirrorlist.centos.org: comando no encontrado

Quiero usar esto para nuestra organización ... si ejecuté el comando "ansible all -m ping". frente al error, a continuación se muestran los detalles:

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

cambiar, pero seguir siendo configurable por el usuario en desuso. Esta función se eliminará en la versión 2.10. Las advertencias de obsolescencia pueden ser

desactivado configurando deprecation_warnings = False en ansible.cfg.

RTE3EPAdmin | Inalcanzable! => {

"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 | ÉXITO => {

"ansible_facts": {

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

},

"changed": false,

"ping": "pong"

}

Por favor ayúdame ... qué necesito para hacer esto. En realidad, no tenemos UN / PWD para el archivo de hosts para conectar la máquina host.

localhost ansible_connection = local

[RTE3VFO]

RTE3VFOAdmin ansible_host = vlddwblasts001.test.intranet

RTE3VFOManaged ansible_host = vlddwblasts002.test.intranet

[RTE3EP]

RTE3EPAdmin ansible_host = vlddwblasts002.test.intranet

RTE3EPAnsible_host administrado = vlddwblasts003.test.intranet

[RTE3RES]

RTE3RESAdmin ansible_host = vlddwblasts003.test.intranet

RTE3RESAManged ansible_host = vlddwblasts004.test.intranet

[RTE3ORCH]

RTE3ORCHAdmin ansible_host = vlddwblasts004.test.intranet

RTE3ORCHAnsible_host administrado = vlddwblasts005.test.intranet

[RTE3EASE]

RTE3EASEAdmin ansible_host = vlddwblasts005.test.intranet

RTE3EASEManaged ansible_host = vlddwblasts006.test.intranet

[RTE3RTS]

RTE3RTSAdmin ansibke_host = vlddwblasts006.test.intranet

[EASE-ASR-Test2: niños]

RTE3VFO

RTE3EP

RTE3RES

RTE3ORCH

RTE3EASE

RTE3RTS

y la estructura del directorio es:

[ webadmin @ vlodjumpts00 ansible] $ pwd

/ etc / ansible

[ webadmin @ vlodjumpts00 ansible] $ ll

total 84

-rw ------- 1 webadmin webadmin 607 12 de julio de 2017 1

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

-rw-r - r-- 1 raíz raíz 19985 8 de diciembre de 2019 ansible.cfg.rpmnew

-rw ------- 1 webadmin webadmin 213 3 de julio de 2017 Easeasr-rte2-Ease.yml

-rwxr-xr-x 1 webadmin webadmin 1034 19 de septiembre 09:16 easy-hosts

-rwxr-xr-x 1 webadmin webadmin 1647 19 de septiembre 10:50 hosts

-rw ------- 1 webadmin webadmin 2679 3 de julio de 2017 hosts.bkp

-rw ------- 1 webadmin webadmin 273 6 de julio de 2017 lineinsfile_tst.yml

drwx ------ 4 webadmin webadmin 4096 2 de noviembre de 2017 playbooks

drwxr-xr-x 3 root root 19 de diciembre 8 de 2019 roles

-rwxr-xr-x 1 webadmin webadmin 7321 2 de noviembre de 2017 servmix_hosts

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

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

No estamos conectados directamente al host ... primero inicie sesión en nuestro servidor de salto y luego en el host ssh ...

el servidor de salto es el puerto "vmdcltctws217" usando = 22, tipo de conexión = ssh

y luego entrar con nuestro UN / PWD

después de eso hicimos sudo para la conexión al servidor host.

sudo su - easesqa

y luego servidor host ssh como ..

vlddwblasts001.test.intranet

luego ejecutamos el comando start / stop desde aquí.

Por favor ayúdame, ¿para qué puedo hacerlo?