diff --git a/website/docs/backends/state.html.md b/website/docs/backends/state.html.md index 78f1c68af..0f40c757c 100644 --- a/website/docs/backends/state.html.md +++ b/website/docs/backends/state.html.md @@ -66,7 +66,7 @@ prior to forcing the overwrite. Backends are responsible for supporting [state locking](/docs/state/locking.html) if possible. Not all backend types support state locking. In the -[list of supported backend types](/docs/backends/types) we explicitly note +[list of supported backend types](/docs/backends/types/index.html) we explicitly note whether locking is supported. For more information on state locking, view the diff --git a/website/docs/commands/0.13upgrade.html.markdown b/website/docs/commands/0.13upgrade.html.markdown index 9340ebb40..28d948155 100644 --- a/website/docs/commands/0.13upgrade.html.markdown +++ b/website/docs/commands/0.13upgrade.html.markdown @@ -23,7 +23,7 @@ providers are in use for a module, detect the source address for those providers where possible, and record this information in a [`required_providers` block][required-providers]. -[required-providers]: /docs/configuration/terraform.html#specifying-required-provider-versions +[required-providers]: /docs/configuration/provider-requirements.html ~> Note: the command ignores `.tf.json` files and override files in the module. diff --git a/website/docs/commands/apply.html.markdown b/website/docs/commands/apply.html.markdown index ffcdc135e..fe15702fc 100644 --- a/website/docs/commands/apply.html.markdown +++ b/website/docs/commands/apply.html.markdown @@ -72,11 +72,11 @@ The command-line flags are all optional. The list of available flags are: * `-var 'foo=bar'` - Set a variable in the Terraform configuration. This flag can be set multiple times. Variable values are interpreted as - [HCL](/docs/configuration/syntax.html#HCL), so list and map values can be - specified via this flag. + [literal expressions](/docs/configuration/expressions/types.html) in the + Terraform language, so list and map values can be specified via this flag. * `-var-file=foo` - Set variables in the Terraform configuration from - a [variable file](/docs/configuration/variables.html#variable-files). If + a [variable file](/docs/configuration/variables.html#variable-definitions-tfvars-files). If a `terraform.tfvars` or any `.auto.tfvars` files are present in the current directory, they will be automatically loaded. `terraform.tfvars` is loaded first and the `.auto.tfvars` files after in alphabetical order. Any files @@ -92,7 +92,7 @@ that directory as the root module instead of the current working directory. That usage is still supported in Terraform v0.14, but is now deprecated and we plan to remove it in Terraform v0.15. If your workflow relies on overriding the root module directory, use -[the `-chdir` global option](./#switching-working-directory-with--chdir) +[the `-chdir` global option](./#switching-working-directory-with-chdir) instead, which works across all commands and makes Terraform consistently look in the given directory for all files it would normaly read or write in the current working directory. @@ -100,6 +100,6 @@ current working directory. If your previous use of this legacy pattern was also relying on Terraform writing the `.terraform` subdirectory into the current working directory even though the root module directory was overridden, use -[the `TF_DATA_DIR` environment variable](environment-variables.html#TF_DATA_DIR) +[the `TF_DATA_DIR` environment variable](environment-variables.html#tf_data_dir) to direct Terraform to write the `.terraform` directory to a location other than the current working directory. diff --git a/website/docs/commands/import.html.md b/website/docs/commands/import.html.md index 7e7118473..5a8e1b72f 100644 --- a/website/docs/commands/import.html.md +++ b/website/docs/commands/import.html.md @@ -75,11 +75,12 @@ in the configuration for the target resource, and that is the best behavior in m * `-var 'foo=bar'` - Set a variable in the Terraform configuration. This flag can be set multiple times. Variable values are interpreted as - [HCL](/docs/configuration/syntax.html#HCL), so list and map values can be - specified via this flag. This is only useful with the `-config` flag. + [literal expressions](/docs/configuration/expressions/types.html) in the + Terraform language, so list and map values can be specified via this flag. + This is only useful with the `-config` flag. * `-var-file=foo` - Set variables in the Terraform configuration from - a [variable file](/docs/configuration/variables.html#variable-files). If + a [variable file](/docs/configuration/variables.html#variable-definitions-tfvars-files). If a `terraform.tfvars` or any `.auto.tfvars` files are present in the current directory, they will be automatically loaded. `terraform.tfvars` is loaded first and the `.auto.tfvars` files after in alphabetical order. Any files diff --git a/website/docs/commands/init.html.markdown b/website/docs/commands/init.html.markdown index 70f9d8aef..c46b5e989 100644 --- a/website/docs/commands/init.html.markdown +++ b/website/docs/commands/init.html.markdown @@ -142,10 +142,12 @@ You can modify `terraform init`'s plugin behavior with the following options: cause Terraform to ignore any selections recorded in the dependency lock file, and to take the newest available version matching the configured version constraints. -- `-get-plugins=false` — Skip plugin installation. _Note: Since Terraform 0.13, this - command has been superseded by [`provider_installation`](./cli-config.html#provider-installation) - blocks or using the [`plugin_cache_dir`](./cli-config.html#plugin_cache_dir) setting. - It should not be used in Terraform versions 0.13+. +- `-get-plugins=false` — Skip plugin installation. + + -> Note: Since Terraform 0.13, this option has been superseded by the + [`provider_installation`](./cli-config.html#provider-installation) and + [`plugin_cache_dir`](./cli-config.html#plugin_cache_dir) settings. + It should not be used in Terraform versions 0.13+. - `-plugin-dir=PATH` — Force plugin installation to read plugins _only_ from the specified directory, as if it had been configured as a `filesystem_mirror` in the CLI configuration. If you intend to routinely use a particular @@ -176,7 +178,7 @@ that directory as the root module instead of the current working directory. That usage is still supported in Terraform v0.14, but is now deprecated and we plan to remove it in Terraform v0.15. If your workflow relies on overriding the root module directory, use -[the `-chdir` global option](./#switching-working-directory-with--chdir) +[the `-chdir` global option](./#switching-working-directory-with-chdir) instead, which works across all commands and makes Terraform consistently look in the given directory for all files it would normaly read or write in the current working directory. @@ -184,6 +186,6 @@ current working directory. If your previous use of this legacy pattern was also relying on Terraform writing the `.terraform` subdirectory into the current working directory even though the root module directory was overridden, use -[the `TF_DATA_DIR` environment variable](environment-variables.html#TF_DATA_DIR) +[the `TF_DATA_DIR` environment variable](environment-variables.html#tf_data_dir) to direct Terraform to write the `.terraform` directory to a location other than the current working directory. diff --git a/website/docs/commands/plan.html.markdown b/website/docs/commands/plan.html.markdown index c6a1703d4..8f7f9ebe7 100644 --- a/website/docs/commands/plan.html.markdown +++ b/website/docs/commands/plan.html.markdown @@ -76,13 +76,13 @@ The available options are: Address](/docs/internals/resource-addressing.html) to target. This flag can be used multiple times. See below for more information. -* `-var=foo=bar` - Set a variable in the Terraform configuration. This flag +* `-var 'foo=bar'` - Set a variable in the Terraform configuration. This flag can be set multiple times. Variable values are interpreted as - [HCL](/docs/configuration/syntax.html#HCL), so list and map values can be - specified via this flag. + [literal expressions](/docs/configuration/expressions/types.html) in the + Terraform language, so list and map values can be specified via this flag. * `-var-file=foo` - Set variables in the Terraform configuration from - a [variable file](/docs/configuration/variables.html#variable-files). If + a [variable file](/docs/configuration/variables.html#variable-definitions-tfvars-files). If a `terraform.tfvars` or any `.auto.tfvars` files are present in the current directory, they will be automatically loaded. `terraform.tfvars` is loaded first and the `.auto.tfvars` files after in alphabetical order. Any files @@ -142,7 +142,7 @@ module instead of the current working directory. That usage is still supported in Terraform v0.14, but is now deprecated and we plan to remove it in Terraform v0.15. If your workflow relies on overriding the root module directory, use -[the `-chdir` global option](./#switching-working-directory-with--chdir) +[the `-chdir` global option](./#switching-working-directory-with-chdir) instead, which works across all commands and makes Terraform consistently look in the given directory for all files it would normaly read or write in the current working directory. @@ -150,6 +150,6 @@ current working directory. If your previous use of this legacy pattern was also relying on Terraform writing the `.terraform` subdirectory into the current working directory even though the root module directory was overridden, use -[the `TF_DATA_DIR` environment variable](environment-variables.html#TF_DATA_DIR) +[the `TF_DATA_DIR` environment variable](environment-variables.html#tf_data_dir) to direct Terraform to write the `.terraform` directory to a location other than the current working directory. diff --git a/website/docs/commands/refresh.html.markdown b/website/docs/commands/refresh.html.markdown index 6506cc96a..d8f44c8d7 100644 --- a/website/docs/commands/refresh.html.markdown +++ b/website/docs/commands/refresh.html.markdown @@ -56,11 +56,11 @@ The `terraform refresh` command accepts the following options: * `-var 'foo=bar'` - Set a variable in the Terraform configuration. This flag can be set multiple times. Variable values are interpreted as - [HCL](/docs/configuration/syntax.html#HCL), so list and map values can be - specified via this flag. + [literal expressions](/docs/configuration/expressions/types.html) in the + Terraform language, so list and map values can be specified via this flag. * `-var-file=foo` - Set variables in the Terraform configuration from - a [variable file](/docs/configuration/variables.html#variable-files). If + a [variable file](/docs/configuration/variables.html#variable-definitions-tfvars-files). If a `terraform.tfvars` or any `.auto.tfvars` files are present in the current directory, they will be automatically loaded. `terraform.tfvars` is loaded first and the `.auto.tfvars` files after in alphabetical order. Any files diff --git a/website/docs/commands/state/push.html.md b/website/docs/commands/state/push.html.md index 0d4258490..bbd295d60 100644 --- a/website/docs/commands/state/push.html.md +++ b/website/docs/commands/state/push.html.md @@ -20,7 +20,7 @@ manual intervention is necessary with the remote state. Usage: `terraform state push [options] PATH` This command will push the state specified by PATH to the currently -configured [backend](/docs/backends). +configured [backend](/docs/configuration/blocks/backends/index.html). If PATH is "-" then the state data to push is read from stdin. This data is loaded completely into memory and verified prior to being written to diff --git a/website/docs/configuration-0-11/interpolation.html.md b/website/docs/configuration-0-11/interpolation.html.md index 80102490a..aac18e5af 100644 --- a/website/docs/configuration-0-11/interpolation.html.md +++ b/website/docs/configuration-0-11/interpolation.html.md @@ -409,7 +409,7 @@ The supported built-in functions are: * `timestamp()` - Returns a UTC timestamp string in RFC 3339 format. This string will change with every invocation of the function, so in order to prevent diffs on every plan & apply, it must be used with the - [`ignore_changes`](./resources.html#ignore-changes) lifecycle attribute. + [`ignore_changes`](./resources.html#ignore_changes) lifecycle attribute. * `timeadd(time, duration)` - Returns a UTC timestamp string corresponding to adding a given `duration` to `time` in RFC 3339 format. For example, `timeadd("2017-11-22T00:00:00Z", "10m")` produces a value `"2017-11-22T00:10:00Z"`. @@ -424,7 +424,7 @@ The supported built-in functions are: * `urlencode(string)` - Returns an URL-safe copy of the string. - * `uuid()` - Returns a random UUID string. This string will change with every invocation of the function, so in order to prevent diffs on every plan & apply, it must be used with the [`ignore_changes`](./resources.html#ignore-changes) lifecycle attribute. + * `uuid()` - Returns a random UUID string. This string will change with every invocation of the function, so in order to prevent diffs on every plan & apply, it must be used with the [`ignore_changes`](./resources.html#ignore_changes) lifecycle attribute. * `values(map)` - Returns a list of the map values, in the order of the keys returned by the `keys` function. This function only works on flat maps and diff --git a/website/docs/configuration-0-11/modules.html.md b/website/docs/configuration-0-11/modules.html.md index abe8440d9..180f88571 100644 --- a/website/docs/configuration-0-11/modules.html.md +++ b/website/docs/configuration-0-11/modules.html.md @@ -233,7 +233,7 @@ resource "aws_s3_bucket" "example" { This approach is recommended in the common case where only a single configuration is needed for each provider across the entire configuration. -In more complex situations there may be [multiple provider instances](/docs/configuration/providers.html#multiple-provider-instances), +In more complex situations there may be [multiple provider instances](./providers.html#multiple-provider-instances), or a child module may need to use different provider settings than its parent. For such situations, it's necessary to pass providers explicitly as we will see in the next section. @@ -272,7 +272,7 @@ module "example" { The `providers` argument within a `module` block is similar to the `provider` argument within a resource as described for -[multiple provider instances](/docs/configuration/providers.html#multiple-provider-instances), +[multiple provider instances](./providers.html#multiple-provider-instances), but is a map rather than a single string because a module may contain resources from many different providers. diff --git a/website/docs/configuration-0-11/providers.html.md b/website/docs/configuration-0-11/providers.html.md index fcff5142e..5fbcecbec 100644 --- a/website/docs/configuration-0-11/providers.html.md +++ b/website/docs/configuration-0-11/providers.html.md @@ -220,7 +220,7 @@ may also be used, but currently may cause errors when running `terraform destroy ## Third-party Plugins Anyone can develop and distribute their own Terraform providers. (See -[Writing Custom Providers](/docs/extend/writing-custom-providers.html) for more +[Writing Custom Providers](https://learn.hashicorp.com/collections/terraform/providers?utm_source=WEBSITE/docs/extend/writing-custom-providers.htmlutm_medium=WEB_IO/docs/extend/writing-custom-providers.htmlutm_offer=ARTICLE_PAGE/docs/extend/writing-custom-providers.htmlutm_content=DOCS) for more about provider development.) These third-party providers must be manually installed, since `terraform init` cannot automatically download them. diff --git a/website/docs/configuration-0-11/variables.html.md b/website/docs/configuration-0-11/variables.html.md index aa74c062a..cc2f4aa86 100644 --- a/website/docs/configuration-0-11/variables.html.md +++ b/website/docs/configuration-0-11/variables.html.md @@ -211,7 +211,7 @@ $ TF_VAR_image=foo terraform apply ``` Maps and lists can be specified using environment variables as well using -[HCL](./syntax.html#HCL) syntax in the value. +[HCL](./syntax.html) syntax in the value. For a list variable like so: diff --git a/website/docs/configuration/meta-arguments/resource-provider.html.md b/website/docs/configuration/meta-arguments/resource-provider.html.md index 37a84e8d6..7fa434c93 100644 --- a/website/docs/configuration/meta-arguments/resource-provider.html.md +++ b/website/docs/configuration/meta-arguments/resource-provider.html.md @@ -51,7 +51,7 @@ ensure that the provider is fully configured before any resource actions are taken. The `provider` meta-argument expects -[a `.` reference](/docs/configuration/providers.html#referring-to-alternate-providers), +[a `.` reference](/docs/configuration/providers.html#referring-to-alternate-provider-configurations), which does not need to be quoted. Arbitrary expressions are not permitted for `provider` because it must be resolved while Terraform is constructing the dependency graph, before it is safe to evaluate expressions. diff --git a/website/docs/configuration/outputs.html.md b/website/docs/configuration/outputs.html.md index 718671f07..59a8732c4 100644 --- a/website/docs/configuration/outputs.html.md +++ b/website/docs/configuration/outputs.html.md @@ -66,6 +66,8 @@ value as `module.web_server.instance_ip_addr`. `output` blocks can optionally include `description`, `sensitive`, and `depends_on` arguments, which are described in the following sections. + + ### `description` — Output Value Documentation Because the output values of a module are part of its user interface, you can @@ -85,6 +87,8 @@ string might be included in documentation about the module, and so it should be written from the perspective of the user of the module rather than its maintainer. For commentary for module maintainers, use comments. + + ### `sensitive` — Suppressing Values in CLI Output An output can be marked as containing sensitive material using the optional @@ -151,6 +155,8 @@ Sensitive output values are still recorded in the to access the state data. For more information, see [_Sensitive Data in State_](/docs/state/sensitive-data.html). + + ### `depends_on` — Explicit Output Dependencies Since output values are just a means for passing data out of a module, it is diff --git a/website/docs/configuration/providers.html.md b/website/docs/configuration/providers.html.md index 30a5c3cea..a6377a713 100644 --- a/website/docs/configuration/providers.html.md +++ b/website/docs/configuration/providers.html.md @@ -80,7 +80,7 @@ empty default configuration for any provider that is not explicitly configured. ## `alias`: Multiple Provider Configurations -[inpage-alias]: #alias-multiple-provider-instances +[inpage-alias]: #alias-multiple-provider-configurations You can optionally define multiple configurations for the same provider, and select which one to use on a per-resource or per-module basis. The primary diff --git a/website/docs/configuration/resources.html.md b/website/docs/configuration/resources.html.md index f4b767776..013b9c115 100644 --- a/website/docs/configuration/resources.html.md +++ b/website/docs/configuration/resources.html.md @@ -14,6 +14,7 @@ pages. + ## Syntax and Elements of Resource Blocks @@ -66,7 +67,9 @@ This information has moved to + + @@ -82,6 +85,8 @@ This information has moved to + + @@ -107,6 +112,9 @@ This information has moved to + + + ### `lifecycle` diff --git a/website/docs/configuration/variables.html.md b/website/docs/configuration/variables.html.md index 26ee510b0..c7d65b10e 100644 --- a/website/docs/configuration/variables.html.md +++ b/website/docs/configuration/variables.html.md @@ -349,6 +349,8 @@ terraform apply -var='image_id_map={"us-east-1":"ami-abc123","us-east-2":"ami-de The `-var` option can be used any number of times in a single command. + + ### Variable Definitions (`.tfvars`) Files To set lots of variables, it is more convenient to specify their values in diff --git a/website/docs/import/index.html.md b/website/docs/import/index.html.md index 4be535bba..5127e076c 100644 --- a/website/docs/import/index.html.md +++ b/website/docs/import/index.html.md @@ -31,7 +31,7 @@ behavior. For more information on this assumption, see ## Currently State Only The current implementation of Terraform import can only import resources -into the [state](/docs/state). It does not generate configuration. A future +into the [state](/docs/state/). It does not generate configuration. A future version of Terraform will also generate configuration. Because of this, prior to running `terraform import` it is necessary to write diff --git a/website/docs/internals/json-format.html.md b/website/docs/internals/json-format.html.md index 4c345220e..48a7b28e0 100644 --- a/website/docs/internals/json-format.html.md +++ b/website/docs/internals/json-format.html.md @@ -56,7 +56,7 @@ The extra wrapping object here will allow for any extension we may need to add i A plan consists of a prior state, the configuration that is being applied to that state, and the set of changes Terraform plans to make to achieve that. -For ease of consumption by callers, the plan representation includes a partial representation of the values in the final state (using a [value representation](#value-representation)), allowing callers to easily analyze the planned outcome using similar code as for analyzing the prior state. +For ease of consumption by callers, the plan representation includes a partial representation of the values in the final state (using a [value representation](#values-representation)), allowing callers to easily analyze the planned outcome using similar code as for analyzing the prior state. ```javascript { diff --git a/website/docs/internals/remote-service-discovery.html.md b/website/docs/internals/remote-service-discovery.html.md index 5a2ecb336..4ae3dfc8d 100644 --- a/website/docs/internals/remote-service-discovery.html.md +++ b/website/docs/internals/remote-service-discovery.html.md @@ -85,7 +85,7 @@ version 1 of the module registry protocol: At present, the following service identifiers are in use: -* `login.v1`: [login protocol version 1](/docs/commands/login.html#protocol-v1) +* `login.v1`: [login protocol version 1](/docs/commands/login.html) * `modules.v1`: [module registry API version 1](module-registry-protocol.html) * `providers.v1`: [provider registry API version 1](provider-registry-protocol.html) diff --git a/website/docs/modules/providers.html.md b/website/docs/modules/providers.html.md index dee5d7642..2578a03b1 100644 --- a/website/docs/modules/providers.html.md +++ b/website/docs/modules/providers.html.md @@ -80,7 +80,7 @@ however, specify any of the configuration settings that determine what remote endpoints the provider will access, such as an AWS region; configuration settings come from provider _configurations_, and a particular overall Terraform configuration can potentially have -[several different configurations for the same provider](/docs/configuration/providers.html#alias-multiple-provider-instances). +[several different configurations for the same provider](/docs/configuration/providers.html#alias-multiple-provider-configurations). If you are writing a shared Terraform module, constrain only the minimum required provider version using a `>=` constraint. This should specify the diff --git a/website/docs/plugins/basics.html.md b/website/docs/plugins/basics.html.md index 74960f404..16cdc4b4b 100644 --- a/website/docs/plugins/basics.html.md +++ b/website/docs/plugins/basics.html.md @@ -43,7 +43,6 @@ directory, located at `%APPDATA%\terraform.d\plugins` on Windows and For more information, see: - [Configuring Providers](/docs/configuration/providers.html) -- [Configuring Providers: Third-party Plugins](/docs/configuration/providers.html#third-party-plugins) For developer-centric documentation, see: diff --git a/website/docs/plugins/provider.html.md b/website/docs/plugins/provider.html.md index b19ef5441..9b5c04b6d 100644 --- a/website/docs/plugins/provider.html.md +++ b/website/docs/plugins/provider.html.md @@ -75,9 +75,8 @@ an official release. When constructing a new provider from scratch, it's recommended to follow a similar repository structure as for the existing providers, with the main package in the repository root and a library package in a subdirectory named -after the provider. For more information, see -[Writing Custom Providers](/docs/extend/writing-custom-providers.html) in the -[Extending Terraform section](/docs/extend/index.html). +after the provider. For more information, see the +[Call APIs with Terraform Providers](https://learn.hashicorp.com/collections/terraform/providers?utm_source=WEBSITE/docs/extend/writing-custom-providers.htmlutm_medium=WEB_IO/docs/extend/writing-custom-providers.htmlutm_offer=ARTICLE_PAGE/docs/extend/writing-custom-providers.htmlutm_content=DOCS) collection on HashiCorp Learn. When making changes only to files within the provider repository, it is _not_ necessary to re-build the main Terraform executable. Note that some packages diff --git a/website/docs/provisioners/index.html.markdown b/website/docs/provisioners/index.html.markdown index 6a9f266ba..d2d277fdf 100644 --- a/website/docs/provisioners/index.html.markdown +++ b/website/docs/provisioners/index.html.markdown @@ -166,8 +166,13 @@ You must include [a `connection` block](./connection.html) so that Terraform will know how to communicate with the server. Terraform includes several built-in provisioners; use the navigation sidebar to -view their documentation. You can also install third-party provisioners in -[the user plugins directory](../configuration/providers.html#third-party-plugins). +view their documentation. + +It's also possible to use third-party provisioners as plugins, by placing them +in `%APPDATA%\terraform.d\plugins`, `~/.terraform.d/plugins`, or the same +directory where the Terraform binary is installed. However, we do not recommend +using any provisioners except the built-in `file`, `local-exec`, and +`remote-exec` provisioners. All provisioners support the `when` and `on_failure` meta-arguments, which are described below (see [Destroy-Time Provisioners](#destroy-time-provisioners) diff --git a/website/docs/state/locking.html.md b/website/docs/state/locking.html.md index 49ed9fd3b..5431f7d34 100644 --- a/website/docs/state/locking.html.md +++ b/website/docs/state/locking.html.md @@ -8,7 +8,7 @@ description: |- # State Locking -If supported by your [backend](/docs/backends), Terraform will lock your +If supported by your [backend](/docs/backends/), Terraform will lock your state for all operations that could write state. This prevents others from acquiring the lock and potentially corrupting your state. @@ -21,8 +21,8 @@ If acquiring the lock is taking longer than expected, Terraform will output a status message. If Terraform doesn't output a message, state locking is still occurring if your backend supports it. -Not all [backends](/docs/backends) support locking. Please view the list -of [backend types](/docs/backends/types) for details on whether a backend +Not all [backends](/docs/backends/) support locking. Please view the list +of [backend types](/docs/backends/types/) for details on whether a backend supports locking or not. ## Force Unlock diff --git a/website/docs/state/remote.html.md b/website/docs/state/remote.html.md index 2aa47f002..743e630b6 100644 --- a/website/docs/state/remote.html.md +++ b/website/docs/state/remote.html.md @@ -19,7 +19,7 @@ which can then be shared between all members of a team. Terraform supports storing state in [Terraform Cloud](https://www.hashicorp.com/products/terraform/), [HashiCorp Consul](https://www.consul.io/), Amazon S3, Azure Blob Storage, Google Cloud Storage, Alibaba Cloud OSS, and more. -Remote state is a feature of [backends](/docs/backends), which you can activate +Remote state is a feature of [backends](/docs/backends/), which you can activate in your configuration's root module. ## Delegation and Teamwork diff --git a/website/docs/state/workspaces.html.md b/website/docs/state/workspaces.html.md index 358f8e6af..1bca724e1 100644 --- a/website/docs/state/workspaces.html.md +++ b/website/docs/state/workspaces.html.md @@ -195,7 +195,7 @@ control, although using a remote backend instead is recommended when there are multiple collaborators. For [remote state](/docs/state/remote.html), the workspaces are stored -directly in the configured [backend](/docs/backends). For example, if you +directly in the configured [backend](/docs/backends/). For example, if you use [Consul](/docs/backends/types/consul.html), the workspaces are stored by appending the workspace name to the state path. To ensure that workspace names are stored correctly and safely in all backends, the name diff --git a/website/guides/terraform-provider-development-program.html.md b/website/guides/terraform-provider-development-program.html.md index 9acba17a3..59d5ffc64 100644 --- a/website/guides/terraform-provider-development-program.html.md +++ b/website/guides/terraform-provider-development-program.html.md @@ -13,7 +13,7 @@ The Verified badge helps users easily identify and discover integrations develop ![Verified Provider Card](/assets/images/docs/verified-card.png) --> **Building your own provider?** If you're building your own provider and aren't interested in having HashiCorp officially verify and regularly monitor your provider, please refer to the [Writing Custom Providers guide](https://www.terraform.io/docs/extend/writing-custom-providers.html) and the [Extending Terraform](https://www.terraform.io/docs/extend/index.html) section. +-> **Building your own provider?** If you're building your own provider and aren't interested in having HashiCorp officially verify and regularly monitor your provider, please refer to the [Call APIs with Terraform Providers](https://learn.hashicorp.com/collections/terraform/providers?utm_source=WEBSITEhttps://www.terraform.io/docs/extend/writing-custom-providers.htmlutm_medium=WEB_IOhttps://www.terraform.io/docs/extend/writing-custom-providers.htmlutm_offer=ARTICLE_PAGEhttps://www.terraform.io/docs/extend/writing-custom-providers.htmlutm_content=DOCS) collection on HashiCorp Learn and the [Extending Terraform](https://www.terraform.io/docs/extend/index.html) section of the documentation. ## What is a Terraform Provider? @@ -66,7 +66,7 @@ The provider development process is divided into five steps below. By following ![Provider Development Process](/assets/images/docs/program-steps.png) 1. **Apply**: Initial contact between vendor and HashiCorp -2. **Prepare**: Follow documentation while developing the provider +2. **Prepare**: Follow documentation while developing the provider 3. **Verify**: Share public GPG key with HashiCorp 4. **Publish**: Release the provider on the Registry 5. **Support**: Ongoing maintenance and support of the provider by the vendor. @@ -112,7 +112,7 @@ We’ve found the provider development process to be fairly straightforward and ### 3. Verify -At this stage, it is expected that the provider is fully developed, all tests and documentation are in place, and your provider is ready for publishing. In this step, HashiCorp will verify the source and authenticity of the namespace being used to publish the provider by signing your GPG key with a trust signature. +At this stage, it is expected that the provider is fully developed, all tests and documentation are in place, and your provider is ready for publishing. In this step, HashiCorp will verify the source and authenticity of the namespace being used to publish the provider by signing your GPG key with a trust signature. -> **Important:** This step requires that you have signed and accepted our Technology Partner Agreement. If you have not received this, please see step #1 above. @@ -128,7 +128,7 @@ $ gpg --armor --export "{Key ID or email address}" Once the verification step is complete please follow the steps on [Publishing a Provider](https://www.terraform.io/docs/registry/providers/publishing.html). This step does not require additional involvement from HashiCorp as publishing is a fully self-service process in the [Terraform Registry](https://registry.terraform.io). -Once completed, your provider should be visible in the Terraform Registry and usable in Terraform. Please confirm that everything looks good, and that documentation is rendering properly. +Once completed, your provider should be visible in the Terraform Registry and usable in Terraform. Please confirm that everything looks good, and that documentation is rendering properly. ### 5. Maintain & Support diff --git a/website/upgrade-guides/0-10.html.markdown b/website/upgrade-guides/0-10.html.markdown index ba0295fe8..063e6e47c 100644 --- a/website/upgrade-guides/0-10.html.markdown +++ b/website/upgrade-guides/0-10.html.markdown @@ -60,9 +60,18 @@ eventually support a similar approach for third-party plugins, but we wish to ensure the robustness of the installation and versioning mechanisms before generalizing this feature. -In the mean time, -[the prior mechanisms for installing third-party providers](/docs/plugins/basics.html#installing-a-plugin) -are still supported. Maintainers of third-party providers may optionally +-> **Note:** As of Terraform 0.13, Terraform can automatically install +third-party providers released on the Terraform Registry. + +In the mean time, third-party providers can be installed by placing them in the +user plugins directory: + +Operating system | User plugins directory +------------------|----------------------- +Windows | `%APPDATA%\terraform.d\plugins` +All other systems | `~/.terraform.d/plugins` + +Maintainers of third-party providers may optionally make use of the new versioning mechanism by naming provider binaries using the scheme `terraform-provider-NAME_v0.0.1`, where "0.0.1" is an example version. Terraform expects providers to follow the diff --git a/website/upgrade-guides/0-13.html.markdown b/website/upgrade-guides/0-13.html.markdown index fd3740f81..59f28336f 100644 --- a/website/upgrade-guides/0-13.html.markdown +++ b/website/upgrade-guides/0-13.html.markdown @@ -44,7 +44,7 @@ Upgrade guide sections: * [New Filesystem Layout for Local Copies of Providers](#new-filesystem-layout-for-local-copies-of-providers) * [Special considerations for in-house providers](#in-house-providers) * [Destroy-time provisioners may not refer to other resources](#destroy-time-provisioners-may-not-refer-to-other-resources) -* [Data resource reads can no longer be disabled by `-refresh=false`](#data-resource-reads-can-no-longer-be-disabled-by--refresh-false) +* [Data resource reads can no longer be disabled by `-refresh=false`](#data-resource-reads-can-no-longer-be-disabled-by-refresh-false) * [Frequently Asked Questions](#frequently-asked-questions) ## Before You Upgrade @@ -135,7 +135,7 @@ for a module that must remain compatible with both Terraform v0.12 and Terraform v0.13; the `terraform 0.13upgrade` result includes a conservative version constraint for Terraform v0.13 or later, which you can weaken to `>= 0.12.26` if you follow the guidelines in -[v0.12-Compatible Provider Requirements](/docs/configuration/provider-requirements.html#v012-compatible-provider-requirements). +[v0.12-Compatible Provider Requirements](/docs/configuration/provider-requirements.html#v0-12-compatible-provider-requirements). Each module must declare its own set of provider requirements, so if you have a configuration which calls other modules then you'll need to run this upgrade @@ -441,7 +441,7 @@ accurate plan, and so there is no replacement mechanism in Terraform v0.13 to restore the previous behavior. ## Frequently Asked Questions -### Why do I see `-/provider` during init? +### Why do I see `-/provider` during init? Provider source addresses starting with `registry.terraform.io/-/` are a special way Terraform marks legacy addresses where the true namespace is unknown. For @@ -473,7 +473,7 @@ While this does not cause any problems for Terraform, it has been confusing. You may circumvent this by using the `terraform state replace-provider` subcommand to tell Terraform exactly what provider addresses are required in state. Continuing from the example above, the following commands tell Terraform the -source address for the `null` and `random` providers: +source address for the `null` and `random` providers: ``` terraform state replace-provider -- -/random registry.terraform.io/hashicorp/random