IntenseWebs/opentofu
3
0
Fork 0
mirror of https://github.com/opentofu/opentofu.git synced 2025-02-25 18:45:20 -06:00
Code Issues Packages Projects Releases Wiki Activity

Update website/docs/language/providers (#231)

Browse Source 
Signed-off-by: Marcin Białoń <mbialon@spacelift.io>
This commit is contained in:
Marcin Białoń 2023-08-30 00:11:57 +02:00 committed by GitHub
parent f769350c88
commit 932c32008c
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 109 additions and 208 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

50
website/docs/language/providers/configuration.mdx
View File

@ -7,25 +7,25 @@ description: >-
# Provider Configuration
Providers allow Terraform to interact with cloud providers, SaaS providers, and
Providers allow OpenTF to interact with cloud providers, SaaS providers, and
other APIs.
Some providers require you to configure them with endpoint URLs, cloud regions,
or other settings before Terraform can use them. This page documents how to
or other settings before OpenTF can use them. This page documents how to
configure settings for providers.
Additionally, all Terraform configurations must declare which providers they
require so that Terraform can install and use them. The
[Provider Requirements](/terraform/language/providers/requirements)
page documents how to declare providers so Terraform can install them.
Additionally, all OpenTF configurations must declare which providers they
require so that OpenTF can install and use them. The
[Provider Requirements](/opentf/language/providers/requirements)
page documents how to declare providers so OpenTF can install them.
## Provider Configuration
Provider configurations belong in the root module of a Terraform configuration.
Provider configurations belong in the root module of a OpenTF configuration.
(Child modules receive their provider configurations from the root module; for
more information, see
[The Module `providers` Meta-Argument](/terraform/language/meta-arguments/module-providers)
and [Module Development: Providers Within Modules](/terraform/language/modules/develop/providers).)
[The Module `providers` Meta-Argument](/opentf/language/meta-arguments/module-providers)
and [Module Development: Providers Within Modules](/opentf/language/modules/develop/providers).)
A provider configuration is created using a `provider` block:
@ -37,7 +37,7 @@ provider "google" {
```
The name given in the block header (`"google"` in this example) is the
[local name](/terraform/language/providers/requirements#local-names) of the provider to
[local name](/opentf/language/providers/requirements#local-names) of the provider to
configure. This provider should already be included in a `required_providers`
block.
@ -46,7 +46,7 @@ the provider. Most arguments in this section are defined by the provider itself;
in this example both `project` and `region` are specific to the `google`
provider.
You can use [expressions](/terraform/language/expressions) in the values of these
You can use [expressions](/opentf/language/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 (with an exception for resource
@ -54,24 +54,24 @@ arguments that are specified directly in the configuration).
A provider's documentation should list which configuration arguments it expects.
For providers distributed on the
[Terraform Registry](https://registry.terraform.io), versioned documentation is
[Public Terraform Registry](https://registry.terraform.io), versioned documentation is
available on each provider's page, via the "Documentation" link in the
provider's header.
Some providers can use shell environment variables (or other alternate sources,
like VM instance profiles) as values for some of their arguments; when
available, we recommend using this as a way to keep credentials out of your
version-controlled Terraform code.
version-controlled OpenTF code.
There are also two "meta-arguments" that are defined by Terraform itself
There are also two "meta-arguments" that are defined by OpenTF itself
and available for all `provider` blocks:
- [`alias`, for using the same provider with different configurations for different resources][inpage-alias]
- [`version`, which we no longer recommend][inpage-versions] (use
[provider requirements](/terraform/language/providers/requirements) instead)
[provider requirements](/opentf/language/providers/requirements) instead)
Unlike many other objects in the Terraform language, a `provider` block may
be omitted if its contents would otherwise be empty. Terraform assumes an
Unlike many other objects in the OpenTF language, a `provider` block may
be omitted if its contents would otherwise be empty. OpenTF assumes an
empty default configuration for any provider that is not explicitly configured.
## `alias`: Multiple Provider Configurations
@ -129,14 +129,14 @@ use the default provider configuration that matches the first word of the
resource type name. (For example, an `aws_instance` resource uses the default
`aws` provider configuration unless otherwise stated.)
If every explicit configuration of a provider has an alias, Terraform uses the
If every explicit configuration of a provider has an alias, OpenTF uses the
implied empty configuration as that provider's default configuration. (If the
provider has any required configuration arguments, Terraform will raise an error
provider has any required configuration arguments, OpenTF will raise an error
when resources default to the empty configuration.)
### Referring to Alternate Provider Configurations
When Terraform needs the name of a provider configuration, it expects a
When OpenTF needs the name of a provider configuration, it expects a
reference of the form `<PROVIDER NAME>.<ALIAS>`. In the example above,
`aws.west` would refer to the provider with the `us-west-2` region.
@ -175,7 +175,7 @@ module "aws_vpc" {
```
Modules have some special requirements when passing in providers; see
[The Module `providers` Meta-Argument](/terraform/language/meta-arguments/module-providers)
[The Module `providers` Meta-Argument](/opentf/language/meta-arguments/module-providers)
for more details. In most cases, only _root modules_ should define provider
configurations, with all child modules obtaining their provider configurations
from their parents.
@ -188,11 +188,9 @@ from their parents.
The `version` meta-argument specifies a version constraint for a provider, and
works the same way as the `version` argument in a
[`required_providers` block](/terraform/language/providers/requirements). The version
[`required_providers` block](/opentf/language/providers/requirements). The version
constraint in a provider configuration is only used if `required_providers`
does not include one for that provider.
~**Warning:** The `version` argument in provider configurations is deprecated, and we will remove it in a future Terraform version.
In Terraform 0.13 and later, always declare provider version constraints in
[the `required_providers` block](/terraform/language/providers/requirements).
Always declare provider version constraints in
[the `required_providers` block](/opentf/language/providers/requirements).

71
website/docs/language/providers/index.mdx
View File

@ -1,28 +1,26 @@
---
page_title: Providers - Configuration Language
description: >-
An overview of how to install and use providers, Terraform plugins that
An overview of how to install and use providers, OpenTF plugins that
interact with services, cloud providers, and other APIs.
---
# Providers
> **Hands-on:** Try the [Perform CRUD Operations with Providers](/terraform/tutorials/configuration-language/provider-use?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) tutorial.
Terraform relies on plugins called providers to interact with cloud providers,
OpenTF relies on plugins called providers to interact with cloud providers,
SaaS providers, and other APIs.
Terraform configurations must declare which providers they require so that
Terraform can install and use them. Additionally, some providers require
OpenTF configurations must declare which providers they require so that
OpenTF can install and use them. Additionally, some providers require
configuration (like endpoint URLs or cloud regions) before they can be used.
## What Providers Do
Each provider adds a set of [resource types](/terraform/language/resources)
and/or [data sources](/terraform/language/data-sources) that Terraform can
Each provider adds a set of [resource types](/opentf/language/resources)
and/or [data sources](/opentf/language/data-sources) that OpenTF can
manage.
Every resource type is implemented by a provider; without providers, Terraform
Every resource type is implemented by a provider; without providers, OpenTF
can't manage any kind of infrastructure.
Most providers configure a specific infrastructure platform (either cloud or
@ -31,11 +29,11 @@ generating random numbers for unique resource names.
## Where Providers Come From
Providers are distributed separately from Terraform itself, and each provider
Providers are distributed separately from OpenTF itself, and each provider
has its own release cadence and version numbers.
The [Terraform Registry](https://registry.terraform.io/browse/providers)
is the main directory of publicly available Terraform providers, and hosts
The [Public Terraform Registry](https://registry.terraform.io/browse/providers)
is the main directory of publicly available providers, and hosts
providers for most major infrastructure platforms.
## Provider Documentation
@ -43,60 +41,58 @@ providers for most major infrastructure platforms.
Each provider has its own documentation, describing its resource
types and their arguments.
The [Terraform Registry](https://registry.terraform.io/browse/providers)
includes documentation for a wide range of providers developed by HashiCorp, third-party vendors, and our Terraform community. Use the
The [Public Terraform Registry](https://registry.terraform.io/browse/providers)
includes documentation for a wide range of providers developed by HashiCorp, third-party vendors, and our OpenTF community. Use the
"Documentation" link in a provider's header to browse its documentation.
Provider documentation in the Registry is versioned; you can use the version
menu in the header to change which version you're viewing.
For details about writing, generating, and previewing provider documentation,
see the [provider publishing documentation](/terraform/registry/providers/docs).
see the [provider publishing documentation](/opentf/registry/providers/docs).
## How to Use Providers
Providers are released separately from Terraform itself and have their own version numbers. In production we recommend constraining the acceptable provider versions in the configuration's provider requirements block, to make sure that `terraform init` does not install newer versions of the provider that are incompatible with the configuration.
Providers are released separately from OpenTF itself and have their own version numbers. In production we recommend constraining the acceptable provider versions in the configuration's provider requirements block, to make sure that `opentf init` does not install newer versions of the provider that are incompatible with the configuration.
To use resources from a given provider, you need to include some information
about it in your configuration. See the following pages for details:
- [Provider Requirements](/terraform/language/providers/requirements)
documents how to declare providers so Terraform can install them.
- [Provider Requirements](/opentf/language/providers/requirements)
documents how to declare providers so OpenTF can install them.
- [Provider Configuration](/terraform/language/providers/configuration)
- [Provider Configuration](/opentf/language/providers/configuration)
documents how to configure settings for providers.
- [Dependency Lock File](/terraform/language/files/dependency-lock)
- [Dependency Lock File](/opentf/language/files/dependency-lock)
documents an additional HCL file that can be included with a configuration,
which tells Terraform to always use a specific set of provider versions.
which tells OpenTF to always use a specific set of provider versions.
## Provider Installation
- Terraform Cloud and Terraform Enterprise install providers as part of every run.
- TACOS (TF Automation and Collaboration Software) install providers as part of every run.
- Terraform CLI finds and installs providers when
[initializing a working directory](/terraform/cli/init). It can
automatically download providers from a Terraform registry, or load them from
- OpenTF CLI finds and installs providers when
[initializing a working directory](/opentf/cli/init). It can
automatically download providers from a provider registry, or load them from
a local mirror or cache. If you are using a persistent working directory, you
must reinitialize whenever you change a configuration's providers.
To save time and bandwidth, Terraform CLI supports an optional plugin
To save time and bandwidth, OpenTF CLI supports an optional plugin
cache. You can enable the cache using the `plugin_cache_dir` setting in
[the CLI configuration file](/terraform/cli/config/config-file).
[the CLI configuration file](/opentf/cli/config/config-file).
To ensure Terraform always installs the same provider versions for a given
configuration, you can use Terraform CLI to create a
[dependency lock file](/terraform/language/files/dependency-lock)
To ensure OpenTF always installs the same provider versions for a given
configuration, you can use OpenTF CLI to create a
[dependency lock file](/opentf/language/files/dependency-lock)
and commit it to version control along with your configuration. If a lock file
is present, Terraform Cloud, CLI, and Enterprise will all obey it when
is present, OpenTF CLI, and TACOS (TF Automation and Collaboration Software) will all obey it when
installing providers.
> **Hands-on:** Try the [Lock and Upgrade Provider Versions](/terraform/tutorials/configuration-language/provider-versioning?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) tutorial.
## How to Find Providers
To find providers for the infrastructure platforms you use, browse
[the providers section of the Terraform Registry](https://registry.terraform.io/browse/providers).
To find providers for the infrastructure platforms you use, browse the
[Public Terraform Registry](https://registry.terraform.io/browse/providers).
Some providers on the Registry are developed and published by HashiCorp, some
are published by platform maintainers, and some are published by users and
@ -109,7 +105,4 @@ develops and maintains a given provider.
## How to Develop Providers
Providers are written in Go, using the Terraform Plugin SDK. For more
information on developing providers, see:
- The [Plugin Development](/terraform/plugin) documentation
- The [Call APIs with Terraform Providers](/terraform/tutorials/providers-plugin-framework?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) tutorials
information on developing providers, see the [Plugin Development](/opentf/plugin) documentation.

196
website/docs/language/providers/requirements.mdx
View File

@ -1,32 +1,26 @@
---
page_title: Provider Requirements - Configuration Language
description: >-
Providers are plugins that allow Terraform to interact with services, cloud
Providers are plugins that allow OpenTF to interact with services, cloud
providers, and other APIs. Learn how to declare providers in a configuration.
---
# Provider Requirements
Terraform relies on plugins called "providers" to interact with remote systems.
Terraform configurations must declare which providers they require, so that
Terraform can install and use them. This page documents how to declare providers
so Terraform can install them.
> **Hands-on:** Try the [Perform CRUD Operations with Providers](/terraform/tutorials/providers/provider-use) tutorial.
OpenTF relies on plugins called "providers" to interact with remote systems.
OpenTF configurations must declare which providers they require, so that
OpenTF can install and use them. This page documents how to declare providers
so OpenTF can install them.
Additionally, some providers require configuration (like endpoint URLs or cloud
regions) before they can be used. The [Provider
Configuration](/terraform/language/providers/configuration) page documents how
Configuration](/opentf/language/providers/configuration) page documents how
to configure settings for providers.
-> **Note:** This page is about a feature of Terraform 0.13 and later; it also
describes how to use the more limited version of that feature that was available
in Terraform 0.12.
## Requiring Providers
Each Terraform module must declare which providers it requires, so that
Terraform can install and use them. Provider requirements are declared in a
Each module must declare which providers it requires, so that
OpenTF can install and use them. Provider requirements are declared in a
`required_providers` block.
A provider requirement consists of a local name, a source location, and a
@ -44,7 +38,7 @@ terraform {
```
The `required_providers` block must be nested inside the top-level
[`terraform` block](/terraform/language/settings) (which can also contain other settings).
[`terraform` block](/opentf/language/settings) (which can also contain other settings).
Each argument in the `required_providers` block enables one provider. The key
determines the provider's [local name](#local-names) (its unique identifier
@ -56,32 +50,22 @@ within this module), and the value is an object with the following elements:
* `version` - a [version constraint](#version-constraints) specifying
which subset of available provider versions the module is compatible with.
-> **Note:** The `name = { source, version }` syntax for `required_providers`
was added in Terraform v0.13. Previous versions of Terraform used a version
constraint string instead of an object (like `mycloud = "~> 1.0"`), and had no
way to specify provider source addresses. If you want to write a module that
works with both Terraform v0.12 and v0.13, see [v0.12-Compatible Provider
Requirements](#v0-12-compatible-provider-requirements) below.
## Names and Addresses
Each provider has two identifiers:
* A unique _source address,_ which is only used when requiring a provider.
* A _local name,_ which is used everywhere else in a Terraform module.
-> **Note:** Prior to Terraform 0.13, providers only had local names, since
Terraform could only automatically download providers distributed by HashiCorp.
* A _local name,_ which is used everywhere else in a module.
### Local Names
Local names are module-specific, and are assigned when requiring a provider.
Local names must be unique per-module.
Outside of the `required_providers` block, Terraform configurations always refer
Outside of the `required_providers` block, OpenTF configurations always refer
to providers by their local names. For example, the following configuration
declares `mycloud` as the local name for `mycorp/mycloud`, then uses that local
name when [configuring the provider](/terraform/language/providers/configuration):
name when [configuring the provider](/opentf/language/providers/configuration):
```hcl
terraform {
@ -106,28 +90,26 @@ resource types. (For example, resources from `hashicorp/aws` all begin with
Whenever possible, you should use a provider's preferred local name. This makes
your configurations easier to understand, and lets you omit the `provider`
meta-argument from most of your resources. (If a resource doesn't specify which
provider configuration to use, Terraform interprets the first word of the
provider configuration to use, OpenTF interprets the first word of the
resource type as a local provider name.)
### Source Addresses
A provider's source address is its global identifier. It also specifies the
primary location where Terraform can download it.
primary location where OpenTF can download it.
Source addresses consist of three parts delimited by slashes (`/`), as
follows:
`[<HOSTNAME>/]<NAMESPACE>/<TYPE>`
* **Hostname** (optional): The hostname of the Terraform registry that
* **Hostname** (optional): The hostname of the registry that
distributes the provider. If omitted, this defaults to
`registry.terraform.io`, the hostname of
[the public Terraform Registry](https://registry.terraform.io/).
`registry.terraform.io`.
* **Namespace:** An organizational namespace within the specified registry.
For the public Terraform Registry and for Terraform Cloud's private registry,
this represents the organization that publishes the provider. This field
may have other meanings for other registry hosts.
In most cases this represents the organization that publishes the provider.
This field may have other meanings for other registry hosts.
* **Type:** A short name for the platform or system the provider manages. Must
be unique within a particular namespace on a particular registry host.
@ -152,10 +134,9 @@ public registry, so you may see the shortened version `"hashicorp/random"` inste
of `"registry.terraform.io/hashicorp/random"`.
-> **Note:** If you omit the `source` argument when requiring a provider,
Terraform uses an implied source address of
`registry.terraform.io/hashicorp/<LOCAL NAME>`. This is a backward compatibility
feature to support the transition to Terraform 0.13; in modules that require
0.13 or later, we recommend using explicit source addresses for all providers.
OpenTF uses an implied source address of
`registry.terraform.io/hashicorp/<LOCAL NAME>`.
We recommend using explicit source addresses for all providers.
### Handling Local Name Conflicts
@ -164,7 +145,7 @@ is usually the same as the "type" portion of its source address.
However, it's sometimes necessary to use two providers with the same preferred
local name in the same module, usually when the providers are named after a
generic infrastructure type. Terraform requires unique local names for each
generic infrastructure type. OpenTF requires unique local names for each
provider in a module, so you'll need to use a non-preferred name for at least
one of them.
@ -200,7 +181,7 @@ data "http" "example" {
}
```
Terraform won't be able to guess either provider's name from its resource types,
OpenTF won't be able to guess either provider's name from its resource types,
so you'll need to specify a `provider` meta-argument for every affected
resource. However, readers and maintainers of your module will be able to easily
understand what's happening, and avoiding confusion is much more important than
@ -210,23 +191,21 @@ avoiding typing.
Each provider plugin has its own set of available versions, allowing the
functionality of the provider to evolve over time. Each provider dependency you
declare should have a [version constraint](/terraform/language/expressions/version-constraints) given in
the `version` argument so Terraform can select a single version per provider
declare should have a [version constraint](/opentf/language/expressions/version-constraints) given in
the `version` argument so OpenTF can select a single version per provider
that all modules are compatible with.
The `version` argument is optional; if omitted, Terraform will accept any
The `version` argument is optional; if omitted, OpenTF will accept any
version of the provider as compatible. However, we strongly recommend specifying
a version constraint for every provider your module depends on.
To ensure Terraform always installs the same provider versions for a given
configuration, you can use Terraform CLI to create a
[dependency lock file](/terraform/language/files/dependency-lock)
To ensure OpenTF always installs the same provider versions for a given
configuration, you can use OpenTF CLI to create a
[dependency lock file](/opentf/language/files/dependency-lock)
and commit it to version control along with your configuration. If a lock file
is present, Terraform Cloud, CLI, and Enterprise will all obey it when
is present, OpenTF CLI, and TACOS (TF Automation and Collaboration Software) will all obey it when
installing providers.
> **Hands-on:** Try the [Lock and Upgrade Provider Versions](/terraform/tutorials/configuration-language/provider-versioning) tutorial.
### Best Practices for Provider Versions
Each module should at least declare the minimum provider version it is known
@ -244,7 +223,7 @@ terraform {
```
A module intended to be used as the root of a configuration — that is, as the
directory where you'd run `terraform apply` — should also specify the
directory where you'd run `opentf apply` — should also specify the
_maximum_ provider version it is intended to work with, to avoid accidental
upgrades to incompatible new versions. The `~>` operator is a convenient
shorthand for allowing the rightmost component of a version to increment. The
@ -271,41 +250,38 @@ incompatibilities, and let the root module manage the maximum version.
## Built-in Providers
Most Terraform providers are distributed separately as plugins, but there
is one provider that is built into Terraform itself. This provider enables the
[the `terraform_remote_state` data source](/terraform/language/state/remote-state-data).
Most providers are distributed separately as plugins, but there
is one provider that is built into OpenTF itself. This provider enables the
[the `terraform_remote_state` data source](/opentf/language/state/remote-state-data).
Because this provider is built in to Terraform, you don't need to declare it
Because this provider is built in to OpenTF, you don't need to declare it
in the `required_providers` block in order to use its features. However, for
consistency it _does_ have a special provider source address, which is
`terraform.io/builtin/terraform`. This address may sometimes appear in
Terraform's error messages and other output in order to unambiguously refer
OpenTF's error messages and other output in order to unambiguously refer
to the built-in provider, as opposed to a hypothetical third-party provider
with the type name "terraform".
with the type name "opentf".
There is also an existing provider with the source address
`hashicorp/terraform`, which is an older version of the now-built-in provider
that was used by older versions of Terraform. `hashicorp/terraform` is not
compatible with Terraform v0.11 or later and should never be declared in a
`hashicorp/terraform`, which is an older version of the now-built-in provider.
`hashicorp/terraform` is not compatible with OpenTF and should never be declared in a
`required_providers` block.
## In-house Providers
Anyone can develop and distribute their own Terraform providers. See
the [Call APIs with Terraform Providers](/terraform/tutorials/providers)
tutorials for more about provider development.
Anyone can develop and distribute their own providers.
Some organizations develop their own providers to configure
proprietary systems, and wish to use these providers from Terraform without
publishing them on the public Terraform Registry.
proprietary systems, and wish to use these providers from OpenTF without
publishing them on a registry.
One option for distributing such a provider is to run an in-house _private_
registry, by implementing
[the provider registry protocol](/terraform/internals/provider-registry-protocol).
[the provider registry protocol](/opentf/internals/provider-registry-protocol).
Running an additional service just to distribute a single provider internally
may be undesirable, so Terraform also supports
[other provider installation methods](/terraform/cli/config/config-file#provider-installation),
may be undesirable, so OpenTF also supports
[other provider installation methods](/opentf/cli/config/config-file#provider-installation),
including placing provider plugins directly in specific directories in the
local filesystem, via _filesystem mirrors_.
@ -316,16 +292,16 @@ distribute from a local filesystem directory, you can use an arbitrary hostname
in a domain your organization controls.
For example, if your corporate domain were `example.com` then you might choose
to use `terraform.example.com` as your placeholder hostname, even if that
to use `opentf.example.com` as your placeholder hostname, even if that
hostname doesn't actually resolve in DNS. You can then choose any namespace and
type you wish to represent your in-house provider under that hostname, giving
a source address like `terraform.example.com/examplecorp/ourcloud`:
a source address like `opentf.example.com/examplecorp/ourcloud`:
```hcl
terraform {
required_providers {
mycloud = {
source = "terraform.example.com/examplecorp/ourcloud"
source = "opentf.example.com/examplecorp/ourcloud"
version = ">= 1.0"
}
}
@ -334,15 +310,15 @@ terraform {
To make version 1.0.0 of this provider available for installation from the
local filesystem, choose one of the
[implied local mirror directories](/terraform/cli/config/config-file#implied-local-mirror-directories)
[implied local mirror directories](/opentf/cli/config/config-file#implied-local-mirror-directories)
and create a directory structure under it like this:
```
terraform.example.com/examplecorp/ourcloud/1.0.0
opentf.example.com/examplecorp/ourcloud/1.0.0
```
Under that `1.0.0` directory, create one additional directory representing the
platform where you are running Terraform, such as `linux_amd64` for Linux on
platform where you are running OpenTF, such as `linux_amd64` for Linux on
an AMD64/x64 processor, and then place the provider plugin executable and any
other needed files in that directory.
@ -350,77 +326,11 @@ Thus, on a Windows system, the provider plugin executable file might be at the
following path:
```
terraform.example.com/examplecorp/ourcloud/1.0.0/windows_amd64/terraform-provider-ourcloud.exe
opentf.example.com/examplecorp/ourcloud/1.0.0/windows_amd64/opentf-provider-ourcloud.exe
```
If you later decide to switch to using a real private provider registry rather
than distribute binaries out of band, you can deploy the registry server at
`terraform.example.com` and retain the same namespace and type names, in which
`opentf.example.com` and retain the same namespace and type names, in which
case your existing modules will require no changes to locate the same provider
using your registry server.
## v0.12-Compatible Provider Requirements
Explicit provider source addresses were introduced with Terraform v0.13, so the
full provider requirements syntax is not supported by Terraform v0.12.
However, in order to allow writing modules that are compatible with both
Terraform v0.12 and v0.13, versions of Terraform between v0.12.26 and v0.13
will accept but ignore the `source` argument in a `required_providers` block.
Consider the following example written for Terraform v0.13:
```hcl
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 1.0"
}
}
}
```
Terraform v0.12.26 will accept syntax like the above but will understand it
in the same way as the following v0.12-style syntax:
```hcl
terraform {
required_providers {
aws = "~> 1.0"
}
}
```
In other words, Terraform v0.12.26 ignores the `source` argument and considers
only the `version` argument, using the given [local name](#local-names) as the
un-namespaced provider type to install.
When writing a module that is compatible with both Terraform v0.12.26 and
Terraform v0.13.0 or later, you must follow the following additional rules so
that both versions will select the same provider to install:
* Use only providers that can be automatically installed by Terraform v0.12.
Third-party providers, such as community providers in the Terraform Registry,
cannot be selected by Terraform v0.12 because it does not support the
hierarchical source address namespace.
* Ensure that your chosen local name exactly matches the "type" portion of the
source address given in the `source` argument, such as both being "aws" in
the examples above, because Terraform v0.12 will use the local name to
determine which provider plugin to download and install.
* If the provider belongs to the `hashicorp` namespace, as with the
`hashicorp/aws` provider shown above, omit the `source` argument and allow
Terraform v0.13 to select the `hashicorp` namespace by default.
* Provider type names must always be written in lowercase. Terraform v0.13
treats provider source addresses as case-insensitive, but Terraform v0.12
considers its legacy-style provider names to be case-sensitive. Using
lowercase will ensure that the name is selectable by both Terraform major
versions.
This compatibility mechanism is provided as a temporary transitional aid only.
When Terraform v0.12 detects a use of the new `source` argument it doesn't
understand, it will emit a warning to alert the user that it is disregarding
the source address given in that argument.