[Devel-conf] Metalterator

[Michael Shigorin]

On Thu, Apr 09, 2009 at 04:07:57PM +0400, Pavel Wolneykien wrote:
> > >> metalterator - Alterator meta-backend with additional Guile modules
> > > Расскажете подробнее?  На http://www.altlinux.org/Alterator
> > > и в окрестностях ничего не нашёл, а интересно.
> Это радует, что интересно. ;)

Погодите радоваться, вон у Стаса можете спросить,
во что такой интерес порой выливается :)

А это письмо бы всё равно хорошо на вики в качестве описания.

> Значит дело было так. Собрался я писать модуль для Squid (во
> второй раз, но это отдельная история). После разговора с wart@
> и ldv@ мне стало совершенно понятно, что для работы с
> относительно сложным конфигурационным файлом нужна БД: ни
> читать, ни писать отдельные значения в файл нельзя -- всё
> перепутается. Зато сгенерировать такой файл целиком задача на
> порядок проще.

Возможно, wart@ и ldv@ не настраивают squid в повседневной
деятельности -- перед изменением, которое по сути представляет
из себя воспроизведение через много-много лет одной из худших
черт SuSE YaST -- "конфиг руками не трогать", стоит советоваться
не в закрытом режиме (как нам пеняли вот), а с теми, кому с этим
жить.  Т.е. в sysadmins@ и с support at .

Я могу только заметить, что перегенерация файла с довольно
нетривиальным, обширным и _не_ покрываемым никакой настраивалкой
с обозримым интерфейсом синтаксисом -- это плохая идея, хотя так
писать настраивалку проще, конечно.

Причём это принципиальная разница языка и книжки-раскраски:
нетривиальные проекты склонны реализовывать именно _язык_
конфигурации, а самая лучшая настраивалка ничем не отличается
от сколь угодно удобной в использовании, направляющей, упреждающе
подсказывающей, но неизбежно ограниченной стопки шаблонов.

При этом в жизни мы пользуемся языком, а не счётными палочками.
Потому как задачи сложнее.  Но начинали -- со счётных палочек.
Так и тут: хорошая настраивалка должна быть под рукой, когда
задача новая или редкая и при этом типичная; замечательная
настраивалка позволит отойти от её использования и не цепляться.
А для этого -- не будет держать под страхом того, что конфиг ни
на йоту нельзя трогать мимо неё.

> Тогда я стал думать: какую БД мне выбрать? Ясно что самую
> простую, поскольку данных, которыми может управлять
> пользователь в пределах одного модуля, скорее всего, немного.
> Поэтому критерием поиска БД стало удобство отображения в неё
> объектов Альтератора. И вот тут я понял, что неплохим
> хранилищем для этих объектов будет обычная файловая система! На
> что inger@ сказал: "ФС -- это одна из самых клёвых встроенных
> БД!".

Интересно, а не вспоминал ли он при этом один из предложенных
нами в своё время фрагментов насчёт "распределённой базы
состояния и правил"?

Понятно, что всему своё время, но уж если добрались до желания
базы и решили засунуть её просто на ФС (которая является ещё и
_иерархической_ базой, если уж на то пошло, а не реляционной;
это важно) -- то мне немного страшно представлять себе, как потом
будет решаться задача расшаривания этой самой базы для настройки
стайки тех же squid'ов по региональным отделениям заказчика.

> Таким образом, вместо библиотеки я решил написать отдельный
> бакенд, который бы отображал woo-команды на файловую систему.

Шеллы наши бЫстры, но всё-таки плохо подходят для насыщенных
слоёв абстракции.  В код не смотрел (c), но возможно,
сериализовать сразу структуры данных и бросать их целиком через
native backend было бы несколько меньшим ударом по скорости.
Если уж идти таким путём.

> Если была дана команда прочесть атрибут, который не задан в
> объекте, то будет явно возвращено значение #f.

Ммм... а с существующими булевыми должны долетать тоже уже #t/#f
или ещё yes/no?  Может возникнуть ситуация "неразборчиво".

Ещё пока опять вспомнил на ту же тему: в процессе написания
alterator-ltsconf встал вопрос о понятии дефолта или дефолтности
значения параметра -- там по логике работы удобно иметь
возможность регулировать общие для всех тонких клиентов параметры
или указывать для конкретных частные (при этом не засоряем UI
копиями общего значения и можно отличить, на что именно повлияет
изменение дефолтов).

Это один из шажков к управлению неединичными системами, и в его
процессе оказалось, что в альтераторе для такого сейчас нет ничего.
См. http://tinyurl.com/ltsconf-defaultness и ниже, что пришлось
накостылять в качестве частного "решения".

> Да, совсем забыл: полное имя объекта, т.е. всё, что идёт после /meta
> интерпретируется как путь месту в ФС! К примеру,
>   alterator-cmdline /meta/etc/metalterator/squid/squid "write" http_port "3128"
> обновит значение http_port в файле /etc/metalterator/squid/squid.scm.

Не следует писать в /etc по каждому чиху, для этого есть /var
и прочие $TMP.  Внезапное выключение питания или кернел паник
в самый неподходящий момент -- эффективный учитель :(

> В настоящее время единственным пользователем метабакенда
> является бакенд squid из пакета alterator-squid-1.0-alt1.
> Кстати сказать: конфигурацию по умолчанию этот пакет несёт с
> собой в виде набора файлов, которые он кладёт как есть прямо в
> /etc/metalterator/squid. По моему это тоже очень удобно!

Кому и чем?

Сисадмину удобен (потому как привычен) /etc/squid/squid.conf,
который можно править $EDITOR.

Разработчику модулей (вот мне) -- видится тупиковой идея генерата.

Ну и честно говоря, пока не вижу никакого особенного мета- в ещё
одном бэкенде -- то, что уже давно было продумано и сделано,
гораздо более метаинструмент, и притом его всё равно есть куда
и надо обобщать.  О чём мы, собсно, и говорили.

Можно сказать "ну так и сделай, раз такой умный", и это будет
правильно; собственно, за прошлый год мы попытались совместить
свои планы по разработке системы управления множеством
компьютеров с Alterator, но по разным причинам это благополучно
затухло.  Поскольку прикладной задачей сейчас здесь является
мониторинг и управление кластером размером с Т-500, то понятно,
что распределённость и масштабируемость приходится закладывать
сразу, а не оставлять на "когда-нибудь"; при этом анализ текущего
Alterator показал, что проще взять хорошие изначальные идеи и
переписать начисто, чем пытаться эволюционировать -- вот в этом
со Стасом возникло различие мнений.

Надо будет поинтересоваться текущим статусом разработки и есть ли
уже что полезного и публикуемого, но мож хоть Вам пригодится
(хотя честно говоря -- не уверен).  Если хотите, могу покопать
переписку и пофорвардить обсуждение.  (или даже лучше сюда?..)

-- 
 ---- WBR, Michael Shigorin <mike at altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/