LINUX.ORG.RU
ФорумTalks

Почему серверное и десктопное ПО до сих пор повсеместно не использует XML-конфиги (или удаленное хранилище конфигов)? Где M2M API?

 , , , ,


0

2

P.S. Для тех, кто не осилит: суть треда в проблемах использования ПО автогенерации конфигов и оркестрирования в современном мире.

Воу-воу, полегче, ЛОР!

Посмотрел я на AIX, продукты Red Hat, яву, на кеды, на systemd, продукты Mozilla и у меня случился Батрудинов (я бы даже сказал хороший французский багет)! Точнее багет случился, когда я начал писать рецепты для ПО в puppet.

Почему всё ПО не использует нормальные, документированные и понятные конфиги, как у этого ПО? Почему не использовать внешнее (удаленное) хранилище конфигов или XML-конфиги?

Тот же firefox имеет хранилище конфигурационных опций с описанием (по которым, кстати, ещё и онлайн-справка расширенная доступна).
AIX вообще использует кошерное внешнее хранилище (увы, не для всего) конфигов. И умеет к нему удобный псевдогуй, и консольный доступ.
Systemd позволяет удобно описать юниты самой разной направленности. И работать всё это будет гарантированно и стабильно. Не то что скрипты инициализации, которые вообще не понятно, отработают или нет.
Почти все серверные продукты RedHat управляются через XML-конфиги и БД.
Большинство ПО под яву юзает читабельные XML-конфиги с комментами.

А что мы видим обычно?
Apache2: конфиги вообще не документированы, код имеет очень хитрую обработку конфигов (в которых одно и то же можно сделать десятью методами). Даже обработка случая, когда запрашивается несуществующий (дефолтный) домен, может быть задана минимум 3-мя способами (причём ни один из них не является явным).
Nginx: уже лучше, что всё-равно кофиги не очень: их уже можно нормально генерировать, но вот считать их и распарсить уже не выйдет.
Asterisk: это ПО просто эталонный пример недокументрованных забагованных функций, странного поведения, взаимозаменяющих и устаревших опций, непонятных дефолтных настроек. После перехода на FreeSwitch с XML-конфигами и JS-скриптами я перестал просыпаться ночью в холодном поту и дозваниваться на IVR.
БД (любые почти: mysql, postgresql, postgresql XL, firebird). Такое ощущение, что конфиги проектировались для БД на 10 запросов в секунду, которая работает максимум с тремя клиентами, но никак не для кластеров. Кластерные конфигурации вообще очень странные: многое нельзя сделать на лету, настройки хранятся как в конфигах (INI-подобных), так и в системных таблицах. Это очень неудобно, особенно в облачном случае, когда БД надо масштабировать на лету, либо обеспечивать HA.
У postgresql настройка вообще совсем не простая: из-за отсутсвтвия движка интеллектуального вакууминга (как у оракла) его надо настраивать вручную под каждую конфигурацию, причём очень хорошо понимать особенности текущий конфигурации. Также постгрес имеет исторически большой набор ПО, которое расширяет возможности БД, работая, как глобальные встроенные функции и триггеры. Они как хотят, так и хранят свои настройки.
DE. Ну тут всё просто: твоё приложение - твои правила! Конфигами рулить очень сложно.
Оборудование. IPMI нормально работает только через питоновые либы, которые определяют конкретный сервер и конкретную реализацию IPMI. Логи тоже не стандартизированы. Из настройки в автоматическом режиме доступен только порядок загрузки. Для всего остального надо заходить руками в EFI/BIOS. Часто даже утилит для бекапа и развёртки на другие сервера этих конфигов биоса нет.


Конфигурационные файлы многих СПО приложений напоминают perl-код с регекспами: обычно даже разработчик не может точно сказать, как это работает.
Про кривую автоматизацию генерации таких конфигов я вообще молчу: один спецсимвол в рецепте puppet и сервис ляжет.

На тему людей, которые хотят человекочитаемые конфиги, а не нормальный интерфейс machine2machine, у меня родилась зарисовка:
http://www.youtube.com/watch?v=f6dGb2I8iB0
Почему, мистер Андерсон? Почему? Во имя чего? Что Вы делаете? Зачем, зачем пишете велосипеды? Зачем продолжаете костылить? Нужели Вы верите в какой-нибудь KISS, или Вам просто страшно слиться? Так в чём же приемущества plain-конфигов, может откроете? Это свобода? Минималистичность? Может быть чистота, или Вы боретесь за читабельность? Иллюзия, мистер Андерсон, причуды кодинга. Хрупкие логические теории слабого программиста, который отчаянно пытается оправдать существование устаревших форматов, безсхемных и бессмысленных. Но они, мистер Андерсон, как и языки с прямым доступом к памяти, столь же искусственны. Только человек может придумать скучное и безжизненное понятие «читабельность». Вам пора это увидеть, мистер Андерсон, увидеть и понять: Вы не можете победить XML, продолжать борьбу с энтерпрайзом бессмысленно. Почему, почему, мистер Андерсон, почему Вы упорствуете?

