Cp-ansible: Suporte para Ansible Galaxy

Alguma atualização sobre isso? Será muito mais fácil usar esses manuais

Atualmente não há planos para publicar na galáxia ansible. Vou registrar uma jira interna para ver como investigar isso para um lançamento futuro.

A expectativa geral é clonar o repo e, em seguida, executar o manual necessário para a configuração fornecida.

O Ansible 2.9 introduziu um novo formato de distribuição chamado Coleções. Parece ser a melhor opção para resolver esse problema, pois uma coleção pode incluir manuais, funções, módulos e plug-ins.

Algumas dicas:

• 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

Fiz uma tentativa de reestruturação como uma coleção de galáxias, testei trabalhando com o manual all.yml e algumas configurações básicas (ouvintes ssl e sasl / plain). Partes dele são muito desajeitadas, principalmente que, pelo que posso dizer, para fazer referência a quaisquer filtros e módulos, você precisa fazer referência a todo o namespace da galáxia. No entanto, funciona para o meu caso de uso e estou feliz em abrir um PR se a equipe achar que vale a pena adicioná-lo.

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

@ aig787 eu gosto! Sempre achei que os manuais de atualização deveriam estar em um diretório de "manuais"
As funções têm acesso ao que está no diretório de plug-ins certo?
O dir confluentinc_cp também é necessário?

Uma peça complicada é o ansible.cfg, sempre gostei de tê-lo ao lado dos manuais, porque exige que a configuração do ansible nesse arquivo seja usada durante a instalação

