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

но, как говориться, на вкус и цвет

+

Это как с ансиблом - неча shell/command юзать

С другой стороны - а зачем это превращать в язык программирования. Какая выгода ?

а тут нет баланса) многие вещи надо под себя адаптировать

Выше там человек про паппет высказывался. И я с ним, к сожалению, согласен, что объектная модель у него лучше. С другой стороны, она требует больше сил для поддержки.
Как по мне - идеальный scm должен быть по аналогии с терраформом

Хотя кубер и иммутабельная инфра все заборют

терраформ, да, штука крутая

который год борют и все незаборют. Серебрянной пули нет.

С тем же тераформом ветер дует в Terafform SDK и Pulumi.
Кажется мы прошли полный цикл от императивки до декларативки и снова до императивки

Pulumi даже не слышал о таком

Странно что никто еще с Serverless в чат не ворвался

у меня в закладках открыто, но даже не вниказ что это

да

Всем привет! Есть какой-то способ подавить вывод Changes при выполнении state.apply, и выполнять этот этап без уведомления что что-то изменилось? Объясню зачем - есть systemd-юнит, который oneshot, то есть всегда в статусе inactive и когда солтстек его будет проверять, то он всегда будет выполняться, несмотря даже на то, что он работает. И это отвлекает, приходится постоянно проверять что поменялось. Хочется как-то это скрыть

state_verbose
state_output
state_output_diff

Спасибо, я правильно понимаю что это можно для одного стейта ограничить вывод?

А, кажется нет, state_output это только на старт saltstack из командной строки? В стейт нельзя это добавить?

Может быть есть какой-то аналог changed_when в ансибле для Saltstack?

onlyif и добавить туда команду на проверку надо ли сервис запускать