Перемещено leave из general

☆☆☆

Последнее исправление: ktulhu666 (всего исправлений: 5)

Сейчас набегут местные эксперты и скажут, что XML не нужен. А потом набегут ещё раз и добавят про systemd =).

Deleted
()

Точнее багет случится, когда я начал писать рецепты для ПО в puppet.

Кстати, я в аналогичной ситуации (правда с salt вместо puppet) решил, что вместо «изменим пару строк/значений в конфиге» гораздо лучше работает тактика «генерим конфиг с нуля, а всё, что было раньше - нафиг». В salt для генерации текста можно использовать jinja2, а для более сложных случаев - писать генератор прямо на питоне. Но не всегда такое возможно, к сожалению.

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)

Если софт не сложный, то XML-конфиг будет напоминать Hello world с использованием всех принципов ООП. То есть огромным нагромождением служебных конструкций вокруг минимума полезных данных.

ИМХО, идеальный бы вариантом было бы использование JSON, но почему-то его очень мало кто использует, хотя он гораздо читабельнее.

KivApple ★★★★★
()

А, это ты.

anonymous
()

Почему все ПО не работает без глюков и не развивается без регрессий?

XML

Фу. Либо JSON, либо YAML.

Почему не использовать внешнее (удаленное) хранилище конфигов?

Используй.

thesis ★★★★★
()
Ответ на: комментарий от sergej

Нифига: конфиги должно генерироваться ПО оркестрации на основе декларативных политик доступности, безопасности и связей ПО.

ktulhu666 ☆☆☆
() автор топика
Ответ на: комментарий от thesis

Почему все ПО не работает без глюков и не развивается без регрессий?

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

Фу. Либо JSON, либо YAML.

Фу. JSON не реально читать, а тем более править. Или Вы про два уровня вложений и конфиг в один экран? Я про конфиги в тысячи строк.

Используй.

Не дают же!

ktulhu666 ☆☆☆
() автор топика
Ответ на: комментарий от ktulhu666

Я про конфиги в тысячи строк.

Миллионы, чувак. В нормальном конфиг-файле - миллионы строк.

Не дают же!

А мне дают.

thesis ★★★★★
()

Потому что разработчики недальнозоркие. Они же не думают сначала, что их проект будет развиваться, что им люди пользоваться будут.
Есть несколько опций для конфига — и key=value в plain text сойдёт. Хреначат. Когда уже приложение стоит на тысячах серверов добавляют функционал, появляются новые опции, появляется нужда в структурах более сложных. Менять то ничего нельзя, ибо совместимость нужна, вот и продолжают хреначить туда всякие костыли.
А документация не нужна, потому что open-source, для себя пишут. Кто не понял пусть в исходники зырит )))

По поводу XML — это древнее, нечитаемое и громоздкое говно. Комментирование в нём через жопу, редактировать неудобно. Я этой дряни в Android уже натерпелся.
Все кто используют его — в Аду гореть будут.
Лучший формат для конфига это TOML

I60R ★★
()
Ответ на: комментарий от ktulhu666

Как ты себе представляешь работу на десктопе или типичном одиночном сервере?

Поставить ПО оркестрации на локалхост ради оркестирования локалхостом?

Chaser_Andrey ★★★★★
()
Ответ на: комментарий от ktulhu666

конфиги должно генерироваться ПО оркестрации на основе декларативных политик доступности, безопасности и связей ПО.

А кем должны генерироваться декларативные политики?

staseg ★★★★★
()
Ответ на: комментарий от Chaser_Andrey

Нет, в качестве универсального формата он никак не годится.
Потому что это очень узкоспециализированый формат — удобен только для написания легковесных програм на Си.
Поэтому статистика такая:
libcofuse — 263 коммита с 2003-го года. Ни одного вменяемого парсера для других языков не нагуглил.
toml — 389 коммитов с 2013-го года. Есть парсеры для всех языков по которым гуглил.

I60R ★★
()

XML-конфиги

Забанься, идиот.

