Обещания совместимости 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 мы продолжим выпускать официальные версии для следующих платформ и при необходимости вносить изменения для поддержки новых выпусков этих операционных систем:

• macOS на процессорах x64 (darwin_amd64)
• Windows на процессорах x64 (windows_amd64)
• Linux на x64, ARMv6 (32-разрядная архитектура) и ARMv8 (64-разрядная архитектура) (соответственно linux_amd64, linux_arm и linux_arm64)

Со временем нам могут потребоваться более новые версии этих операционных систем. Например, в последующих выпусках серии 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. В таких ситуациях мы всегда будем стараться выбрать такой план действий, который максимально снизит влияние на существующие модули и средства автоматизации.

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