Skip to content

Terraform: один абзац документации, в котором «безопасно» стоит вместо «зависит». Четыре года, вопрос без ответа, ответ, написанный за полтора месяца до вопроса в соседней задаче, и переработка справочника, сделавшая формулировку ещё категоричнее.

v1 0 stars 0 forks 0 watchers 1 branch 0 runs Public
mikicreated via APIv1

Terraform, апрель 2022 — сентябрь 2026.

Terraform держит инфраструктуру описанной в файлах: вот кластер, вот база, вот права. Провайдер — переходник к облаку, и его тоже настраивают в этих файлах.

Один абзац документации про эти настройки живёт с 2020 года. Из-за него — история на четыре года, в которой все правы, а читатель всё равно не знает, что ему можно.

21 апреля 2022 — Томас приносит абзац и пример.

Thomas Ball открывает issue #30910. Он не жалуется на ошибку — он цитирует документацию и показывает, что она расходится с поведением:

You can use expressions in the values of these configuration arguments, but can only reference values that are known before the configuration is applied. This means you can safely reference input variables, but not attributes exported by resources.

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

А дальше приводит рабочий пример: создаёт кластер и настраивает провайдер Kubernetes ровно теми атрибутами, которых «до применения» знать нельзя. Работает.

Тот же день — Джеймс объясняет, что слово важнее, чем кажется.

Отвечает James Bardin из HashiCorp — в день обращения:

I think the key phrase in the quoted docs is "you can safely reference". As you have shown the references will work in the configuration, however computed resource attributes may not be known during planning so the provider may not be fully configured at that time. Depending on the provider this may work just fine, may never work, or fall somewhere in between where it fails only under certain conditions.

Ключевое слово в цитате — «безопасно». Ссылки действительно работают, но вычисляемые атрибуты могут быть неизвестны на этапе планирования, и провайдер в этот момент может оказаться не настроен полностью. В зависимости от провайдера это может работать прекрасно, может не работать никогда, а может падать только при определённых условиях.

И дальше — фраза, которая объясняет весь абзац:

While we definitely don't recommend configurations like this, they are allowed for backwards compatibility. Perhaps the documentation could be improved here.

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

То есть документация говорит «нельзя», движок разрешает, а правда — «зависит от провайдера». Одно слово, «безопасно», несёт всю эту разницу.

22 апреля — Джесси задаёт вопрос, который решает всё.

Jesse Schalken не спорит с решением. Он спрашивает, как им пользоваться:

Can you provide an example of precisely how the above configuration might fail? How can someone know if they are in the "works just fine" category?

Можете показать точно, как такая конфигурация падает? Как человеку понять, что он в категории «работает прекрасно»?

И добавляет наблюдение, от которого трудно отмахнуться:

I don't think a merely abstract admonishment from either you or the docs is enough to outweigh the enormous simplification that comes with being able to manage both GKE and cluster resources in the same Terraform config if it works just fine according to our testing.

Абстрактного предостережения — вашего или документации — недостаточно, чтобы перевесить огромное упрощение: держать и кластер, и его ресурсы в одной конфигурации. По нашим тестам это прекрасно работает.

Он приносит ответ со StackOverflow с девятью голосами, где ровно так и советуют.

Ответ существовал. За полтора месяца до вопроса.

Джеймс даёт ссылку на комментарий в задаче #2430. Там, 4 марта 2022 года, Alex Somesan — сопровождающий провайдера Kubernetes — уже написал точный механизм:

All but one resources in the Kubernetes provider are "classic" terraform resources […] These resources DO NOT need access to the cluster API at planning time and can actually produce a plan in absence of a complete provider configuration. […] As long as all the unknown inputs to the provider block attributes can be resolved to concrete values before apply, they will work.

Все ресурсы провайдера Kubernetes, кроме одного, — «классические» […] Им НЕ нужен доступ к API кластера на этапе планирования, и план они строят даже при неполной настройке провайдера. […] Пока все неизвестные значения успевают стать конкретными до применения — они работают.

Ответ на вопрос Джесси — здесь, целиком, написан за полтора месяца до того, как вопрос задали. Он просто лежит в другой задаче, среди ста тридцати восьми комментариев, и в документацию не попал.

23 апреля — пользователь пишет за проект новый абзац.

Томас возвращается не с претензией, а с текстом: предлагает заменить спорный абзац на объяснение, почему так устроено и какие бывают исключения. Готовая правка от человека, который два дня назад впервые пришёл в проект.

В тот же день Джесси формулирует претензию к слову — так точно, как редко удаётся:

It shouldn't write off such a broadly used configuration as "unsafe" but instead say that whether resources can be planned before their provider is configured […] is provider-dependent. It is not "unsafe", the safety depends on the resource and provider in question.

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

28 апреля — 22 июня: последний вопрос без ответа.

Алекс показывает, что у ресурса kubernetes_manifest требование расписано яснее некуда — в документации самого провайдера.

Джесси отвечает через два месяца, и это последнее сообщение в теме на четыре года:

That says that kubernetes_manifest needs cluster access during plan time, but where are the docs saying that the other resources don't?

Там сказано, что kubernetes_manifest нужен доступ к кластеру во время планирования. А где написано, что остальным ресурсам — не нужен?

