mirror of
https://github.com/opentffoundation/opentf.git
synced 2025-12-25 01:00:16 -05:00
Migrating links to new format
This commit is contained in:
Ashlee Boyer
@@ -25,4 +25,4 @@ What does archiving mean?
|
||||
|
||||
HashiCorp may archive a provider when we or the community are not able to support it at a level consistent with our open source guidelines and community expectations.
|
||||
|
||||
Archiving is reversible. If anyone from the community is willing to maintain an archived provider, please reach out to the [Terraform Provider Development Program](/docs/partnerships) at _<terraform-provider-dev@hashicorp.com>_.
|
||||
Archiving is reversible. If anyone from the community is willing to maintain an archived provider, please reach out to the [Terraform Provider Development Program](/terraform/docs/partnerships) at _<terraform-provider-dev@hashicorp.com>_.
|
||||
|
||||
@@ -8,10 +8,10 @@ description: >-
|
||||
# Credentials Helpers
|
||||
|
||||
For Terraform-specific features that interact with remote network services,
|
||||
such as [module registries](/registry) and
|
||||
[remote operations](/cloud-docs/run/cli), Terraform by default looks for
|
||||
such as [module registries](/terraform/registry) and
|
||||
[remote operations](/terraform/cloud-docs/run/cli), Terraform by default looks for
|
||||
API credentials to use in these calls in
|
||||
[the CLI configuration](/cli/config/config-file).
|
||||
[the CLI configuration](/terraform/cli/config/config-file).
|
||||
|
||||
Credentials helpers offer an alternative approach that allows you to customize
|
||||
how Terraform obtains credentials using an external program, which can then
|
||||
@@ -19,7 +19,7 @@ directly access an existing secrets management system in your organization.
|
||||
|
||||
This page is about how to write and install a credentials helper. To learn
|
||||
how to configure a credentials helper that was already installed, see
|
||||
[the CLI config Credentials Helpers section](/cli/config/config-file#credentials-helpers).
|
||||
[the CLI config Credentials Helpers section](/terraform/cli/config/config-file#credentials-helpers).
|
||||
|
||||
## How Terraform finds Credentials Helpers
|
||||
|
||||
@@ -29,7 +29,7 @@ particular location and whose name follows a specific naming convention.
|
||||
A credentials helper called "credstore", for example, would be implemented as
|
||||
an executable program named `terraform-credentials-credstore` (with an `.exe`
|
||||
extension on Windows only), and installed in one of the
|
||||
[default plugin search locations](/plugin/how-terraform-works#plugin-locations).
|
||||
[default plugin search locations](/terraform/plugin/how-terraform-works#plugin-locations).
|
||||
|
||||
## How Terraform runs Credentials Helpers
|
||||
|
||||
@@ -56,7 +56,7 @@ The current set of verbs are:
|
||||
|
||||
To represent credentials, the credentials helper protocol uses a JSON object
|
||||
whose contents correspond with the contents of
|
||||
[`credentials` blocks in the CLI configuration](/cli/config/config-file#credentials).
|
||||
[`credentials` blocks in the CLI configuration](/terraform/cli/config/config-file#credentials).
|
||||
To represent an API token, the object contains a property called "token" whose
|
||||
value is the token string:
|
||||
|
||||
@@ -159,7 +159,7 @@ other properties as described above.
|
||||
|
||||
Terraform does not have any automatic installation mechanism for credentials
|
||||
helpers. Instead, the user must extract the helper program executable into
|
||||
one of the [default plugin search locations](/plugin/how-terraform-works#plugin-locations).
|
||||
one of the [default plugin search locations](/terraform/plugin/how-terraform-works#plugin-locations).
|
||||
|
||||
If you are packaging a credentials helper for distribution, place it in an
|
||||
named with the expected naming scheme (`terraform-credentials-example`) and,
|
||||
|
||||
@@ -8,7 +8,7 @@ description: >-
|
||||
|
||||
# Debugging Terraform
|
||||
|
||||
> **Hands-on:** Try the [Create Dynamic Expressions](https://learn.hashicorp.com/tutorials/terraform/troubleshooting-workflow#bug-reporting-best-practices?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) tutorial.
|
||||
> **Hands-on:** Try the [Create Dynamic Expressions](/terraform/tutorials/configuration-language/troubleshooting-workflow#bug-reporting-best-practices?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) tutorial.
|
||||
|
||||
Terraform has detailed logs that you can enable by setting the `TF_LOG` environment variable to any value. Enabling this setting causes detailed logs to appear on `stderr`.
|
||||
|
||||
|
||||
@@ -32,7 +32,7 @@ value `"1.0"`. The semantics of this version are:
|
||||
version.
|
||||
|
||||
We will introduce new major versions only within the bounds of
|
||||
[the Terraform 1.0 Compatibility Promises](/language/v1-compatibility-promises).
|
||||
[the Terraform 1.0 Compatibility Promises](/terraform/language/v1-compatibility-promises).
|
||||
|
||||
## Format Summary
|
||||
|
||||
|
||||
@@ -110,8 +110,8 @@ The amount of parallelism is limited using a semaphore to prevent too many
|
||||
concurrent operations from overwhelming the resources of the machine running
|
||||
Terraform. By default, up to 10 nodes in the graph will be processed
|
||||
concurrently. This number can be set using the `-parallelism` flag on the
|
||||
[plan](/cli/commands/plan), [apply](/cli/commands/apply), and
|
||||
[destroy](/cli/commands/destroy) commands.
|
||||
[plan](/terraform/cli/commands/plan), [apply](/terraform/cli/commands/apply), and
|
||||
[destroy](/terraform/cli/commands/destroy) commands.
|
||||
|
||||
Setting `-parallelism` is considered an advanced operation and should not be
|
||||
necessary for normal usage of Terraform. It may be helpful in certain special
|
||||
|
||||
@@ -13,7 +13,7 @@ When Terraform plans to make changes, it prints a human-readable summary to the
|
||||
|
||||
Since the format of plan files isn't suited for use with external tools (and likely never will be), Terraform can output a machine-readable JSON representation of a plan file's changes. It can also convert state files to the same format, to simplify data loading and provide better long-term compatibility.
|
||||
|
||||
Use `terraform show -json <FILE>` to generate a JSON representation of a plan or state file. See [the `terraform show` documentation](/cli/commands/show) for more details.
|
||||
Use `terraform show -json <FILE>` to generate a JSON representation of a plan or state file. See [the `terraform show` documentation](/terraform/cli/commands/show) for more details.
|
||||
|
||||
The output includes a `format_version` key, which as of Terraform 1.1.0 has
|
||||
value `"1.0"`. The semantics of this version are:
|
||||
@@ -26,7 +26,7 @@ value `"1.0"`. The semantics of this version are:
|
||||
version.
|
||||
|
||||
We will introduce new major versions only within the bounds of
|
||||
[the Terraform 1.0 Compatibility Promises](/language/v1-compatibility-promises).
|
||||
[the Terraform 1.0 Compatibility Promises](/terraform/language/v1-compatibility-promises).
|
||||
|
||||
## Format Summary
|
||||
|
||||
@@ -338,7 +338,7 @@ The following example illustrates the structure of a `<values-representation>`:
|
||||
}
|
||||
```
|
||||
|
||||
The translation of attribute and output values is the same intuitive mapping from HCL types to JSON types used by Terraform's [`jsonencode`](/language/functions/jsonencode) function. This mapping does lose some information: lists, sets, and tuples all lower to JSON arrays while maps and objects both lower to JSON objects. Unknown values and null values are both treated as absent or null.
|
||||
The translation of attribute and output values is the same intuitive mapping from HCL types to JSON types used by Terraform's [`jsonencode`](/terraform/language/functions/jsonencode) function. This mapping does lose some information: lists, sets, and tuples all lower to JSON arrays while maps and objects both lower to JSON objects. Unknown values and null values are both treated as absent or null.
|
||||
|
||||
Output values include a `"type"` field, which is a [serialization of the value's type](https://pkg.go.dev/github.com/zclconf/go-cty/cty#Type.MarshalJSON). For primitive types this is a string value, such as `"number"` or `"bool"`. Complex types are represented as a nested JSON array, such as `["map","string"]` or `["object",{"a":"number"}]`. This can be used to reconstruct the output value with the correct type.
|
||||
|
||||
|
||||
@@ -8,18 +8,18 @@ description: >-
|
||||
# Server-side Login Protocol
|
||||
|
||||
~> **Note:** You don't need to read these docs to _use_
|
||||
[`terraform login`](/cli/commands/login). The information below is for
|
||||
[`terraform login`](/terraform/cli/commands/login). The information below is for
|
||||
anyone intending to implement the server side of `terraform login` in order to
|
||||
offer Terraform-native services in a third-party system.
|
||||
|
||||
The `terraform login` command supports performing an OAuth 2.0 authorization
|
||||
request using configuration provided by the target host. You may wish to
|
||||
implement this protocol if you are producing a third-party implementation of
|
||||
any [Terraform-native services](/internals/remote-service-discovery),
|
||||
any [Terraform-native services](/terraform/internals/remote-service-discovery),
|
||||
such as a Terraform module registry.
|
||||
|
||||
First, Terraform uses
|
||||
[remote service discovery](/internals/remote-service-discovery) to
|
||||
[remote service discovery](/terraform/internals/remote-service-discovery) to
|
||||
find the OAuth configuration for the host. The host must support the service
|
||||
name `login.v1` and define for it an object containing OAuth client
|
||||
configuration values, like this:
|
||||
|
||||
@@ -24,7 +24,7 @@ value `"1.0"`. The semantics of this version are:
|
||||
version.
|
||||
|
||||
We will introduce new major versions only within the bounds of
|
||||
[the Terraform 1.0 Compatibility Promises](/language/v1-compatibility-promises).
|
||||
[the Terraform 1.0 Compatibility Promises](/terraform/language/v1-compatibility-promises).
|
||||
|
||||
## Sample JSON Output
|
||||
|
||||
@@ -60,7 +60,7 @@ The following message types are supported:
|
||||
|
||||
- `version`: information about the Terraform version and the version of the schema used for the following messages
|
||||
- `log`: unstructured human-readable log lines
|
||||
- `diagnostic`: diagnostic warning or error messages; [see the `terraform validate` docs for more details on the format](/cli/commands/validate#json)
|
||||
- `diagnostic`: diagnostic warning or error messages; [see the `terraform validate` docs for more details on the format](/terraform/cli/commands/validate#json)
|
||||
|
||||
### Operation Results
|
||||
|
||||
@@ -103,7 +103,7 @@ If drift is detected during planning, Terraform will emit a `resource_drift` mes
|
||||
- `resource`: object describing the address of the resource to be changed; see [resource object](#resource-object) below for details
|
||||
- `action`: the action planned to be taken for the resource. Values: `update`, `delete`.
|
||||
|
||||
This message does not include details about the exact changes which caused the change to be planned. That information is available in [the JSON plan output](/internals/json-format).
|
||||
This message does not include details about the exact changes which caused the change to be planned. That information is available in [the JSON plan output](/terraform/internals/json-format).
|
||||
|
||||
### Example
|
||||
|
||||
@@ -146,7 +146,7 @@ At the end of a plan or before an apply, Terraform will emit a `planned_change`
|
||||
- `delete_because_each_key`: resource instance key is not included in the `for_each` argument
|
||||
- `delete_because_no_module`: enclosing module instance is not in configuration
|
||||
|
||||
This message does not include details about the exact changes which caused the change to be planned. That information is available in [the JSON plan output](/internals/json-format).
|
||||
This message does not include details about the exact changes which caused the change to be planned. That information is available in [the JSON plan output](/terraform/internals/json-format).
|
||||
|
||||
### Example
|
||||
|
||||
|
||||
@@ -23,7 +23,7 @@ publishing them on the public Terraform Registry.
|
||||
The public Terraform Registry implements a superset of the API described on
|
||||
this page, in order to capture additional information used in the registry UI.
|
||||
For information on those extensions, see
|
||||
[Terraform Registry HTTP API](/registry/api-docs). Third-party registry
|
||||
[Terraform Registry HTTP API](/terraform/registry/api-docs). Third-party registry
|
||||
implementations may choose to implement those extensions if desired, but
|
||||
Terraform CLI itself does not use them.
|
||||
|
||||
@@ -81,7 +81,7 @@ blocks have the same source address.
|
||||
## Service Discovery
|
||||
|
||||
The module registry protocol begins with Terraform CLI using
|
||||
[Terraform's remote service discovery protocol](/internals/remote-service-discovery),
|
||||
[Terraform's remote service discovery protocol](/terraform/internals/remote-service-discovery),
|
||||
with the hostname in the module address acting as the "User-facing Hostname".
|
||||
|
||||
The service identifier for the module registry protocol is `modules.v1`.
|
||||
@@ -209,10 +209,10 @@ A successful response has no body, and includes the location from which the
|
||||
module version's source can be downloaded in the `X-Terraform-Get` header.
|
||||
The value of this header accepts the same values as the `source` argument
|
||||
in a `module` block in Terraform configuration, as described in
|
||||
[Module Sources](/language/modules/sources),
|
||||
[Module Sources](/terraform/language/modules/sources),
|
||||
except that it may not recursively refer to another module registry address.
|
||||
|
||||
The value of `X-Terraform-Get` may instead be a relative URL, indicated by
|
||||
beginning with `/`, `./` or `../`, in which case it is resolved relative to
|
||||
the full URL of the download endpoint to produce
|
||||
[an HTTP URL module source](/language/modules/sources#http-urls).
|
||||
[an HTTP URL module source](/terraform/language/modules/sources#http-urls).
|
||||
|
||||
@@ -16,7 +16,7 @@ implement to provide an alternative installation source for Terraform providers,
|
||||
regardless of their origin registries.
|
||||
|
||||
Terraform uses network mirrors only if you activate them explicitly in
|
||||
[the CLI configuration's `provider_installation` block](/cli/config/config-file#provider-installation).
|
||||
[the CLI configuration's `provider_installation` block](/terraform/cli/config/config-file#provider-installation).
|
||||
When enabled, a network mirror can serve providers belonging to any registry
|
||||
hostname, which can allow an organization to serve all of the Terraform
|
||||
providers they intend to use from an internal server, rather than from each
|
||||
@@ -26,7 +26,7 @@ This is _not_ the protocol that should be implemented by a host intending to
|
||||
serve as an origin registry for Terraform Providers. To provide an origin
|
||||
registry (whose hostname would then be included in the source addresses of the
|
||||
providers it hosts), implement
|
||||
[the provider registry protocol](/internals/provider-registry-protocol)
|
||||
[the provider registry protocol](/terraform/internals/provider-registry-protocol)
|
||||
instead.
|
||||
|
||||
## Provider Addresses
|
||||
@@ -34,7 +34,7 @@ instead.
|
||||
Each Terraform provider has an associated address which uniquely identifies it
|
||||
within Terraform. A provider address has the syntax `hostname/namespace/type`,
|
||||
which is described in more detail in
|
||||
[the Provider Requirements documentation](/language/providers/requirements).
|
||||
[the Provider Requirements documentation](/terraform/language/providers/requirements).
|
||||
|
||||
By default, the `hostname` portion of a provider address serves both as part
|
||||
of its unique identifier _and_ as the location of the registry to retrieve it
|
||||
@@ -52,7 +52,7 @@ the hostname where the provider network mirror is deployed.
|
||||
## Protocol Base URL
|
||||
|
||||
Most Terraform-native services use
|
||||
[the remote service discovery protocol](/internals/remote-service-discovery) so
|
||||
[the remote service discovery protocol](/terraform/internals/remote-service-discovery) so
|
||||
that the physical location of the endpoints can potentially be separated from
|
||||
the hostname used in identifiers. The Provider Network Mirror protocol does
|
||||
_not_ use the service discovery indirection, because a network mirror location
|
||||
@@ -94,7 +94,7 @@ base URL from the above CLI configuration example.
|
||||
### Authentication
|
||||
|
||||
If the CLI configuration includes
|
||||
[credentials](/cli/config/config-file#credentials) for the hostname
|
||||
[credentials](/terraform/cli/config/config-file#credentials) for the hostname
|
||||
given in the network mirror base URL, Terraform will include those credentials
|
||||
in its requests for operations described below.
|
||||
|
||||
@@ -258,7 +258,7 @@ in the appropriate nested subdirectories, and ensure that your system is
|
||||
configured to serve `.json` files with the `application/json` media type.
|
||||
|
||||
As a convenience, Terraform CLI includes
|
||||
[the `terraform providers mirror` subcommand](/cli/commands/providers/mirror),
|
||||
[the `terraform providers mirror` subcommand](/terraform/cli/commands/providers/mirror),
|
||||
which will analyze the current configuration for the providers it requires,
|
||||
download the packages for those providers from their origin registries, and
|
||||
place them into a local directory suitable for use as a mirror.
|
||||
|
||||
@@ -40,7 +40,7 @@ where:
|
||||
* `hostname` is the registry host that the provider is considered to have
|
||||
originated from, and the default location Terraform will consult for
|
||||
information about the provider
|
||||
[unless overridden in the CLI configuration](/cli/config/config-file#provider-installation).
|
||||
[unless overridden in the CLI configuration](/terraform/cli/config/config-file#provider-installation).
|
||||
* `namespace` is the name of a namespace, unique on a particular hostname, that
|
||||
can contain one or more providers that are somehow related. On the public
|
||||
Terraform Registry the "namespace" represents the organization that is
|
||||
@@ -76,7 +76,7 @@ to see it as an entirely separate provider that will _not_ be usable by modules
|
||||
that declare a dependency on `hashicorp/azurerm`. If your goal is to create
|
||||
an alternative local distribution source for an existing provider -- that is,
|
||||
a _mirror_ of the provider -- refer to
|
||||
[the provider installation method configuration](/cli/config/config-file#provider-installation)
|
||||
[the provider installation method configuration](/terraform/cli/config/config-file#provider-installation)
|
||||
instead.
|
||||
|
||||
## Provider Versions
|
||||
@@ -96,7 +96,7 @@ version selection.
|
||||
## Service Discovery
|
||||
|
||||
The providers protocol begins with Terraform CLI using
|
||||
[Terraform's remote service discovery protocol](/internals/remote-service-discovery),
|
||||
[Terraform's remote service discovery protocol](/terraform/internals/remote-service-discovery),
|
||||
with the hostname in the provider address acting as the "User-facing Hostname".
|
||||
|
||||
The service identifier for the provider registry protocol is `providers.v1`.
|
||||
|
||||
@@ -83,14 +83,14 @@ version 1 of the module registry protocol:
|
||||
|
||||
At present, the following service identifiers are in use:
|
||||
|
||||
* `login.v1`: [login protocol version 1](/cli/commands/login)
|
||||
* `modules.v1`: [module registry API version 1](/internals/module-registry-protocol)
|
||||
* `providers.v1`: [provider registry API version 1](/internals/provider-registry-protocol)
|
||||
* `login.v1`: [login protocol version 1](/terraform/cli/commands/login)
|
||||
* `modules.v1`: [module registry API version 1](/terraform/internals/module-registry-protocol)
|
||||
* `providers.v1`: [provider registry API version 1](/terraform/internals/provider-registry-protocol)
|
||||
|
||||
## Authentication
|
||||
|
||||
If credentials for the given hostname are available in
|
||||
[the CLI config](/cli/config/config-file#Credentials) through a `credentials_helper` or a host-specific environment variable, then they will be included in the request for the discovery document.
|
||||
[the CLI config](/terraform/cli/config/config-file#Credentials) through a `credentials_helper` or a host-specific environment variable, then they will be included in the request for the discovery document.
|
||||
|
||||
The credentials may also be provided to endpoints declared in the discovery
|
||||
document, depending on the requirements of the service in question.
|
||||
|
||||
Reference in New Issue
Block a user