[Devel-conf] Metalterator

Вс Апр 12 17:06:33 MSD 2009

Бывают такие конфиги которые парсить практически бесполезно. Например dhcp.

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

Аналогичные проблемы у средств работы с iptables.

Оповещать пользователей о "тронутых" конфигах хорошая идея, давайте
что-нибудь сделаем на эту тему ... но кроме хранения для этого где-то в
отдельном месте md5sum ничего не приходит в голову ибо пользователь может
поправить очень незаметно, но достаточно для поломки интерфейса. Давайте эту
проблему обсудим в отдельном треде.

Ну а насчёт Т-500 и недостойного для него alterator мы не сговорились прежде
всего не в стратегиях развития, а примерно в том же в чём не сговорились
сейчас в Сизифе с rpm5 и co.

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

Ну а стратегия ... да, мне надо постоянно поддерживать и развивать нынешнюю
версию, но я многократно рассказывал и показывал, что я переписывал целые
куски заново а потом аккуратно перетаскивал туда накопившийся багаж. Не
верят ...

11 апреля 2009 г. 14:20 пользователь Michael Shigorin <mike на osdn.org.ua>написал:

> 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 на .
>
> Я могу только заметить, что перегенерация файла с довольно
> нетривиальным, обширным и _не_ покрываемым никакой настраивалкой
> с обозримым интерфейсом синтаксисом -- это плохая идея, хотя так
> писать настраивалку проще, конечно.
>
> Причём это принципиальная разница языка и книжки-раскраски:
> нетривиальные проекты склонны реализовывать именно _язык_
> конфигурации, а самая лучшая настраивалка ничем не отличается
> от сколь угодно удобной в использовании, направляющей, упреждающе
> подсказывающей, но неизбежно ограниченной стопки шаблонов.
>
> При этом в жизни мы пользуемся языком, а не счётными палочками.
> Потому как задачи сложнее.  Но начинали -- со счётных палочек.
> Так и тут: хорошая настраивалка должна быть под рукой, когда
> задача новая или редкая и при этом типичная; замечательная
> настраивалка позволит отойти от её использования и не цепляться.
> А для этого -- не будет держать под страхом того, что конфиг ни
> на йоту нельзя трогать мимо неё.
>
> > Тогда я стал думать: какую БД мне выбрать? Ясно что самую
> > простую, поскольку данных, которыми может управлять
> > пользователь в пределах одного модуля, скорее всего, немного.
> > Поэтому критерием поиска БД стало удобство отображения в неё
> > объектов Альтератора. И вот тут я понял, что неплохим
> > хранилищем для этих объектов будет обычная файловая система! На
> > что 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 на altlinux.ru>
>  ------ Linux.Kiev http://www.linux.kiev.ua/
> _______________________________________________
> devel-conf mailing list
> devel-conf на lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel-conf
>
----------- следующая часть -----------
Вложение в формате HTML было удалено...
URL: <http://lists.altlinux.org/pipermail/devel-conf/attachments/20090412/4b5d70b6/attachment-0001.html>