Puppet/applicability of manifests and modules on ALT

Хочется разработать механизмы для:

• проверки соответствия произвольного модуля или манифеста текущему состоянию репозитория пакетов Sisyphus (все ли требуемые ресурсы найдутся; похоже на автопоиск зависимостей при сборке rpm);
• применения неадаптированного для ALT манифеста и модуля (ведь на puppet-мастере могут не знать про ОС ALT) с помощью "перевода" ресурсов для ALT перед выполнением (с обращением к distromap).

Типы ресурсов в puppet: package, file (path), service etc. (Это абстрактные сущности, которые могут быть по-разному реализованы на разных ОС в разных случаях.)

Эти механизмы можно назвать puppet-агентами специального вида:

• агент, печатающий каталог, но ничего не делающий;
• агент, представляющийся другой ОС при обращении к puppet-мастеру, а потом переводящий ресурсы в полученном каталоге в ALTовые.

distromap для неадаптированных к ALT манифестов и модулей

Как это могло бы работать: сначала получить от puppet-мастера каталог, представившись другой ОС, потом выполнить, переводя ресурсы в ALTовые.

сначала получить от puppet-мастера каталог, представившись другой ОС

• puppet catalog download с выставленными переменными окружения для изменения фактов об ОС для ruby-facter:

Retrieves a catalog from the puppet master and saves it to the local yaml cache. This action always contacts the puppet master and will ignore alternate termini.

The saved catalog can be used in any subsequent catalog action by specifying '--terminus yaml' for that action.

 Скаченный этой командой каталог не получается применить: предлагаемые команды на самом деле приводят к ошибке, а в опытах с другой командой с --use_cached_catalog тоже что-то не получается: мы хотим скачать каталог для одного варианта ОС, а выполняется в итоге другой, старый, для другой ОС.

• поведение опции --noop для puppet agent было модифицировано, чтобы сохранять скаченное.

 Этим путём мы и пользуемся -- в сочетании с --use_cached_catalog потом.

потом выполнить сохранённый каталог

• puppet apply -t -d --apply mytest.yaml -- how do I apply the compiled catalog on the client?

Not the most intuitive thing, puppet apply -t -d --apply mytest.yaml. Most likely will get expired catalog, but that can either be updated by changing expire datetime in the catalog, or controlling expiration using --runinterval (it's overloading the same option for two purpose).

 Эта команда не работает в версии puppet-4.8.2-alt1 (неизвестная опция).

• puppet catalog apply --terminus yaml -- man по puppet catalog:

...the source of the catalog can be managed with the --terminus option.

 При запуске этой команды возникает ошибка (версия puppet-4.8.2-alt1) после и одного, и другого варианта команды скачивания (модифицированный puppet agent --noop или puppet catalog download):

Error: no implicit conversion of nil into Array
Error: Try 'puppet help catalog apply' for usage

• puppet agent --onetime --no-daemonize --use_cached_catalog -- найдено в исходном коде.

 Действует после одного варианта команды скачивания (модифицированный puppet agent --noop).

переводя ресурсы в ALTовые (через distromap)

Варианты реализации (просьба отмечать реализованные):

• переписываем каталог "извне"

 Были попытки, но требуется возня с форматами: yaml, json, etc.

• ещё один провайдер для типа package, какой-нибудь, myaptrpm.rb

 Есть работающий прототип, но без специальной опции: выбор myaptrpm.rb hardcoded.

• фабрика package.rb делает обёртку вокруг выбранного по обычным правилам провайдера для типа package.

Проверка требуемых модулем или манифестом ресурсов в Sisyphus

Способы перечислить/напечатать (CERTNAME, HOST обозначают нашу ноду):

• puppet catalog find CERTNAME -- напечатать
• puppet catalog select [--terminus TERMINUS] HOST '*' -- все типы

Способы проверить наличие в Sisyphus: пакеты -- очевидно как; остальное -- не очень. Переводить в Requires в стиле поиска автозавимостей может быть не самым практичным способом. Возможно, стоит ставить требуемые пакеты в hasher, передавать туда каталог, а потом проверять, т.е. выполнять в каком-то упрощённом режиме.

Тестирование puppet --distromap

Для начала тестирования планируется:

• бэкпортировать наши новые фичи на puppet3 тоже;
• сделать distromap для одного из последних релизов RHEL;
• начать тестирование с реальными манифестами (и модулями), заточенными под один из последних релизов RHEL.

По мере продвижения реализовывать distromap для других ресурсов помимо package (например, service, file и пр.).

См. также

• Puppet unit testing like a pro -- про тестирование, может быть, полезно для проверки соотвтетствия модулей и манифестов репозиторию Sisyphus
• Static catalogs -- будет нужно для тестирования в hasher-е (в особых случаях, когда скачиваются дополнительные файлы помимо каталога)