github.com/hugorut/terraform@v1.1.3/website/docs/language/upgrade-guides/1-1.mdx (about)

     1  ---
     2  page_title: Upgrading to Terraform v1.1
     3  description: Upgrading to Terraform v1.1
     4  ---
     5  
     6  # Upgrading to Terraform v1.1
     7  
     8  Terraform v1.1 is the first minor release after establishing a compatibility
     9  baseline in Terraform v1.0, and so this release should not require any
    10  unusual upgrade steps for most users.
    11  
    12  However, if you are upgrading from a version earlier than v1.0 then please
    13  refer to [the Terraform v1.0 upgrade guide](/language/upgrade-guides/1-0) for how to upgrade through
    14  the v0 releases to reach the v1 release series. Because v1.1 is
    15  backward-compatible with the v1.0 series, you can upgrade directly to the
    16  latest v1.1 release, skipping the v1.0 series entirely, at any point where the
    17  v1.0 upgrade guide calls for upgrading to Terraform v1.0.
    18  
    19  Terraform v1.1 continues to honor
    20  [the Terraform v1.0 Compatibility Promises](/language/v1-compatibility-promises),
    21  but there are some behavior changes outside of those promises that may affect a
    22  small number of users, described in the following sections.
    23  
    24  * [Terraform requires macOS 10.13 High Sierra or later](#terraform-requires-macos-1013-high-sierra-or-later)
    25  * [Preparation for removing Azure AD Graph support in the AzureRM Backend](#preparation-for-removing-azure-ad-graph-support-in-the-azurerm-backend)
    26  * [Changes to `terraform graph`](#changes-to-terraform-graph)
    27  * [Changes to `terraform state mv`](#changes-to-terraform-state-mv)
    28  * [Provider checksum verification in `terraform apply`](#provider-checksum-verification-in-terraform-apply)
    29  
    30  ## Terraform requires macOS 10.13 High Sierra or later
    31  
    32  As operating system vendors phase out support for older versions of their
    33  software, the Terraform team must also phase out support in order to focus
    34  on supporting newer releases.
    35  
    36  With that in mind, the official releases of Terraform v1.1 now require
    37  macOS 10.13 High Sierra or later. Earlier versions of macOS are no longer
    38  supported, and Terraform CLI behavior on those earlier versions is undefined.
    39  
    40  ## Preparation for removing Azure AD Graph support in the AzureRM Backend
    41  
    42  [Microsoft has announced the deprecation of Azure AD Graph](https://docs.microsoft.com/en-us/graph/migrate-azure-ad-graph-faq),
    43  and so Terraform v1.1 marks the first phase of a deprecation process for
    44  that legacy system in [the AzureRM state storage backend](/language/settings/backends/azurerm).
    45  
    46  During the Terraform v1.1 release the default behavior is unchanged, but you
    47  can explicitly opt in to Microsoft Graph by setting
    48  `use_microsoft_graph = true` inside your `backend "azurerm` block and then
    49  reinitializing your working directory with `terraform init -reconfigure`.
    50  
    51  In Terraform v1.2 we plan to change this argument to default to `true` when
    52  not set, and so we strongly recommend planning to migrate to Microsoft Graph
    53  in the near future to prepare for the final removal of Azure AD Graph support
    54  in a later Terraform release. However, no immediate change is required before
    55  upgrading to Terraform v1.1.
    56  
    57  ## Changes to `terraform graph`
    58  
    59  The `terraform graph` command exists to help with debugging and so it
    60  inherently exposes some of Terraform Core's implementation details. For that
    61  reason it isn't included in the v1.0 Compatibility Promises, but we still
    62  aim to preserve its behavior in spirit even as Terraform Core's internal
    63  design changes.
    64  
    65  In previous releases, `terraform graph` exposed the implementation detail that
    66  Terraform internally knows how to build graph types called "validate" and
    67  "eval", but Terraform Core no longer exposes those graph types externally
    68  and so consequently the graph command will no longer accept the options
    69  `-type=validate` or `-type=eval`.
    70  
    71  You can see a similar result to what those graph types would previously
    72  produce by generating a _plan_ graph, which is the default graph type and
    73  therefore requires no special `-type=...` option.
    74  
    75  ## Changes to `terraform state mv`
    76  
    77  Terraform's local state storage backend supports a number of
    78  [legacy command line options](/language/settings/backends/local#command-line-arguments)
    79  for backward-compatibility with workflows from much older versions of Terraform,
    80  prior to the introduction of Backends.
    81  
    82  Those options are not supported when using any other backend, but for many
    83  commands they are simply silently ignored rather than returning an error.
    84  
    85  Because `terraform state mv` has some extra use-cases related to migrating
    86  between states, it historically had some slightly different handling of those
    87  legacy options, but was not fully consistent.
    88  
    89  From Terraform v1.1, the behavior of these options has changed as follows:
    90  
    91  * The `-state=...` argument is allowed even when a remote backend is specified
    92    in the configuration. If present, it forces the command to work in local
    93    mode.
    94  * The `-backup=...` and `-backup-out=...` options are allowed only if either
    95    the local backend is the configuration's selected backend _or_ if you
    96    specify `-state=...` to force local state operation. These options will now
    97    return an error if used against a remote backend, whereas previous Terraform
    98    versions ignored them entirely in that case.
    99  
   100  There are no breaking changes to `terraform state mv`'s normal usage pattern,
   101  without any special options overriding the state storage strategy.
   102  
   103  ## Provider checksum verification in `terraform apply`
   104  
   105  This section applies only to situations where you might generate a saved
   106  plan file using `terraform plan -out=tfplan` and then separately apply it
   107  using `terraform apply tfplan`.
   108  
   109  You do not need to consider this section unless you are using a custom
   110  Terraform provider which somehow modifies its own provider package contents
   111  during execution. That is hypothetically possible, but not true in practice for
   112  any publicly-available providers we are aware of at the time of writing this
   113  guide.
   114  
   115  Our design intent for this two-step run workflow is that the saved plan
   116  records enough information for Terraform to guarantee that it's running
   117  against an identical set of providers during the apply step as it was during
   118  the plan step, because otherwise the different provider plugins may disagree
   119  about the meaning of the planned actions.
   120  
   121  However, prior versions of Terraform verified consistency only for the main
   122  executable file representing a provider plugin, and didn't consider other
   123  files that might appear alongside in the plugin package. Terraform v1.1 now
   124  uses the same strategy for provider checking during apply as it does when
   125  verifying provider consistency against
   126  [the dependency lock file](/language/files/dependency-lock)
   127  during `terraform init`, which means `terraform apply` will return an error
   128  if it detects that _any_ of the files in a provider's plugin package have
   129  changed compared to when the plan was created.
   130  
   131  In the unlikely event that you _do_ use a self-modifying provider plugin,
   132  please consider other solutions to achieve the goals which motivated that,
   133  which do not involve the provider modifying itself at runtime. If you aren't
   134  sure, please open a GitHub issue to discuss your use-case.