Deleted
()

Читабельные конфиги?!

Задача конфига сопоставлять название параметров и значения. Вот представь, что у тебя задача написать хмл конфиг с нуля, что ты будешь делать без документашки, ни названий опций, ни значений ни, влияние на поведение софта тебе не известны?

Т.е. для того чтоб написать конфиг нужно понимать что ты пишешь. А в этом случае хмл например годится только если у тебя есть софтина которая помогает этот хмл писать, да ещё и парсер в самом приложении должен быть.

ya-betmen ★★★★★
()
Ответ на: комментарий от anonymous

Мечты о бинарном реестре как у винды?

Как у AIX. Реестр винды не юзабелен ни в каком виде.

ktulhu666 ☆☆☆
() автор топика
Ответ на: комментарий от Chaser_Andrey

Как ты себе представляешь работу на десктопе или типичном одиночном сервере?

Ну это у Вас типичное. А у меня нужно кучей машин управлять.
И да: в чём проблема ручного редактирования XML-конфигов? Есть куча редакторов, которые делают это с подсветкой, автоформатированием, свёрткой узлов дерева и картой дерева. Ну проверка валидности по ходу редактирования. Это усложняет выстрел в ногу.

ktulhu666 ☆☆☆
() автор топика
Ответ на: комментарий от Chaser_Andrey

Лучший формат для конфига - это libconfuse

Мертворожденный труп.

ktulhu666 ☆☆☆
() автор топика
Ответ на: комментарий от thesis

Миллионы, чувак. В нормальном конфиг-файле - миллионы строк.

Так тем более: назовите хоть один JSON-редактор, который за Вас думает, а не тупо текст предоставляет.

ktulhu666 ☆☆☆
() автор топика
Ответ на: комментарий от Chaser_Andrey

Лучший формат для конфига - это libconfuse

Обоснуйте.

ktulhu666 ☆☆☆
() автор топика
Ответ на: комментарий от I60R

Потому что разработчики недальнозоркие. Они же не думают сначала, что их проект будет развиваться, что им люди пользоваться будут.

Вот именно! А потом начинаются непонятные конфиги и проблемы их автогенерации у админов. Сразу бы XML юзали.

Есть несколько опций для конфига — и key=value в plain text сойдёт. Хреначат.

Если несколько опций, то пусть сразу юзают XML: если несколько опций, а какая разница то? Пусть сразу админам и машинами будет удобно.

А документация не нужна, потому что open-source, для себя пишут. Кто не понял пусть в исходники зырит )))

Лол. Да там такие исходники, что сам автор хрен разберется. Часто даже без комментов.

По поводу XML — это древнее, нечитаемое и громоздкое говно. Комментирование в нём через жопу, редактировать неудобно.

Обоснуйте. Может Вы не знаете про XML-редакторы, постоение визуального дерева узлов, блобы и валидацию? Вы, что, в nano XML правите? Вы в своём уме?

Лучший формат для конфига это TOML

Да говнище же: ни блобок, ни экранирования, ни валидации. Больше двух уровней вложенности и читать невозможно.

ktulhu666 ☆☆☆
() автор топика
Ответ на: комментарий от ktulhu666

должно генерироваться ПО оркестрации

если бы было должно, то непременно бы генерировалось

sergej ★★★★★
()

Почему всё ПО не использует нормальные, документированные и понятные конфиги, как у этого ПО?

Наивный чукотский вьюнош, линуксовое/никсовое ПО писалось кучей разных людей в разное время в разных условиях. Поэтому приходится работать с различными форматами конфигурации: кто-то решил, что ему XML удобнее, кому-то JSON полюбился, кто-то по привычке INI использует, кто-то свой plaintext пишет, и т.д., и т.п.

Да ладно форматы - с расположением конфигов до сих пор разобраться не могут! Речь, конечно, больше о расположении конфигов в домашних директориях юзеров (~/.appname/ или ~/.appnamerc или ~/.config/appname/), в /etc, как правило, либо один конфиг в /etc, либо одна директория в /etc.

А суть такова: когда софт пишут разные независимые люди (много разных людей), им нужен очень хороший аргумент, чтобы о чём-либо договориться, в том числе о том, в каком формате хранить конфиги. А так как такого аргумента не находится, каждый дро^W хранит, как хочет, deal with it. Если шибко надо - это опенсурс, возьми да перепиши этот софт, чтобы он делал то, что тебе надо.

tiandrey ★★★★★
()

Ну хоть в этот раз хорошо и тонко вбросил, молодец, хвалю.

