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@ и с supp...@. Я могу только заметить, что перегенерация файла с довольно нетривиальным, обширным и _не_ покрываемым никакой настраивалкой с обозримым интерфейсом синтаксисом -- это плохая идея, хотя так писать настраивалку проще, конечно. Причём это принципиальная разница языка и книжки-раскраски: нетривиальные проекты склонны реализовывать именно _язык_ конфигурации, а самая лучшая настраивалка ничем не отличается от сколь угодно удобной в использовании, направляющей, упреждающе подсказывающей, но неизбежно ограниченной стопки шаблонов. При этом в жизни мы пользуемся языком, а не счётными палочками. Потому как задачи сложнее. Но начинали -- со счётных палочек. Так и тут: хорошая настраивалка должна быть под рукой, когда задача новая или редкая и при этом типичная; замечательная настраивалка позволит отойти от её использования и не цепляться. А для этого -- не будет держать под страхом того, что конфиг ни на йоту нельзя трогать мимо неё. > Тогда я стал думать: какую БД мне выбрать? Ясно что самую > простую, поскольку данных, которыми может управлять > пользователь в пределах одного модуля, скорее всего, немного. > Поэтому критерием поиска БД стало удобство отображения в неё > объектов Альтератора. И вот тут я понял, что неплохим > хранилищем для этих объектов будет обычная файловая система! На > что 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 <m...@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
