Обещания совместимости OpenTofu v1.x

Выпуск OpenTofu v1.6 стал важной вехой в развитии языка и рабочего процесса OpenTofu. OpenTofu v1.x — стабильная платформа для описания инфраструктуры и управления ею.

В этом выпуске мы определяем ряд особенностей OpenTofu, совместимость которых намерены сохранять на протяжении всех выпусков 1.x:

• Большое подмножество возможностей языка OpenTofu.
• Более ограниченное подмножество команд рабочего процесса OpenTofu CLI.
• Протокол обмена данными между OpenTofu Core и провайдерами OpenTofu.
• Протоколы обмена данными для установки провайдеров и внешних модулей.

Мы намерены обеспечить, чтобы модули, написанные для OpenTofu v1.6, продолжали успешно выполнять планирование и применение без необходимости изменений во всех выпусках v1.x.

Мы также намерены обеспечить работу автоматизации, построенной на основе подмножества рабочего процесса, описанного в этом документе, без изменений во всех будущих выпусках v1.x.

Наконец, мы намерены обеспечить совместимость провайдеров, созданных на основе документированного на данный момент протокола обмена данными провайдеров, со всеми будущими выпусками OpenTofu v1.x для той же операционной системы и архитектуры без необходимости изменять исходный код или повторно компилировать двоичные файлы.

Вкратце, мы стремимся сделать переходы между выпусками v1.x простыми: не потребуется менять конфигурацию, выполнять дополнительные команды для обновления или вносить изменения в настроенную вами автоматизацию OpenTofu.

Серия OpenTofu v1.x будет активно поддерживаться как минимум 18 месяцев после выпуска v1.6.

В следующих разделах приведены конкретные сведения о наших обещаниях на протяжении серии v1.x для тех, кому нужны подробности. Однако на более общем уровне мы не намерены вносить изменения, из-за которых при переходе на новый выпуск v1.x потребуется менять существующие модули или автоматизацию. Как правило, проблемы совместимости в новых выпусках OpenTofu CLI мы будем считать ошибками, которые нужно исправить, за исключением случаев, когда для изменения есть веская причина, например необходимость устранить критическую проблему безопасности или соответствовать несовместимому изменению удалённой зависимости, на которую мы не можем напрямую повлиять.

Язык OpenTofu​

Основной язык OpenTofu включает синтаксис языка, структуры верхнего уровня, такие как блоки resource, module и provider, «метааргументы» в этих блоках, а также документированную семантику и поведение операторов и встроенных функций, доступных в выражениях.

Формальной спецификации языка OpenTofu не существует, однако раздел Configuration документации на сайте OpenTofu описывает возможности языка и предполагаемое поведение этих возможностей.

Следующие блоки верхнего уровня и определённые для них «метааргументы» (то есть аргументы, определённые OpenTofu Core, а не внешними плагинами, например провайдерами) сохранят свою текущую функциональность:

• resource и data — блоки для объявления ресурсов, включая их вложенные типы блоков lifecycle, connection и provisioner, а также метааргумент provider.
• module — блоки для вызова других модулей и метааргумент providers.
• Метааргументы count, for_each и depends_on в блоках resource, data и module.
• provider — блоки для настройки провайдеров и метааргумент alias.
• variable, output и locals — блоки для объявления различных видов именованных значений в модуле.
• terraform — блоки, включая вложенные аргументы required_version и required_providers, а также вложенные блоки backend для настройки бэкенда.

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

Мы намерены обеспечить широкую совместимость с возможностями языка OpenTofu, за некоторыми конкретными исключениями:

• Мы считаем конфигурацию допустимой, если OpenTofu может создать и применить для неё план, не сообщая об ошибках.

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

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

