take out currently

This commit is contained in:
Laura Pacilio 2022-10-17 19:00:19 -04:00
parent 9f77c954ec
commit 31a9fde330
19 changed files with 35 additions and 54 deletions

View File

@ -107,8 +107,7 @@ even when you specify `-chdir=...`:
## Shell Tab-completion
If you use either `bash` or `zsh` as your command shell, Terraform can provide
tab-completion support for all command names and (at this time) _some_ command
arguments.
tab-completion support for all command names and some command arguments.
To add the necessary commands to your shell profile, run the following command:
@ -126,9 +125,6 @@ manually in the shell profile, run the following command:
terraform -uninstall-autocomplete
```
Currently not all of Terraform's subcommands have full tab-completion support
for all arguments. We plan to improve tab-completion coverage over time.
## Upgrade and Security Bulletin Checks
The Terraform CLI commands interact with the HashiCorp service

View File

@ -89,7 +89,7 @@ stream. The top-level JSON object will have the following properties:
The nested objects in `diagnostics` have the following properties:
- `severity` (string): A string keyword, currently either `"error"` or
- `severity` (string): A string keyword, either `"error"` or
`"warning"`, indicating the diagnostic severity.
The presence of errors causes Terraform to consider a configuration to be

View File

@ -2,21 +2,15 @@
page_title: 'Import: Resource Importability'
description: |-
Each resource in Terraform must implement some basic logic to become
importable. As a result, not all Terraform resources are currently importable.
importable. As a result, you cannot import all Terraform resources.
---
# Resource Importability
Each resource in Terraform must implement some basic logic to become
importable. As a result, not all Terraform resources are currently importable.
For those resources that support import, they are documented at the bottom of
each resource documentation page, under the Import heading. If you find a
resource that you want to import and Terraform reports that it is not
importable, please report an issue in the relevant provider repository.
importable. As a result, you cannot import not all Terraform resources.
Converting a resource to be importable is also relatively simple, so if
you're interested in contributing that functionality, the Terraform team
would be grateful.
The resources that you can import are documented at the bottom of
each resource documentation page in the [Terraform Registry](https://registry.terraform.io/). If you have issues importing a resource, report an issue in the relevant provider repository.
To make a resource importable, please see
[Extending Terraform: Resources — Import](/plugin/sdkv2/resources/import).
To make a resource importable, refer to [Extending Terraform: Resources — Import](/plugin/sdkv2/resources/import).

View File

@ -69,7 +69,7 @@ To configure your repository:
## Supported Architectures
The HashiCorp APT server currently has packages only for the `amd64`
The HashiCorp APT server has packages only for the `amd64`
architecture, which is also sometimes known as `x86_64`.
There are no official packages available for other architectures, such as
@ -78,7 +78,7 @@ There are no official packages available for other architectures, such as
## Supported Debian and Ubuntu Releases
The HashiCorp APT server currently contains release repositories for the
The HashiCorp APT server contains release repositories for the
following distribution releases:
* Debian 8 (`jessie`)

View File

@ -58,7 +58,7 @@ yum install terraform
## Supported Architectures
The HashiCorp Yum/DNF server currently has packages only for the `x86_64`
The HashiCorp Yum/DNF server has packages only for the `x86_64`
architecture, which is also sometimes known as `amd64`.
There are no official packages available for other architectures, such as
@ -67,7 +67,7 @@ There are no official packages available for other architectures, such as
## Supported Distribution Releases
The HashiCorp Yum server currently contains release repositories for the
The HashiCorp Yum server contains release repositories for the
following distribution releases:
* AmazonLinux 2
@ -95,8 +95,8 @@ more than one version at a time, and `yum install` or `dnf install` will
default to selecting the latest version.
It's often necessary to match your Terraform version with what a particular
configuration is currently expecting. You can use the following command to
see which versions are currently available in the repository index:
configuration is currently expecting. Use the following command to
retrieve the available versions in the repository index:
```bash
yum --showduplicate list terraform

View File

@ -12,8 +12,7 @@ of resources. (For more information about providers, see
[Providers](/language/providers) in the Terraform
language docs.)
-> **Note:** Providers are currently the only plugin type most Terraform users
will interact with. Terraform also supports third-party provisioner plugins, but
-> **Note:** Providers are the only plugin type most Terraform users interact with. Terraform also supports third-party provisioner plugins, but
we discourage their use.
Terraform downloads and/or installs any providers

View File

@ -9,7 +9,7 @@ description: >-
# Plugin Signing
~> **Note** Currently only provider plugins fetched from a registry are authenticated.
~> **Note** Terraform only authenticates provider plugins fetched from a registry.
Terraform providers installed from the Registry are cryptographically signed, and the signature is verified at time of installation. There are three types of provider signatures, each with different trust implications:

View File

@ -140,8 +140,8 @@ stream and then exiting with a non-zero status code.
## Handling Unsupported Credentials Object Properties
Currently Terraform defines only the `token` property within JSON credentials
objects, but this format might be extended in future.
Terraform defines only the `token` property within JSON credentials
objects.
If a credentials helper is asked to store an object that has any properties
other than `token` and if it is not able to faithfully retain them then it

View File

