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.

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

Гипотетические варианты реализации (просьба отмечать как неудачные или работающие и почему):

• 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 catalog apply --terminus yaml -- man по puppet catalog:

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

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

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

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

• переписываем каталог "извне";
• ещё один провайдер для типа package, какой-нибудь, myaptrpm.rb;
• фабрика package.rb делает обёртку вокруг выбранного по обычным правилам провайдера для типа package.

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

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

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

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

См. также

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