Cp-ansible: Asistencia de Ansible Galaxy

¿Alguna actualización al respecto? Será mucho más fácil usar estos manuales

Actualmente no hay planes para publicar en ansible galaxy. Presentaré una jira interna para ver si se investiga esto para una versión futura.

La expectativa general es clonar el repositorio y luego ejecutar el libro de jugadas requerido para la configuración dada.

Ansible 2.9 introdujo un nuevo formato de distribución llamado Colecciones. Parece más adecuado para resolver este problema, ya que una colección puede incluir libros de jugadas, roles, módulos y complementos.

Algunos consejos:

• https://www.ansible.com/blog/getting-started-with-ansible-collections
• https://docs.ansible.com/ansible/latest/user_guide/collections_using.html
• https://docs.ansible.com/ansible/latest/dev_guide/developing_collections.html

Intenté reestructurarme como una colección de galaxias, probé trabajar con el libro all.yml jugadas

https://github.com/aig787/cp-ansible/tree/agriffin/5.4.1-repack

@ aig787 ¡ Me gusta! Siempre sentí que los libros de jugadas de actualización deberían estar en un directorio de "libros de jugadas"
Los roles tienen acceso a lo que hay en el directorio de complementos, ¿verdad?
¿También es necesario el directorio confluentinc_cp?

Una pieza complicada es ansible.cfg, siempre me ha gustado tenerlo junto a los libros de jugadas, porque requiere que la configuración ansible en ese archivo se use durante la instalación