@ -49,7 +49,7 @@ The JSON output format consists of the following objects and sub-objects:
## State Representation
Because state does not currently have any significant metadata not covered by the common values representation ([described below](#values-representation)), the `<state-representation>` is straightforward:
Because state does not have any significant metadata not covered by the common values representation ([described below](#values-representation)), the `<state-representation>` uses the following format:
```javascript
{
@ -612,7 +612,7 @@ A `<change-representation>` describes the change to the indicated object.
## Checks Representation
~> **Warning:** The JSON representation of "checks" is currently experimental
~> **Warning:** The JSON representation of "checks" is experimental
and some details may change in future Terraform versions based on feedback,
even in minor releases of Terraform CLI.
@ -627,8 +627,7 @@ A `<checks-representation>` describes the current state of a checkable object in
// "kind" specifies what kind of checkable object this is. Different
// kinds of object will have different additional properties inside the
// address object, but all kinds include both "kind" and "to_display".
// Currently the two valid kinds are "resource" and "output_value", but
// additional kinds may be added in future Terraform versions.
// The two valid kinds are "resource" and "output_value".
"kind": "resource",
// "to_display" contains an opaque string representation of the address

View File

@ -51,7 +51,7 @@ The properties within the discovery object are as follows:
specific mechanism by which an OAuth server authenticates the request and
issues an authorization token.
Terraform CLI currently only supports a single grant type:
Terraform CLI supports a single grant type:
* `authz_code`: [authorization code grant](https://tools.ietf.org/html/rfc6749#section-4.1).
Both the `authz` and `token` properties are required when `authz_code` is

View File

@ -136,7 +136,7 @@ At the end of a plan or before an apply, Terraform will emit a `planned_change`
- `resource`: object describing the address of the resource to be changed; see [resource object](#resource-object) below for details
- `previous_resource`: object describing the previous address of the resource, if this change includes a configuration-driven move
- `action`: the action planned to be taken for the resource. Values: `noop`, `create`, `read`, `update`, `replace`, `delete`, `move`.
- `reason`: an optional reason for the change, currently only used when the action is `replace` or `delete`. Values:
- `reason`: an optional reason for the change, only used when the action is `replace` or `delete`. Values:
- `tainted`: resource was marked as tainted
- `requested`: user requested that the resource be replaced, for example via the `-replace` plan flag
- `cannot_update`: changes to configuration force the resource to be deleted and created rather than updated

View File

@ -147,9 +147,7 @@ $ curl 'https://registry.terraform.io/v1/modules/hashicorp/consul/aws/versions'
The `modules` array in the response always includes the requested module as the
first element.
Other elements of this list are not currently used. Third-party implementations
should always use a single-element list for forward compatiblity with possible
future extensions to the protocol.
Terraform does not use the other elements of this list. However, third-party implementations should always use a single-element list for forward compatiblity.
Each returned module has an array of available versions, which Terraform
matches against any version constraints given in configuration.

View File

@ -149,9 +149,7 @@ A successful result is a JSON object containing a single property `versions`,
which must be a JSON object.
Each of the property names of the `versions` object represents an available
version number. The property values must be objects, but no properties are
currently defined for those objects. We recommend leaving those objects
empty.
version number. The property values must be objects, but no properties are defined for those objects. We recommend leaving those objects empty.
Return `404 Not Found` to signal that the mirror does not have a provider
with the given address.

View File

@ -294,11 +294,11 @@ A successful result is a JSON object with the following properties:
_required_ for describing an individual provider package so that Terraform
CLI can avoid downloading a package that will not be compatible with it.
* `os` (required): this must currently echo back the `os` parameter from the
request. Other possibilities may come in later versions of this protocol.
* `os` (required): this must echo back the `os` parameter from the
request.
* `arch` (required): this must currently echo back the `arch` parameter from the
request. Other possibilities may come in later versions of this protocol.
* `arch` (required): this must echo back the `arch` parameter from the
request.
* `filename` (required): the filename for this provider's zip archive as
recorded in the "shasums" document, so that Terraform CLI can determine which

View File

@ -96,9 +96,8 @@ The three kinds of collection type in the Terraform language are:
for single line maps. A newline between key/value pairs is sufficient
in multi-line maps.
Note: Although colons are valid delimiters between keys and values,
`terraform fmt` currently ignores them (whereas `terraform fmt`
attempts to vertically align equals signs).
-> **Note:** Although colons are valid delimiters between keys and values, `terraform fmt` ignores them. In contrast, `terraform fmt` attempts to vertically align equals signs.
* `set(...)`: a collection of unique values that do not have any secondary
identifiers or ordering.

View File

@ -134,8 +134,7 @@ described in more detail in the following pages:
[the `depends_on` page](/language/meta-arguments/depends_on)
for details.
In addition to the above, the `lifecycle` argument is not currently used by
Terraform but is reserved for planned future features.
Terraform does not use the `lifecycle` argument.
## Accessing Module Output Values

View File

@ -270,7 +270,7 @@ functionality and so with that in mind there are some specific possibilities
that we know the current prototype doesn't support well:
* Testing of subsequent updates to an existing deployment of a module.
Currently tests written in this way can only exercise the create and destroy
Tests written in this way can only exercise the create and destroy
behaviors.
* Assertions about expected errors. For a module that includes variable

View File

@ -271,9 +271,8 @@ incompatibilities, and let the root module manage the maximum version.
## Built-in Providers
While most Terraform providers are distributed separately as plugins, there
is currently one provider that is built in to Terraform itself, which
provides
Most Terraform providers are distributed separately as plugins, but there
is one provider that is built into Terraform itself. This built-in plugin provides the
[the `terraform_remote_state` data source](/language/state/remote-state-data).
Because this provider is built in to Terraform, you don't need to declare it

View File

@ -18,7 +18,7 @@ You can also use Terraform Cloud with local operations, in which case only state
## Command Support
Currently the remote backend supports the following Terraform commands:
The remote backend supports the following Terraform commands:
- `apply`
- `console` (supported in Terraform >= v0.11.12)