Ansible: Varios archivos en el directorio de valores predeterminados del rol

puede tener un main.yml en tasks , que incluye otros archivos, incluso en subdirectorios de tasks , por ejemplo, para configurar sus dos componentes principales foo y la barra de ese gran rol:

- include: foo/main.yml
- include: bar/main.yml

El uso de un módulo include_vars para las variables de función predeterminadas anula la razón por la que existen las variables predeterminadas en primer lugar, es decir, se utiliza para proporcionar "valores predeterminados de último recurso" que pueden ser fácilmente reemplazados por otras partes del libro de funciones / estrategias.

La idea de varios archivos en el directorio defaults/ se discutió previamente en IRC, llegamos a la conclusión de que analizar el directorio defaults/ manera similar a los directorios inventory/group_vars/ y inventory/host_vars/ sería Agradable tener. El código necesario ya existe y, con suerte, se puede adaptar fácilmente a los valores predeterminados de los roles.

+1

+1

¡Sería bueno tenerlo!

+1

Sí, solo asumí que los valores predeterminados / * se encontraron y cargaron automágicamente como se mencionó anteriormente. Parece que la solución alternativa sugerida (incluidos los archivos de valores predeterminados adicionales en las tareas) anulará las variables de inventario debido a la

Precedencia de variables de Ansible 2.x

    role defaults [1] (loading all role defaults here critical)
    inventory vars [2]
    inventory group_vars
    inventory host_vars
    playbook group_vars
    playbook host_vars
    host facts
    registered vars
    set_facts
    play vars
    play vars_prompt
    play vars_files
    role and include vars (hack coming in here will override everything above)
    block vars (only for tasks in block)
    task vars (only for the task)
    extra vars (always win precedence)

Esto puede estar relacionado con # 8121

+1

+1

Definitivamente una característica imprescindible debido a las restricciones de precedencia de variables.
Esto también permite definir un archivo de valores por defecto por clase de variables y mantener una separación limpia; por ejemplo, en redes, esto me permitiría definir un archivo predeterminado para IPv4, uno para IPv6, uno para SNMP y así sucesivamente ...
Por fin, parece necesario poder poner estos archivos en diferentes carpetas bajo "valores predeterminados".

Solo golpeo este yo mismo, así que definitivamente +1

Esto realmente es un PITA.
Si pudiera sugerir una solución, sería agregar una opción, similar a include_vars , pero en meta/main.yml , para especificar el orden de carga.

- dependencies: []
- default_vars:
  - "main.yml"
  - "{{ ansible_os_family }}-{{ ansible_distribution_major_version }}.yml"

Esto permitiría que la opción por defecto sea ["main.yml"] y no romper el código existente, mientras que da a los desarrolladores la capacidad de definir variables granulares basadas en contextos de su elección.

Extraño. Sospechaba totalmente que esto funcionaría de inmediato. Una de las pocas veces que ansible viola un poco el principio de la menor sorpresa ...

Definitivamente +1

Por vars/ lo mismo, pero parece que # 2958 estaba decidiendo en contra de esto

El ejemplo de @cornfeedhobo coincide exactamente con mi caso de uso. Al usar include_vars, evito que las jugadas anulen fácilmente cualquier variable individual.

Otra opción de interfaz sería:

• Agregue una opción al módulo include_vars, 'as_default', que procesa el archivo incluido como si estuviera en los valores predeterminados.

Para mí, realmente parece extraño / contrario a la intuición que haya un directorio "predeterminado" con un solo archivo en él.
Quiero decir, ¿alguna vez has visto un módulo de Python con un solo archivo __main__.py en él?

Precisamente por eso pensé intuitivamente que la funcionalidad de la que se habla en este ticket ya estaba presente. "Por supuesto que puedo tener varios archivos predeterminados, hay un directorio para ello"

include_role permite especificar archivos 'alternativos' ahora http://docs.ansible.com/ansible/include_role_module.html a través de la opción defaults_from

Acabo de entrar en una situación en la que se desea dividir defaults/main.yml . Agregué mi 👍 al problema.

Lo mismo aquí, yo también lo necesito
+1

+1

@bcoca, eso es una buena adición y agrega flexibilidad, pero no aborda el problema aquí, y pone la responsabilidad en el escritor del libro de jugadas, cuando la intención es empoderar al rol para establecer valores predeterminados cuerdos fácilmente.

Por favor revise mi comentario arriba

Sí, esta es una característica muy útil para evitar archivos con 2k líneas.
+1

+1

+1

👍

+1

+1

+1
El mismo problema aquí. main.yml demasiado grande, dividido en varios archivos. Asumimos que "simplemente funcionaría" y cargaría todas las vars en los archivos bajo defaults / ya que es un directorio. sin alegría.

+1

+1

+1

👍

+1

+1

👍

Ustedes pueden rechazar cada comentario +1, pero dudo mucho que puedan rastrear la cantidad de suscriptores, por lo que agregar +1 sigue siendo una forma decente de mostrar el apoyo deseado.

Hasta que la atención del problema esté claramente vinculada a la cantidad de suscriptores a un problema, siempre espere ver comentarios +1.

Lo que puede esperar es que el equipo ansible bloquee los comentarios del problema, así que no sea un spammer y no los defienda, por favor.

Lo que puede esperar es que el equipo ansible bloquee los comentarios del problema, así que no sea un spammer y no los defienda, por favor.