cherry-pick
()
Ответ на: комментарий от ktulhu666

Фу. JSON не реально читать, а тем более править.

XML

А я уже было подумал, что на лоре завёлся разумный человек.

anonymous
()
Ответ на: комментарий от ktulhu666

Только полный идиот будет использовать хымыль в конфигах! Ну или даун...

Eddy_Em ☆☆☆☆☆
()

Про нужность конфигурационных файлов программ в принципе ещёникто не написал?

P.S. Это ведь talks?

qnikst ★★★★★
()
Последнее исправление: qnikst (всего исправлений: 1)
Ответ на: комментарий от Harald

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

anonymous
()

В своем ПО конфиги храню в INI. Самый большой конфиг, что я делал ~5k строк. Максимальный уровень вложенности ~6-8, точно хз. Все настройки можно править через гуй. Иногда нужно изменить такой конфиг по определенному правилу на объекте - фигачу его регэкспами в portable версии нормального текстового редактора.

А для этих твоих хэмээлей можно что-то типа регекспов применить? Нет? ну тогда xml для конфигов я вертел на ОСи своей.

Для некоторых объектов количество конфигов достигает 10, объекты разнесены, не везде открыт удаленный доступ. Подумываю над сервером конфигов (АЗАЗА!). Пока выкручиваюсь через велосипед обновлений. В любом случае xml мне на... не нужен.

Если тебе так нужно централизованное управление - будь мужиком запили скрипты на perl/python/js/whatever, а не ной на ЛОРе. И да, если так хочешь - можешь использовать xml для конфигурирования своих костылей и связи между ними и, возможно, гуй-клиентом на той же скриптоте. Ну ты понел...

anonymous
()

Ничего, скоро халява закончится! Для получения сертификата совместимости с SystemD каждая программа обязана будет хранить настройки в бинарном реестре.

Deleted
()

1. Парсить конфиги не нужно, их нужно генерировать

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

annulen ★★★★★
()
Последнее исправление: annulen (всего исправлений: 1)

Почему, мистер Андерсон? Почему?

Потому что, допустим, XFCE хранит конфиги в XML. И, допустим, захочешь ты их поправить посредством Salt Stack. Всего за час ты поймешь, что без augeas никак, начнеш писать дикую простыню, поймешь, что она не работает, начнешь копаться, найдешь на гитхабе нужный баг и проклянешь весь этот XML и уверуешь в plain-конфиги.

t184256 ★★★★★
()
Ответ на: комментарий от Harald

А это уже неважно и к программе не относится.

qnikst ★★★★★
()
Ответ на: комментарий от ktulhu666

Оба формата, XML и JSON, в данном случае — говно. Они не позволяют нулевой уровень вложенности, разметка занимает больше места чем данные, поощряют использование вложенности что в результате выливается в десятиэтажные структуры, а ещё можно убрать все переносы строки и пробелы и будет валидный XML\JSON.
Использовать вот такое, это и себя и людей, которые будут пользоваться твоим ПО не уважать.
Есть же TOML, специально для конфигов созданный — используй.
Нет, не хочу, хочу форматом созданным для сериализации\репрезентации обьектов в жабаскрипте обмазаться.
Куда этот мир катится...

I60R ★★
()
Ответ на: комментарий от ktulhu666

Я не совсем понимаю: Вы не осилили XML-редактор и редактируете XML вручную?!

На кой ляд использовать текстовый формат, если его нельзя редактировать вручную и к нему нужен ещё какой-то дурной редактор?!

Можно же хороший годный бинарник, который будет парситься на порядки быстрее и весить меньше и валидироваться проще.

anonymous
()
Ответ на: комментарий от ktulhu666

Столько кастов, насколько я знаю, не проходят.

Я за XML всё таки, если приложение очень сложное и предполагает обработку множества данных. Если в конфиг нужно загнать пару строк, то Ini/TOML. JSON неплохой вариант, когда приложение на JavaScript.

EXL ★★★★★
()
Ответ на: комментарий от EXL

Столько кастов, насколько я знаю, не проходят.

Проходят. Тут спамеры и 30 человек в одном после кастуют.

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

ktulhu666 ☆☆☆
() автор топика
Ответ на: комментарий от ktulhu666

Мне ничего не пришло. Я даже удивился, когда обнаружил себя в этом списке.

А почему не использовать XML даже в случае двух строк?

Потому что пушкой по воробьям.

а работать с ним можно из любого языка.

В JavaScript из коробки, только JSON, вроде как.

EXL ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.