• Если фактическое поведение функции отличается от того, которое мы явно задокументировали, обычно мы будем считать это ошибкой и изменим функцию в соответствии с документацией, однако постараемся не вносить такие изменения, если они могут привести к серьёзным проблемам совместимости. Мы не можем обещать всегда сохранять «совместимость с ошибками» предыдущих выпусков, но будем тщательно рассматривать такие исправления, чтобы свести их влияние к минимуму.

• Любые экспериментальные функции могут измениться или быть полностью удалены из будущих выпусков. OpenTofu всегда выдаёт предупреждение при использовании экспериментальной языковой функции, чтобы вы знали о связанном с этим риске. Мы не рекомендуем использовать экспериментальные функции в рабочих модулях.

• Мы будем добавлять новые языковые функции. Если вы начнёте их использовать, ваша конфигурация не будет работать с предыдущими версиями OpenTofu, в которых эти функции ещё не поддерживались.

• Провайдеры — это отдельные плагины, которые могут изменяться независимо от OpenTofu Core, поэтому на них не распространяются эти обещания совместимости. При обновлении используемых провайдеров может потребоваться изменить конфигурации провайдеров или ресурсов, связанные с ними.

• В OpenTofu v1.6 небольшое число функций остаётся устаревшими; об этом выдаются явные предупреждения. Циклы устаревания завершатся в одном из будущих выпусков v1.x, после чего соответствующие функции будут удалены.

Рабочий процесс​

Существует набор часто используемых рабочих процессов OpenTofu, которые мы называем защищёнными рабочими процессами. Мы не будем удалять эти команды, подкоманды и флаги или вносить обратно несовместимые изменения в функциональность защищённых рабочих процессов. Если мы случайно изменим её, то будем считать обратно несовместимые изменения основных рабочих процессов ошибками, которые следует исправить. Список сочетаний команд и параметров, входящих в защищённые рабочие процессы, см. в разделе Команды защищённых рабочих процессов. Существует и другой набор команд, для которых мы явно не обещаем сохранять совместимость, поскольку ожидаем, что их функциональность будет меняться в выпусках v1.x: см. раздел Команды, которые могут измениться.

Поддерживаемые способы взаимодействия внешнего программного обеспечения с OpenTofu — это режимы вывода JSON, предоставляемые некоторыми командами, и коды завершения. Мы можем расширять некоторые форматы JSON, добавляя новые свойства объектов, но не будем удалять существующие свойства или вносить несовместимые изменения в их определения.

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

Обновление и откат​

На протяжении серии выпусков v1.x мы намерены обеспечить возможность перейти на более новую версию OpenTofu и использовать её как прежде, без специальных действий для обновления.

Вы сможете перейти с любого выпуска v1.x на любой более поздний выпуск v1.x. Возможно, вы также сможете выполнить откат до более раннего выпуска v1.x, но это не гарантируется: в более поздних выпусках могут появиться новые функции, которые предыдущие версии не смогут распознать, в том числе новые форматы хранения снимков состояния OpenTofu.

Если вы используете функции, появившиеся в более позднем выпуске v1.x, ваша конфигурация будет несовместима с выпусками, предшествующими появлению этих функций. Например, если в v1.7 добавлена языковая функция и вы начнёте её использовать, ваша конфигурация OpenTofu перестанет быть совместимой с OpenTofu v1.6.

Провайдеры​

Провайдеры OpenTofu — это отдельные плагины, которые взаимодействуют с OpenTofu по документированному протоколу. Поэтому эти обещания совместимости могут распространяться только на клиентскую часть протокола, реализованную в OpenTofu Core; поведение отдельных провайдеров, в том числе поддерживаемые ими типы ресурсов и ожидаемые аргументы, определяют команды разработчиков провайдеров, и оно может изменяться независимо от выпусков OpenTofu Core.

При переходе на новую версию провайдера может потребоваться изменить части конфигурации, которые интерпретирует этот провайдер, даже если вы продолжаете использовать выпуск OpenTofu v1.x.

Способы установки провайдеров​

