Недавно я был предупрежден о существовании доступных обратных вызовов, которые, по-видимому, являются способом изменения некоторых значений по умолчанию при заданных условиях.
Тем не менее, я просмотрел доступную документацию, а также несколько книг, Google и исходный код, но, хоть убей, я не могу найти ответа на этот простой вопрос:
Как изменить элементы конфигурации, которые влияют на поведение доступных обратных вызовов?
-Например: при просмотре кода появляется обратный вызов почты, чтобы его можно было настроить для отправки почты на настраиваемый адрес электронной почты через настраиваемый узел SMTP. Как / где / когда это следует указывать?
Но если обратный вызов почты (и базовый класс для обратных вызовов) - это все, что нужно, на самом деле, похоже, Нет стандартный механизм конфигурации ..
Mail, например, получает SMTPHOST из переменной окружения, если она есть, и to: появляется прибитым к <root> (бесполезно, если почтовая программа настаивает на blah@fully.qualified.dom.ain как на действительных адресах).
Глядя на документы и некоторые из существующих подключаемых модулей обратного вызова, похоже, один метод использует среду.
Например, обратный вызов jabber просто использует дополнительные переменные env, чтобы обеспечить более детальную настройку.
Похоже, это относится ко многим другим обратным вызовам, и я не смог найти никаких примеров использования доступных переменных для таких целей.
Это, однако, предположительно возможно - проверка CallbackBase # _get_item кажется возможным пройти через доступные переменные, чтобы получить любую подходящую конфигурацию.
Однако я действительно думаю, что использование переменных среды кажется некоторой формой стандарта - хотя я согласен, что это не совсем строго определенный стандарт, если он действительно
Как вы говорите, обратные вызовы немного неясны, и, возможно, это одна из тех областей в недоступном, «если вам это нужно, вы будете знать, что делать».
В случае обратного вызова почты, возможно, лучше всего будет просто создать подкласс существующего плагина, чтобы добавить переменные конфигурации, которые, по вашему мнению, могут вам понадобиться.
Я лично чувствую, что обратные вызовы в целом считаются расширенной функцией, и что многие из доступных обратных вызовов больше предназначены в качестве основы (а в некоторых случаях как быстрый способ получить что-то) для расширения теми, кто нуждается в их функциональность. Но это чисто ощущение.
Я не уверен, правильно ли я вас понял, но я думаю, что вы правы в отношении черных ящиков, связанных с обратными вызовами, или также официальных модулей,
Я представляю модули python, такие как «команды» unix, они могут быть очень разными и принимать разные варианты, а архитектура затрудняет для команды ansible выполнение больших архитектурных изменений, поскольку это будет означать изменение / расширение всех существующих модулей (например, многих требуемые отчеты о ходе работ по запущенным модулям https://github.com/ansible/ansible/issues/3887 что означает, что у них нет возможности проверить, застрял ли модуль)
Чтобы иметь контроль над конфигурацией или изменять / сохранять их, я выбираю другой подход, чем просто написание обратных вызовов.
Я написал слой вокруг ansible, используя возможность динамической инвентаризации, и я использовал плагины обратного вызова вывода для форматирования вывода в json, чтобы иметь возможность анализировать вывод успешного запуска и сохранять изменения состояния / данных обратно в мою программу управления запасами. Таким образом, я могу изменять переменные или даже добавлять хосты в playbook с помощью простого вызова задач и автоматически применять их обратно к моему инвентарю без необходимости сильно изменять или расширять ansible и оставаться относительно совместимыми с будущими версиями.