Todos los roles tienen acceso a lo que está en el directorio de complementos (https://docs.ansible.com/ansible/devel/dev_guide/developing_collections.html#plugins-directory). Creo que solo tienes que usar el nombre completo para acceder a él, por ejemplo, tuve que cambiar KAFKA_OPTS: "{{ kafka_broker_final_java_args | java_arg_build_out }}" a KAFKA_OPTS: "{{ kafka_broker_final_java_args | aig787.confluent_cp.java_arg_build_out }}" para que el filtro funcionara para mí. Puede que haya alguna forma de evitarlo, pero no pude encontrarlo.

Intenté con el directorio confluentinc_cp eliminado y funcionó bien, así que supongo que no es necesario. Inicialmente lo arranqué con ansible-galaxy collection init y seguí la estructura que creó.

¿Hay alguna razón por la que ansible.cfg no se pueda mover al directorio de playbooks con el resto? Creo que, para poder usar los libros de jugadas, la gente aún necesitaría clonar el repositorio y ejecutarlo como lo hacen ahora. La ventaja de tenerlo en Galaxy sería más que permitir que las personas accedan a los roles en sus propias configuraciones que hacer que los libros de jugadas sean más fáciles. De todos modos, esos son mis 2 centavos.

Personalmente, no me importa dónde se coloca ansible.cfg, solo sé que si ejecuta el libro de jugadas y su directorio actual no está donde está ansible.cfg, entonces hay problemas.

Puedo ver el valor de adherirse a las mejores prácticas de Ansible y seguir la estructura del directorio de colecciones, pero tengo curiosidad por saber cuáles son los beneficios de publicar esta colección en Galaxy. ¿Más visibilidad?

A mí me parece una gran sobrecarga administrar el control de versiones en galaxy y en nuestras sucursales.

Sería una ganancia de facilidad de uso. Si tengo un libro de jugadas que hace alguna configuración básica para todos mis nodos, podría agregar esto a un archivo de requisitos y ejecutar `ansible-galaxy install -r requirements.yml 'y hacer referencia al rol de kafka en mi libro de jugadas existente en lugar de tener que clonar el repositorio y amplíe el libro de jugadas o copie los directorios de roles.

En cuanto a por qué tienes que publicarlo, no creo que las colecciones admitan referencias de git como lo hacen los roles (https://galaxy.ansible.com/docs/using/installing.html#installing-multiple-roles-from-a -archivo frente a https://docs.ansible.com/ansible/latest/user_guide/collections_using.html#install-multiple-collections-with-a-requirements-file). Estoy de acuerdo con la cantidad de gastos generales para el control de versiones, parece un poco pesado.

Personalmente, no me importa tenerlo en Galaxy o no, pero sería muy apreciado poder hacer referencia fácilmente a los diferentes roles en un archivo de requisitos: smile:

Estaba a punto de registrar un nuevo problema, pero creo que mi problema está relacionado de alguna manera con este problema. Entonces, comenzando con un comentario aquí para obtener algunos comentarios iniciales de los mantenedores y otros espectadores.

Quiero usar los roles en este repositorio, pero quiero usarlos como dependencias de roles en mis roles personalizados (extensiones de rol). Comenzamos usando el libro de jugadas (all.yml), pero tuvimos muchos problemas para aplicar nuestras extensiones con el tiempo correcto. Mi primer problema (de bloqueo) con este enfoque se solucionó con https://github.com/confluentinc/cp-ansible/pull/442. Pero después de mirar de cerca nuestros registros para la ejecución del libro de jugadas, me doy cuenta de que podríamos tener problemas adicionales:

[DEPRECATION WARNING]: Included file 
'/builds/kafka/provisioner/tasks/failure_handling.yml' not found, however since
 this include is not explicitly marked as 'static: yes', we will try and 
include it dynamically later. In the future, this will be an error unless 
'static: no' is used on the include task. If you do not want missing includes 
to be considered dynamic, use 'static: yes' on the include or set the global 
ansible.cfg options to make all includes static for tasks and/or handlers. This
 feature will be removed from ansible-base in version 2.12. Deprecation 
warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.

Mirando los detalles, creo que el problema general es que los roles actualmente no son autónomos. Arreglar eso sería un paso obligatorio para eventualmente publicar los roles o la colección de roles en Ansible Galaxy. Y creo que esto se puede solucionar con bastante facilidad, ya que se reduce a referencias a los siguientes directorios de nivel superior /filter_plugins y /tasks dentro de los roles.

¿Qué opinas sobre las siguientes tareas como solicitudes de extracción?

1. Mueva la carpeta /filter_plugins a la función confluent.variables , ¿haciéndola parte de esa función? Los complementos de filtro están al menos en uso en esta función.

2. Mueva los archivos de tareas reutilizables en /tasks a uno de los roles existentes, probablemente confluent.common sea ​​el que mejor se ajuste a los roles existentes, o cree un nuevo rol dedicado para ellos ( confluent.common_tasks )? Y actualice las referencias a los archivos de tareas reutilizados con include_role # tasks_from . Ejemplo:

Index: roles/confluent.zookeeper/tasks/health_check.yml
<+>UTF-8
===================================================================
--- roles/confluent.zookeeper/tasks/health_check.yml    (revision 0d369ae20c8215dd2ec469f269dc804539f58190)
+++ roles/confluent.zookeeper/tasks/health_check.yml    (date 1602793473938)
@@ -25,7 +25,9 @@
   ignore_errors: true

 - name: Fetch Files for Debugging Failure
-  include: tasks/failure_handling.yml
+  include_role:
+    name: confluent.common
+    tasks_from: failure_handling.yml
   vars:
     service_name: "{{zookeeper_service_name}}"
     config_file: "{{zookeeper.config_file}}"

@erikgb Es algo que hemos discutido internamente en el pasado. En particular, hubo bastante discusión sobre roles autónomos, versus minimizar la duplicación de código. Parece que tendremos que cambiar esto para la 2.12. lanzamiento de Ansible, según la advertencia, por lo que creo que puede tener más sentido mover tanto /filter_plugins como /tasks al rol confluent.common , y luego usar el Importar declaraciones en todos los demás roles.

@domenicbove ¿cuáles son tus pensamientos?

No tengo ningún problema con mover ubicaciones de archivos siempre que la funcionalidad se mantenga constante @erikgb @JumaX.
Sin embargo, esto parece un trabajo lo suficientemente grande como para ir a la rama maestra, apuntando a nuestra próxima versión.

@domenicbove Estuvo de acuerdo en que sería trabajo para nuestro próximo lanzamiento importante. @erikgb Agregaremos un JIRA interno para rastrear esto y ver si podemos

O @erikgb. Si tiene el trabajo en una sucursal, puede hacer un PR en la sucursal maestra y lo revisaremos. Sin embargo, no creo que eso resuelva este problema en su totalidad, todavía necesitamos hacer galaxia.

¿Próxima versión importante ? ¿Sería Confluent Platform 7? Este cambio podría hacerse compatible con versiones anteriores, creo, siempre que se considere que los principales puntos de entrada son los libros de jugadas y los roles. Preferiría arreglar esto antes del CP 7. 😄

@erikgb sería para CP 6.1, tendemos a no poner nuevas funcionalidades, especialmente si implica una refactorización importante en versiones anteriores. Tenemos muchos clientes empresariales que tienen políticas / problemas cuando cambiamos demasiado el repositorio para la versión existente, tratamos de mantenerlo solo para corregir errores.

@domenicbove @JumaX CP 6.1 tiene más sentido. Veré si tengo algo de tiempo para trabajar en las solicitudes de extracción más adelante esta semana. Recomendaría dividir la refactorización en partes significativas. WDYT?

@erikgb Si desea dividirlo en varios RP, está bien asumiendo que cada RP puede seguir funcionando sin un RP adicional. No estoy seguro de haber dicho eso muy bien. :). Debería apuntar a la Rama Maestra.