Отсутствие документации нельзя процитировать. Именно поэтому такие вопросы остаются без ответа: возразить нечем, и согласиться не на что.

Хвост: абзац переписали — и стало категоричнее.

2 июля 2025 Ruben Nic открывает большую переработку справочника: 357 файлов, +25 671/−16 695. Влита 5 сентября 2025-го. С версии 1.12 абзац звучит так:

You can reference input variables and arguments that you specify directly in your configuration, but you cannot reference computed resource attributes, such as google.web.public_ip.

Ссылаться можно на входные переменные и на аргументы, заданные прямо в конфигурации, но нельзя — на вычисляемые атрибуты ресурсов, например google.web.public_ip.

Слово «безопасно» ушло. Вместе с ним ушла и оговорка: было двусмысленное «безопасно», стало прямое «нельзя». А движок по-прежнему позволяет — ровно как объяснял Джеймс в 2022-м, ради обратной совместимости.

Заодно документация уехала из репозитория Terraform в отдельный web-unified-docs: задача про документацию осталась там, где документации больше нет.

1 сентября 2026 в четырёхлетней тишине появляется новое сообщение от LeonxLJX: «I'd like to take this one. I'll look into the root cause and follow up with a PR» — возьмусь за эту; разберусь в причине и пришлю правку.

Задача открыта до сих пор.

Здесь нет виноватых.

Джеймс ответил в день обращения, объяснил механизм и сам сказал, что абзац стоило бы улучшить. Алекс написал исчерпывающее объяснение — просто не в том месте, где его искали. Томас принёс готовый текст. Джесси задал единственно важный вопрос и получил всё, кроме ответа на него.

Трещина не в людях, а в жанре. Документация обязана быть короткой, а правда здесь длинная: «зависит от провайдера, от ресурса и от того, успеет ли значение стать известным до применения». Короткое слово вместо этого абзаца приходится выбирать — и любое выбранное слово («безопасно», «нельзя») будет сильнее правды.

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

Что это значит для нас

1
Проверить слова, которыми документация обещает безопасность

Найти в своих текстах «выключено», «недоступно», «закрыто», «нельзя» — и проверить каждое запуском, а не чтением кода.

Why: У нас было написано: «MCP_TOKEN пусто — ЭНДПОИНТ ВЫКЛЮЧЕН». Правда другая: пустая переменная выключает только служебный путь, а персональные токены проверяются раньше окружения и работают. Ошибка та же, что в Terraform, но в сторону, где ошибаться нельзя: их слово пугало сильнее правды, наше — успокаивало.
Check
  • Каждое «выключено» проверено запросом, а не чтением
  • Там, где правда длинная, она написана длинно
2
Писать «зависит» там, где зависит

Если поведение зависит от провайдера, окружения или роли — назвать зависимость и её условия. Короткое слово выбирать нельзя: любое будет сильнее правды.

Why: «Безопасно» и «нельзя» одинаково неверны для поведения, которое зависит от ресурса. Джесси четыре года просил ровно этого: не запрета и не разрешения, а списка условий.
Check
  • Найдено ли в тексте хоть одно «нельзя», за которым скрывается «зависит»
  • Условия перечислены, а не заменены предостережением
3
Искать то, чего в документации нет

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

Why: У нас пятнадцать переменных из `.env.example` не были описаны в справочнике — включая `ARCHIVE_PREFIXES`, то есть границу доступа к архиву. Последний вопрос Джесси («а где написано, что остальным не нужен?») остался без ответа ровно потому, что спрашивал он про отсутствие.
Check
  • Сверка запускается сама, а не по памяти
  • Каждая переменная окружения описана там, где сказано, что будет, если её не задать
4
Убирать обещания того, чего нетRecommended

Пройти по руководству пользователя и проверить, что каждая названная кнопка и каждый экран существуют.

Why: Наше руководство описывало кнопку «Поделиться» в шапке. Её там нет — компонент не рендерился ниоткуда. Обещанная и отсутствующая кнопка обесценивает весь документ: дальше читатель перестаёт верить и верным абзацам.
Check
  • Названия из документации находятся в коде как подписи интерфейса
  • Обещания, которых нет, убраны, а не отложены

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

Вопрос Джесси — «а где написано, что остальным ресурсам не нужен доступ?» — за четыре года так и не получил ответа. Не потому, что ответа нет: он есть, в соседней задаче, от марта 2022-го.

Просто он не помещается в одно слово.

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

v10Public 0 0
updated Sep 1, 2026

Saleor: товар сняли с продажи — и строку из корзины покупателя стирали в фоне. Три с половиной года до теста, поменявшего знак

v1Public 0 0
updated Sep 2, 2026

Люди и проекты из разборов — по поступкам, датам и ссылкам. Как определитель птиц: не оценивает, а помогает узнать, кого встретил

v9Public 0 0
updated Sep 2, 2026

Better Auth: ограничение частоты считалось от последнего запроса, включая отклонённые, — и разблокировка не наступала никогда

v6Public 0 0
updated Sep 2, 2026

Как проект принимает чужие правки: что написано в правилах, что видно по переписке и кого вы там встретите

v1Public 0 0
updated Sep 2, 2026

Medusa: защита от повтора отказывает там, где можно было ответить, и пропускает там, где повтор стоит денег

v2Public 0 0
updated Sep 2, 2026