Release 0.4.4 (2017-02-28)¶
Getting usage help with usage
¶
Утилита командной строки доработана, чтобы быть более дружелюбной к пользователю.
Вызов утилиты ram
без параметров теперь выдает краткую справку по самым необходимым командам.
Команда ram usage
позволяет получить краткую справку по использованию той или иной команды:
# ram usage setup
setup: use unit to configure environment
To use unit:
$ ram setup <namepath>
На странице Quick Start добавлены примеры использования этих команд.
Calling ram
commands from python¶
В новой версии фреймворка появилась возможность вызывать команды ram
из питоновского кода.
При этом сделан упор на идентичность семантики вызовов, например следующая команда shell:
# ram setup ifconfig device=eth0
идентична следующему коду на python:
>>> import ram
>>> ram.setup('ifconfig', 'device=eth0')
или:
>>> import ram
>>> ram('setup', 'ifconfig', 'device=eth0')
Для реализации этой функциональности в ram
реализована модель сервисов.
Более подробно об этом на странице Services.
Low level python interface to ram
¶
Упомянутый в предыдущей секции python-интерфейс для фреймворка ram
является высокоуровневым.
Возвращаемые им объекты зависят от конкретного вызываемого сервиса.
Примерами возвращаемых объектов могут быть простые коллекции (списки, словари) или Watch-объекты.
Кроме этого, в новом фреймворке реализован низкоуровневый python-интерфейс. Этот интерфейс предназначен для написания оберток к интерфейсу фреймворка, таких как утилита командной строки.
Более подробно об этом на странице Services.
Libraries interaction: merging¶
В предыдущих версиях фреймворка была реализована концепция тегированных скриптов в составе конфигурационного юнита.
Например, конфигурационный юнит hostname
может включать скрипт apply
для применения настроек в общем случае и
скрипт apply.collectd
для применения настроек в демоне collectd.
Т.к. демон collectd не является стандартной частью системы, скрипт для этого демона не включен в стандартную библиотеку.
Однако фреймворк предоставляет средства для расширения и взаимодействия библиотек поставляемых в разных пакетах.
Фактически файлы в составе одноименных юнитов из разных библиотек объединяются в один виртуальный юнит.
Т.о. для расширения стандартного юнита hostname необходимо создать отдельную библиотеку и
создать в ней юнит hostname
включив в него только один файл - apply.collectd
.
Для просмотра списка файлов в составе виртуального юнита реализована команда ram which
:
# ram which hostname apply*
/usr/lib/ram/hostname/apply
/opt/my-appliance/lib/ram/hostname/apply.collectd
# ram tweak trace on
# ram apply hostname
: /usr/lib/ram/hostname/apply = 0
: /opt/my-appliance/lib/ram/hostname/apply.collectd = 0
На данный момент в фреймворке не реализовано какого-либо гарантированного разрешения конфликтов для файлов с одинаковым именем.
Более подробно о команде which.
P.S.: в предыдущих версиях фреймворка была реализована экспериментальная версия этой функциональности на основе кэша. Кэш представлял собой временную файловую иерархию для объединения порций юнита из различных библиотек. В новой версии разрешение путей происходит динамически и необходимости во временном кэше больше нет.
Команда ram cache
в этой версии оставлена для совместимости.
Libraries interaction: probing¶
Иногда может возникнуть необходимость использовать библиотеку юнитов изначально расчитанную на применение в иной конфигурации.
Например, юнит конфигурации прокси (proxywiz
) изначально разработан для конфигурации двух различных демонов – daemos
и phobos
.
При этом daemos
конфигурируется основными скриптами юнита, а phobos
тегированными.
При необходимости переиспользовать этот юнит в системе без daemos
фреймворк будет генерировать ошибки и
не позволит сконфигурировать присутствующий в системе phobos
. Для решения этой проблемы реализован механизм пробинга.
С точки зрения разработчика интерфейс механизма заключается в добавлении соответствующего файла probe
или probe.<daemon>
.
Файл должен быть исполняемым. В его задачи входит определение наличия того или иного демона в системе.
В случае если, скрипт присутствует и в результате его выполнения получен ненулевой код ошибки,
последующее выполнение скриптов query.<daemon>
, store.<daemon>
и apply.<daemon>
не производится.
Даже если в оригинальной поставке юнита не был реализован соответствующий скрипт probe
,
его можно реализовать в библиотеке-расширении используя механизмы описанные в предыдущем разделе.
Более подробно о команде probe.
Namespaces¶
Разрастание кодовой базы конфигурационных юнитов ведет к необходимости структурной организации библиотек. С этой целью в этой версии фреймворка в экспериментальном режиме реализована поддержка иерархичных пространств имен.
Располагая юниты в иерархии директорий можно обращаться к ним по иерархическому пути, например:
# ram setup subsys1.component2.subcomponent
Более подробно об этом на странице Namespaces.