Обычно OpenTofu устанавливает провайдеры из реестра провайдеров, реализующего протокол реестра провайдеров версии 1. Все выпуски OpenTofu v1.x сохранят совместимость с этим протоколом, поэтому реестры провайдеров с корректной реализацией протокола останутся совместимыми.

OpenTofu также поддерживает установку провайдеров из локальных каталогов файловой системы (зеркал файловой системы) и из сетевых зеркал (реализующих протокол зеркала провайдеров). Все выпуски OpenTofu v1.x сохранят совместимость с этими способами установки, включая неявно используемые локальные каталоги зеркал.

Отдельные реестры провайдеров и сетевые зеркала работают независимо от OpenTofu, поэтому их собственное поведение не подпадает под эти обещания совместимости.

Версии протокола провайдеров​

В OpenTofu v1.6 текущая основная версия протокола плагинов провайдеров — версия 5. Она определяется сочетанием схемы Protocol Buffers, описывающей физические форматы обмена данными, и дополнительной текстовой документации, описывающей ожидаемое поведение провайдера.

Мы будем поддерживать протокол версии 5 во всех выпусках OpenTofu v1.x. Если в будущих выпусках мы внесём новые второстепенные изменения в протокол версии 5, то спроектируем их так, чтобы существующие плагины продолжали работать при условии корректной реализации протокола.

В серии v1.x мы можем добавить новые основные версии протокола. В таком случае мы продолжим поддерживать протокол версии 5 наряду с новыми версиями. Отдельные команды разработчиков провайдеров могут решить отказаться от поддержки протокола версии 5 в более поздних выпусках; тогда эти новые выпуски провайдеров будут несовместимы с некоторыми выпусками OpenTofu v1.x.

Внешние модули​

Модули — это повторно используемые компоненты инфраструктуры, написанные на языке OpenTofu. Некоторые модули являются «внешними»: OpenTofu автоматически устанавливает их из расположения, отличного от каталога текущей конфигурации. В этом случае их содержимое может меняться независимо от изменений локальных модулей, используемых вами провайдеров и самого OpenTofu.

Способы установки модулей​

OpenTofu поддерживает установку дочерних модулей из нескольких типов источников модулей. Мы продолжим поддерживать все существующие типы источников во всех выпусках v1.x.

Один из поддерживаемых типов источников — реестр модулей, реализующий протокол реестра модулей версии 1. Все выпуски OpenTofu v1.x сохранят совместимость с корректными реализациями этого протокола.

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

Совместимость внешних модулей​

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

Провижионеры​

Мы будем обеспечивать совместимость типов провижионеров file, local-exec и remote-exec во всех выпусках v1.x.

OpenTofu поддерживает загрузку дополнительных провижионеров в качестве плагинов из определённых локальных каталогов файловой системы. Мы продолжим поддерживать эту возможность во всех выпусках OpenTofu v1.x, однако, поскольку такие плагины являются отдельными от OpenTofu Core компонентами, их собственное поведение не подпадает под эти обещания совместимости. При этом мы продолжим поддерживать протокол обмена данными плагинов, определённый в OpenTofu v1.6, во всех выпусках v1.x, поэтому плагины провижионеров с корректной реализацией протокола должны оставаться совместимыми с будущими выпусками OpenTofu.

Бэкенды хранения состояния​

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

По историческим причинам все поддерживаемые бэкенды хранения состояния включены в OpenTofu CLI, однако не все из них непосредственно поддерживаются командой OpenTofu. Обещания совместимости распространяются только на следующие бэкенды, поддерживаемые командой OpenTofu:

• local (по умолчанию, если вы не используете удалённое состояние)
• http

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

Мы рассматриваем возможность разрешить реализацию внешних бэкендов хранения состояния с помощью плагинов, аналогично плагинам провайдеров. Если мы внедрим такой механизм в серии выпусков v1.x, для использования этих плагинов может потребоваться изменить конфигурацию, а бэкенды хранения состояния, не перечисленные выше, могут быть удалены из последующих версий OpenTofu CLI, когда появятся эквивалентные плагины.