Podrían hacer eso, pero este es un problema central para poder desarrollar roles adecuadamente, especialmente desde la introducción de include_role en 2.x junto con el antiguo método de inclusión roles . Si diseña su rol para que sea compatible con include_role , lo cual es preferible ya que hace que el desarrollo sea mucho más modular y flexible que con el antiguo método roles solo, entonces se queda con tener para rastrear la inclusión de los valores predeterminados usted mismo como tareas en sus libros de jugadas, pasarle el dinero al usuario final, que no debería tener que saber cómo hacer esto para que su función funcione correctamente, o rastrear la plataforma / distribución / lanzamiento como un nivel anidado de su variables de rol que complican muchísimo el desarrollo (aunque funciona ya que he creado un rol que puede admitir 20 versiones de plataforma diferentes aquí ). ¿De verdad ha intentado escribir un rol que sea compatible con más de unas pocas plataformas? No es de extrañar por qué la mayoría de los roles en Ansible Galaxy no lo hacen, este problema probablemente sea el número uno en esa lista, en mi opinión.

Entonces, si fueron a bloquear esto, no respondieron en absoluto a un problema de un año y le dijeron a la comunidad que no están interesados ​​en discutir los problemas críticos que impiden que las personas creen soluciones reales, entonces definitivamente pueden esperar que las personas no se queden alrededor y continúe usando el producto. Si responden y dan una idea de si están de acuerdo en que es un problema, entonces tal vez la gente deje de hacer +1 para llamar la atención sobre el problema.

Esto es solo un problema porque lanzaron include_role sin pensar en cómo su uso en la práctica afectaría los valores predeterminados. Obligar a alguien a elegir entre usar roles y include_role para que un rol funcione correctamente o agregar trabajo adicional para permitir que ambos funcionen simultáneamente es el núcleo del problema aquí.

Mis 2 centavos.

PD: si estás votando en contra de los +1 porque no quieres las notificaciones ... presiona el botón para cancelar la suscripción en la parte superior derecha y ya no las recibirás.

Bien, este tema es importante para ti. Entiendo el punto. Para mí también. Por eso estoy suscrito, por cierto, y por eso no quiero darme de baja, y por eso rechazo a los spammers, y por eso acepto el comentario original , que es la forma civilizada de mostrar el apoyo de _lazy_.

Me gustaría agregar mi voz a la solicitud de esta capacidad y detallar mi caso de uso. Además de la capacidad simple de dividir main.yml grande, la capacidad de hacer algo como esto sería excelente:

- name: Some name
  include_default_vars:
  with_first_found:
    - "{{ ansible_os_family }}-{{ ansible_distribution_major_version }}.yml"
   - main.yml

Lo que espero lograr con esto es [como ejemplo] un rol openssh que admita todas las opciones ssh_config y sshd_config, y admita múltiples sistemas operativos y versiones [es decir. Debian 8/9, EL6 / 7, etc.] pero que si se llama sin vars configuradas por el usuario, construirá de forma segura la configuración a la configuración predeterminada de OS_majorversion, pero que puede tener CUALQUIER opción disponible anulada por el usuario.

Tal como está ahora, si pongo esos valores predeterminados del sistema operativo en include_vars, la precedencia es demasiado alta y el usuario no puede anular esas configuraciones en el inventario, o en group_vars / all o en group_vars / groupname o en host_vars, etc.

Estoy seguro de que hay una manera de hacer esto ahora, pero cualquier cosa que se me ocurra es tremendamente desagradable y fea y sería difícil de mantener. Además, al menos hasta este momento, nadie con el que me haya encontrado #ansible tiene mejores ideas sobre cómo hacer esto de una manera elegante y fácil de mantener.

Agregar esta función permitiría esto y puede ayudar a que los roles de mayor calidad estén disponibles en github / galaxy.

@ ralphie02 no, eso no es una solución para lo que trata este hilo. Eso es solo variables normales basadas en el host que es diferente del requisito de establecer valores predeterminados para un rol multiplataforma.

Vars / feature_idea similares: https://github.com/ansible/ansible/issues/11639

Esto realmente es un PITA.
Si pudiera sugerir una solución, sería agregar una opción, similar a include_vars , pero en meta/main.yml , para especificar el orden de carga.

- dependencies: []
- default_vars:
  - "main.yml"
  - "{{ ansible_os_family }}-{{ ansible_distribution_major_version }}.yml"

Esto permitiría que la opción por defecto sea ["main.yml"] y no romper el código existente, mientras que da a los desarrolladores la capacidad de definir variables granulares basadas en contextos de su elección.

Realmente creo que esta es una buena solución, no hay una manera realmente fácil en este momento de tener un conjunto diferente de valores predeterminados por sistema operativo / versión / etc. Esta implementación también mantiene la compatibilidad con versiones anteriores, por lo que también es una buena opción.

En línea con @abedwardsw (comentar antes):
La propuesta de más de 2 años de :! ) (O un poco más reciente de @ doubletwist13 ) sería realmente útil para muchos roles que conozco, en particular los suficientemente complejos:
https://github.com/hortonworks/ansible-hortonworks

Referencias directas a sus comentarios:

• https://github.com/ansible/ansible/issues/14248#issuecomment -254059046
• https://github.com/ansible/ansible/issues/14248#issuecomment -329027052

Vea también la propuesta de @geerlingguy (¡de 2016!), Y mi comentario allí (que intenta recopilar problemas relacionados): https://github.com/ansible/proposals/pull/21#issuecomment -470048538