Passando parâmetros para retornos ansible

Question

Recentemente, fui alertado sobre a existência de retornos de chamadas ansiosos, que parecem ser uma maneira de modificar alguns dos padrões sob determinadas condições.

No entanto, eu vasculhei a ansiosa documentação, bem como alguns livros, o google e o código-fonte, mas, para minha vida, não consigo encontrar a resposta para essa pergunta simples:

Como alguém pode alterar os itens de configuração que afetam o comportamento de retornos ansiosos?

-E.g: o retorno de chamada de correio aparece, olhando para o código, para poder ser configurado para enviar email para um endereço de email configurável através de um host SMTP configurável. Como / onde / quando isso deve ser especificado?

Mas, se o retorno de chamada de e-mail (e a classe base para retornos de chamada) for qualquer coisa, parece que existe um mecanismo de configuração padrão NÃO .

O Mail, por exemplo, obtém SMTPHOST de uma variável de ambiente se estiver lá, e para: aparece pregado em < root > (não é bom se o remetente insistir em [email protected] como endereços válidos).

    

Answer 1

Analisando os documentos e alguns dos plug-ins de retorno de chamada existentes, aparece um método estar usando o ambiente.

Por exemplo, o retorno de chamada do jabber simplesmente usa ' mais 'env vars para permitir uma configuração mais granular.

Este parece ser o caso de muitos dos outros callbacks, e eu não encontrei nenhum exemplo de uso de variáveis ansible para tais propósitos.

Isso, no entanto, é presumivelmente possível: verificar a CallbackBase método #_get_item , parece possível percorrer as variáveis ansible para obter qualquer configuração que seja apropriada.

No entanto, eu acho que usar variáveis de ambiente parece ser alguma forma de padrão - embora eu concorde que não é exatamente um padrão strongmente definido se de fato for um

Como você disse, os retornos de chamada são um pouco obscuros, e pode ser que seja uma dessas áreas 'se você precisar, você saberá o que fazer' em ansible.

No caso do retorno de chamada de correio, pode ser sua melhor aposta apenas subclassificar o plug-in existente para adicionar as variáveis de configuração que você acha que deseja.

Pessoalmente, tenho a sensação de que os retornos de chamada são em geral considerados um recurso avançado, e que muitos dos retornos de chamada disponíveis são mais pretendidos como uma base (e, em alguns casos, como um hack rápido para obter algo) para ser estendido por aqueles que precisam de sua funcionalidade. Mas isso é puramente um sentimento.

    

Answer 2

Eu não estou certo se eu entendi corretamente, mas eu acho que você está certo sobre as caixas pretas dos callbacks ou também dos módulos oficiais,

Eu imagino os módulos python como "comandos" unix eles podem ser muito diferentes e aceitam opções diferentes e a arquitetura torna difícil para a equipe ansible fazer grandes mudanças arquitetônicas já que isso significaria modificar / estender todos os módulos existentes (como como os muito exigidos relatórios de progresso sobre os módulos em execução link , o que significa que eles não têm como verificar se um módulo está emperrado)

Para ter controle da configuração ou alterá-la / persisti-la, escolho outro endereço do que apenas escrever callbacks.

Eu escrevi uma camada em torno de ansible usando o recurso de inventário dinâmico e usei plugins de retorno de chamada para formatar a saída em json para poder analisar a saída de uma execução bem-sucedida e salvar estados / dados de alterações em meu programa de gerenciamento de inventário . Dessa forma eu posso mudar variáveis ou até mesmo adicionar hosts no playbook com chamadas de tarefas simples e aplicá-las automaticamente de volta ao meu inventário sem precisar modificar ou estender bastante e permanecer relativamente compatível com versões futuras.