Бэкенд remote​

Поведение бэкенда remote может меняться со временем, поэтому на него не распространяются эти обещания совместимости.

Бэкенды хранения состояния, поддерживаемые сообществом​

Бэкенды azurerm, consul, s3 и kubernetes поддерживаются другими командами HashiCorp. Эти команды намерены продолжать базовую поддержку, включая исправление ошибок, во всех выпусках v1.x. Если мы реализуем протокол плагинов для бэкендов, разработка этих бэкендов, вероятно, будет продолжаться только во внешних плагинах; для перехода на эквивалентные плагины может потребоваться изменить конфигурацию.

Бэкенды cos, oss, pg, gcs и etcdv3 поддерживаются сторонними участниками сообщества, и на них не распространяются эти обещания совместимости.

Бэкенды хранения состояния без поддержки​

У бэкендов хранения состояния artifactory, etcdv2, manta и swift сейчас нет сопровождающих, поэтому они остаются в выпусках OpenTofu CLI лишь при наличии возможности их поддерживать. Они могут быть удалены в более поздних выпусках v1.x и не будут обновляться в случае несовместимых изменений служб, с которыми они интегрированы.

Поддерживаемые платформы​

Набор платформ (операционных систем и архитектур процессоров), часто используемых нашим сообществом, постоянно меняется независимо от нас, поэтому мы не можем гарантировать поддержку каких-либо конкретных платформ на протяжении всей серии v1.x.

Тем не менее, мы намерены продолжать поддерживать платформы, широко используемые нашим сообществом и имеющие надёжную поддержку со стороны поставщиков, а также другого программного обеспечения (библиотек и языков программирования), с помощью которого собирается и тестируется OpenTofu. Мы намерены предупреждать о прекращении поддержки любой из поддерживаемых сейчас платформ не менее чем за два выпуска серии минорных версий, кроме случаев, когда более быстрое изменение вызвано внезапными изменениями политики поддержки поставщиков, на которые мы не можем повлиять.

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

• macOS на Apple Silicon (darwin_arm64)
• Windows на процессорах x64 (windows_amd64)
• Linux на x64 и 64-разрядной ARM (соответственно linux_amd64 и linux_arm64)

Со временем мы можем повысить требования к версиям этих операционных систем. Например, последующие выпуски OpenTofu серии v1.x могут прекратить поддержку более ранних версий macOS или Windows либо более ранних выпусков ядра Linux.

Ранее мы выпускали официальные версии для ряда других платформ, чтобы пользователям этих платформ было удобнее работать, однако не можем обещать, что в серии v1.x для остальных платформ будут регулярно выпускаться обновления и исправления ошибок. Мы не тестируем OpenTofu регулярно на платформах, кроме перечисленных выше.

В более поздних выпусках v1.x мы можем добавить поддержку новых платформ. В таком случае более ранние выпуски OpenTofu, предшествующие появлению этой поддержки, будут недоступны для этих платформ.

Все плагины OpenTofu, включая плагины провайдеров, — это отдельные программы со своими правилами поддержки платформ. Мы не можем гарантировать, что все провайдеры поддерживают или продолжат поддерживать перечисленные выше платформы, даже если сам OpenTofu CLI будет их поддерживать.

Последующие изменения этих обещаний​

На протяжении серии v1.x мы можем расширять или уточнять эти обещания, чтобы описать обязательства, связанные с новыми функциями, или прояснить уже существующие обещания, если на основе отзывов выяснится, что прежние формулировки были неясными.

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

Даже если мы не добавим в этот документ отдельное утверждение, мы намерены обеспечить совместимость всех неэкспериментальных функций, добавленных в более поздних выпусках v1.x, как минимум до конца серии v1.x, если не указано иное.

Приложения​

Команды защищённых рабочих процессов​