Todas as funções têm acesso ao que está no diretório de plug-ins (https://docs.ansible.com/ansible/devel/dev_guide/developing_collections.html#plugins-directory). Eu acho que você só precisa usar o nome completo para acessá-lo, por exemplo, eu tive que mudar KAFKA_OPTS: "{{ kafka_broker_final_java_args | java_arg_build_out }}" para KAFKA_OPTS: "{{ kafka_broker_final_java_args | aig787.confluent_cp.java_arg_build_out }}" para fazer o filtro funcionar para mim. Pode haver alguma maneira de contornar isso, mas eu não fui capaz de encontrar.

Tentei remover o diretório confluentinc_cp e funcionou bem, então acho que não é necessário. Inicialmente, inicializei com ansible-galaxy collection init e segui com a estrutura que criei.

Existe uma razão para o ansible.cfg não poder simplesmente ser movido para o diretório de manuais com o resto? _Acho_ que, para usar os manuais, as pessoas ainda precisariam clonar o repo e executá-lo como agora. A vantagem de tê-lo na galáxia seria mais para dar às pessoas acesso às funções em suas próprias configurações do que para tornar mais fáceis os manuais. De qualquer maneira, são meus 2 centavos.

Eu, pessoalmente, não me importo onde o ansible.cfg está colocado, apenas sei se você executa o manual e seu diretório atual não está onde o ansible.cfg está, então há problemas.

Eu posso ver o valor de aderir às melhores práticas do ansible e seguir a estrutura do diretório de coleções, mas estou curioso para saber quais são os benefícios de publicar esta coleção na galáxia. Mais visibilidade?

Para mim, parece uma grande sobrecarga para gerenciar versões na galáxia e em nossos ramos.

Seria um ganho de facilidade de uso. Se eu tiver um manual que faz alguma configuração básica para todos os meus nós, eu poderia adicionar isso a um arquivo de requisitos e executar `ansible-galaxy install -r requirements.yml 'e fazer referência à função kafka em meu manual existente ao invés de ter que clonar o repo e estender o playbook ou copiar os diretórios de funções ao redor.

Quanto ao motivo de você realmente ter que publicá-lo, não acredito que as coleções suportem referências git como as funções fazem (https://galaxy.ansible.com/docs/using/installing.html#installing-multiple-roles-from-a -file vs. https://docs.ansible.com/ansible/latest/user_guide/collections_using.html#install-multiple-collections-with-a-requirements-file). Eu concordo com a quantidade de overhead para versionamento, parece um pouco pesado.

Eu pessoalmente não me importo em tê-lo no Galaxy ou não, mas ser capaz de referenciar facilmente as diferentes funções em um arquivo de requisitos seria muito apreciado: sorria:

Estava prestes a registrar um novo problema, mas acho que meu problema está de alguma forma relacionado a esse problema. Então, começando com um comentário aqui para obter algum feedback inicial dos mantenedores e de outros que estão assistindo.

Quero usar as funções neste repositório, mas quero usá-las como dependências de funções em minhas funções personalizadas (extensões de função). Começamos usando o manual (all.yml), mas tivemos muitos problemas para aplicar nossas extensões no tempo correto. Meu primeiro problema (de bloqueio) com essa abordagem foi corrigido com https://github.com/confluentinc/cp-ansible/pull/442. Mas depois de olhar atentamente nossos registros para a execução do manual, percebi que podemos ter problemas adicionais:

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

Olhando para os detalhes, acho que o problema geral é que as funções atualmente não são independentes. Consertar isso seria uma etapa obrigatória para publicar as funções ou a coleção de funções no Ansible Galaxy. E eu acho que isso pode ser corrigido facilmente, uma vez que tudo se resume a referências aos seguintes diretórios de nível superior /filter_plugins e /tasks de dentro das funções.

O que você pensa sobre as seguintes tarefas como solicitações pull:

1. Mover a pasta /filter_plugins para a função confluent.variables - tornando-a parte dessa função? Os plug-ins de filtro estão pelo menos em uso nesta função.

2. Mova os arquivos de tarefas reutilizáveis ​​em /tasks para uma das funções existentes, provavelmente confluent.common é a que melhor se encaixa nas funções existentes, ou criando uma nova função dedicada para eles ( confluent.common_tasks )? E atualize as referências aos arquivos de tarefas reutilizados com include_role # tasks_from . Exemplo:

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 É algo que discutimos internamente no passado. Em particular, houve muita discussão sobre funções independentes, em vez de minimizar a duplicação de código. Parece que teremos que mudar isso para o 2.12. liberação de Ansible, com base no aviso, então estou pensando que pode fazer mais sentido mover tanto /filter_plugins quanto /tasks para a função confluent.common e, em seguida, usar instruções de importação em todas as outras funções.

@domenicbove quais são seus pensamentos?

Não tenho problemas em mover locais de arquivos, desde que a funcionalidade permaneça consistente @erikgb @JumaX.
Este parece ser um trabalho grande o suficiente para que ele vá para o branch master, visando nosso próximo lançamento.

@domenicbove Concordou em ser um trabalho para nosso próximo grande lançamento. @erikgb Adicionaremos um JIRA interno para rastrear isso e ver se podemos colocá-lo no roadmap de nosso próximo lançamento.

Ou @erikgb Se você tem o trabalho em um branch, você está convidado a fazer um PR no branch master e nós faremos uma revisão. Eu não acho que isso resolverá esse problema em sua totalidade, porém, ainda precisamos fazer a galáxia.

Próximo lançamento importante ? Seria a Confluent Platform 7? Essa mudança poderia ser tornada compatível com versões anteriores, eu acho - desde que se considere que os principais pontos de entrada são os manuais e os papéis. Eu preferiria consertar isso antes do PC 7. 😄

@erikgb seria para CP 6.1, tendemos a não colocar novas funcionalidades, especialmente se envolver uma grande refatoração em lançamentos mais antigos. Temos muitos clientes corporativos que têm políticas / problemas quando alteramos muito o repositório para a versão existente, tentamos mantê-lo apenas com correções de bugs.

@domenicbove @JumaX CP 6.1 faz mais sentido. Vou ver se consigo algum tempo para trabalhar na (s) solicitação (ões) pull no final desta semana. Eu recomendaria dividir a refatoração em partes significativas. WDYT?

@erikgb Se você quiser dividi-lo em vários