IntenseWebs/opentofu
3
0
Fork 0
mirror of https://github.com/opentofu/opentofu.git synced 2024-12-23 07:33:32 -06:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #31364 from timgates42/bugfix_typos

Browse Source 
docs: Fix a few typos
This commit is contained in:
Laura Pacilio 2022-07-06 17:03:09 -04:00 committed by GitHub
commit aeefde7428
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
docs/planning-behaviors.md
View File

@ -9,7 +9,7 @@ There are also some historical exceptions to this rule, which we hope to
supplement with plan-and-apply-based equivalents over time.
This document describes the default planning behavior of Terraform in the
absense of any special instructions, and also describes the three main
absence of any special instructions, and also describes the three main
design approaches we can choose from when modelling non-default behaviors that
require additional information from outside of Terraform Core.
@ -148,7 +148,7 @@ main sub-categories:
top-level block which refers to other resources using the typical address
syntax.
The following is a non-exhastive list of existing examples of
The following is a non-exhaustive list of existing examples of
configuration-driven behaviors, selected to illustrate some different variations
that might be useful inspiration for new designs:
@ -210,7 +210,7 @@ protocol does not talk about the action types explicitly, and instead only
implies them via other content of the request and response, with Terraform Core
making the final decision about how to react to that information.
The following is a non-exhastive list of existing examples of
The following is a non-exhaustive list of existing examples of
provider-driven behaviors, selected to illustrate some different variations
that might be useful inspiration for new designs:
@ -258,7 +258,7 @@ most appropriate way to handle a particular use-case, because the need for the
behavior originates in some process happening outside of the scope of any
particular Terraform module or provider.
The following is a non-exhastive list of existing examples of
The following is a non-exhaustive list of existing examples of
single-run behaviors, selected to illustrate some different variations
that might be useful inspiration for new designs:

2
docs/resource-instance-change-lifecycle.md
View File

@ -322,7 +322,7 @@ to bring them under Terraform's management without needing to recreate them
first.
When using this facility, the user provides the address of the resource
instance they wish to bind the existing object to, and a string repesentation
instance they wish to bind the existing object to, and a string representation
of the identifier of the existing object to be imported in a syntax defined
by the provider on a per-resource-type basis, which we'll call the
**Import ID**.

2
website/README.md
View File

@ -15,7 +15,7 @@ Click **Edit this page** at the bottom of any Terraform website page to go direc
## Modifying Sidebar Navigation
Updates to the sidebar navigation of Terraform docs need to be made in the [`terraform-website`](https://github.com/hashicorp/terraform-website/) repository (preferrably in a PR also updating the submodule commit). You can read more about how to make modifications to the navigation in the [README for `terraform-website`](https://github.com/hashicorp/terraform-website#editing-navigation-sidebars).
Updates to the sidebar navigation of Terraform docs need to be made in the [`terraform-website`](https://github.com/hashicorp/terraform-website/) repository (preferably in a PR also updating the submodule commit). You can read more about how to make modifications to the navigation in the [README for `terraform-website`](https://github.com/hashicorp/terraform-website#editing-navigation-sidebars).
## Previewing Changes