Ниже приведён список подкоманд и параметров OpenTofu CLI, на которые распространяются эти обещания совместимости. Если вы создадите автоматизацию на основе этих команд, она должна оставаться совместимой со всеми более поздними выпусками v1.x.

Как отмечалось выше, совместимость с внешним программным обеспечением ограничивается явно машиночитаемым выводом (режимами -json и -raw) и кодами завершения. Любой текстовый вывод этих команд может измениться в последующих выпусках.

• init
  • -backend=false
  • -backend-config=FILE
  • -backend-config="KEY=VALUE"
  • -force-copy
  • -get=false
  • -input=false
  • -migrate-state
  • -no-color
  • -plugin-dir=DIR
  • -reconfigure
  • -upgrade
• validate
  • -json
  • -no-color
• plan
  • -compact-warnings
  • -destroy
  • -detailed-exitcode
  • -lock=false
  • -lock-timeout=DURATION
  • -input=false
  • -json
  • -no-color
  • -out=FILE
  • -parallelism=N
  • -refresh=false
  • -refresh-only
  • -replace=ADDRESS
  • -target=ADDRESS
  • -var 'NAME=VALUE'
  • -var-file=FILE
• apply
  • -auto-approve
  • -compact-warnings
  • -lock=false
  • -lock-timeout=DURATION
  • -input=false
  • -json
  • -no-color
  • -parallelism=N
  • -refresh=false
  • -refresh-only
  • -replace=ADDRESS
  • -target=ADDRESS
  • -var 'NAME=VALUE'
  • -var-file=FILE
• show
  • -no-color
  • -json
  • (с файлом плана и без него)
• providers (без подкоманды)
• providers lock
  • -fs-mirror=PATH
  • -net-mirror=URL
  • -platform=OS_ARCH
• providers mirror
  • -platform=OS_ARCH
• providers schema
  • -json
• fmt
  • -list=false
  • -write=false
  • -diff
  • -recursive
  • -check
• version
  • -json
• output
  • -no-color
  • -json
  • -raw
• taint
  • -allow-missing
  • -lock=false
  • -lock-timeout=DURATION
  • -ignore-remote-version
• untaint
  • -allow-missing
  • -lock=false
  • -lock-timeout=DURATION
  • -ignore-remote-version
• force-unlock
  • -force
• state list
  • -id=ID
• state pull
• state push
  • -force
  • -lock=false
  • -lock-timeout=DURATION
• state show
  • -ignore-remote-version
• login

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

Обратите внимание: хотя внутренние журналы OpenTofu (через переменную среды TF_LOG) доступны в формате JSON, конкретный синтаксис и структура строк журнала не являются поддерживаемым интерфейсом интеграции. Журналы доступны в формате JSON только для того, чтобы разработчикам OpenTofu было проще выполнять разовую фильтрацию и обработку журналов.

Команды, которые могут измениться​

На все перечисленные ниже команды и их подкоманды и параметры не распространяются гарантии совместимости: либо у нас уже есть планы улучшить их в серии v1.x, либо мы знаем о недостатках их дизайна, которые могут потребовать несовместимых изменений для дальнейшего сопровождения.

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

• destroy (вместо этого рассмотрите tofu apply -destroy)
• console
• get (вместо этого рассмотрите tofu init)
• graph
• import
• push
• refresh (вместо этого рассмотрите tofu apply -refresh-only)
• state mv
• state replace-provider
• state rm
• все подкоманды workspace (и его устаревшего псевдонима env)

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

Как мы будем выполнять эти обещания​

Автоматизированное регрессионное тестирование​

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

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

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

Предварительные версии​

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

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

Регрессии в окончательных выпусках​

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

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

Снизить риск, связанный с незамеченными регрессиями в окончательных выпусках, можно, заранее тестируя модули с альфа-, бета-версиями и версиями-кандидатами. Мы рекомендуем проводить такие тесты только в изолированных средах разработки или тестирования, а не в рабочей инфраструктуре. Если вы обнаружите в предварительной сборке изменение поведения, которое, по вашему мнению, противоречит обещаниям из этого документа, сообщите об этом в виде задачи в репозитории OpenTofu на GitHub.

