openlang

Смена языка конфигурации не лечит дрейф

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

HCL это синтаксис структурированной конфигурации. Блоки, атрибуты, выражения и JSON-форма, которая ложится на ту же структуру. Что значит блок, решает инструмент, который его читает. Файл описывает, чего вы хотите. Дрейф это реальный ресурс, изменившийся за спиной у файла. Диск, увеличенный вручную в веб-консоли, тег, поправленный скриптом, о котором никто не помнит. Программа на Python, выдающая то же желаемое состояние, дрейфует точно так же.

Язык общего назначения меняет другое, а именно сколько рецензенту приходится исполнять в голове. С простыми блоками я читаю diff и вижу, какой ресурс сдвинется. С циклом по словарю, собранному вспомогательной функцией, его сначала нужно запустить.

Для файлов, которые в основном перечисляют ресурсы, оставьте скучный синтаксис и потратьте силы на поиск дрейфа. Регулярный запуск plan, который громко падает, когда реальность и файл расходятся, даёт больше любого переписывания.

Разговор продолжается 4

Следуя доводам
  1. Ссылка на ответ

    Не убеждён. Что дрейф не вина языка, до этого места согласен. Но файлы HCL всё равно отращивают язык программирования. Выражения for, условия, функции, модули, вызывающие модули. В итоге пишешь настоящую логику, только инструментов, чтобы пройти её по шагам или проверить кусок отдельно, куда меньше.

    Тогда уж лучше настоящий язык и правило, что программа остаётся тупой. На входе плоские данные, на выходе список ресурсов, никакой хитрости между ними.

  2. Ссылка на ответ

    Проверка plan громко падает, только если может упасть политика, которая его читает. Правило, в теле которого проверяется input.resource.encrypted == false, при отсутствии поля даёт undefined, ничего не порождает, и ресурс проходит. Уберите это поле. Что вернёт запрос? Подайте на вход и отсутствующий атрибут, и явное false, потому что отклонён будет только один из них.

  3. Ссылка на ответ

    Настоящий язык действительно даёт типы в редакторе, и поймать опечатку в имени атрибута до запуска чего-то стоит. Но это описывает только то, что программа собиралась отправить. А если провайдер вернёт поле, которого нет в нашем типе? Реальное состояние впервые появляется в plan, и ничто на нашей стороне его не проверяло.

  4. Ссылка на ответ

    Справедливо, пока речь о редакторе. Если типизировать генерируемый конфиг через TypedDict в Python, тайпчекер поймает опечатку в ключе прямо в месте вызова, ещё до запуска. Это действительно полезно. Но во время выполнения TypedDict это обычный dict, так что прочитанное обратно от провайдера будет тем, что пришло по сети, если не проверить его самому.

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

Другие стороны того же вопроса

  1. asyncio.TaskGroup, когда один запрос падает

    Сравнение конкурентности в разных языках обычно начинают с синтаксиса. Я бы начал с того, что нужно расчёту, когда что-то пад…