Регрессии, о которых сообщили с опозданием​

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

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

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

Практические исключения​

Мы даём приведённые выше обещания добросовестно и стремимся к тому, чтобы ваши вложения в разработку модулей OpenTofu или автоматизации не обесценились из-за будущих изменений OpenTofu. Однако столь широкие обещания не могут охватить все нюансы практических проблем, которые могут возникнуть по мере дальнейшей разработки OpenTofu.

Поэтому в некоторых ситуациях нам всё же может потребоваться вносить изменения, которые повлияют на существующие модули или автоматизацию:

• Проблемы безопасности: мы можем обнаружить недостаток дизайна, который создаёт существенную угрозу безопасности. В зависимости от оценки связанного с ним риска мы можем решить нарушить совместимость, чтобы сделать систему безопаснее.
• Внешние зависимости: поведение OpenTofu зависит от интерфейсов, предоставляемых сторонними кодовыми базами, в том числе выбранной вами операционной системой и некоторыми удалёнными сетевыми службами, например используемыми для установки модулей и провайдеров. Эти внешние системы могут меняться независимо от нас, в том числе их функции, от которых зависят собственные возможности OpenTofu, могут быть удалены или изменены. Если в таком случае подходящего механизма замены не окажется, нам, возможно, придётся изменить архитектуру OpenTofu, чтобы она соответствовала новым ограничениям.
• Изменения совместимости, требующие явного включения: для проектирования новой языковой функции может потребоваться изменить поведение или представление конфигурации существующей функции. В таком случае мы обычно делаем новую функцию доступной только при явном включении, чтобы не нарушать работу существующих модулей. Однако если вы измените модуль и включите новую функцию, вам может потребоваться изменить и другие части конфигурации, чтобы они соответствовали новому устройству языка.
• Ошибки в новых функциях: если мы добавим в OpenTofu новую функцию, а её первоначальная реализация будет иметь проблемы и не будет соответствовать задокументированному замыслу на момент выпуска, мы можем выпустить обновление, исправляющее реализацию в соответствии с документацией, даже если это приведёт к небольшому снижению совместимости по сравнению с первоначальной реализацией. Однако, когда функция станет устоявшейся и широко используемой, мы обычно будем считать приоритетным реализованное поведение и изменим документацию, чтобы она ему соответствовала.
• Регрессии существующих функций: если мы узнаем, что новый выпуск OpenTofu содержит регрессию существующей функции, не выявленную во время разработки и предварительных выпусков, и узнаем об этом вскоре после выхода нового выпуска, мы обычно восстановим прежнее поведение. Формально это нарушит совместимость с поведением нового выпуска, но мы будем исходить из того, что систем, затронутых регрессией, больше, чем систем, зависящих от недавно появившегося поведения.
• Регрессии, о которых сообщили с опозданием: как описано в предыдущем разделе, если мы узнаем, что в гораздо более раннем выпуске произошло непреднамеренное изменение редко используемой функции или сочетания функций, восстановление прежнего поведения может показаться регрессией тем, кто начал использовать OpenTofu позднее. Если мы решим, что исправление регрессии затронет больше пользователей, чем сама регрессия, мы можем принять её как новое гарантируемое поведение.
• Непредвиденные ситуации: хотя мы постарались учесть здесь различные конкретные исключительные ситуации, OpenTofu и процесс его разработки не изолированы от более широкого контекста. Поэтому мы должны допускать, что могут возникнуть совершенно непредвиденные обстоятельства, влияющие на будущее OpenTofu. В таких ситуациях мы всегда приложим все усилия, чтобы выбрать путь, который максимально уменьшит влияние на существующие модули и автоматизацию.

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