ResiLien
/
terraform
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
terraform/website/docs/configuration/resources.html.md

87 lines
2.2 KiB
Markdown
Raw Normal View History

dos2unix
2014-07-28 19:43:00 +02:00
---
website: Adopt a ton of pages into the "language" layout As of this commit, that layout doesn't exist yet, but I'm isolating the one-line changes to their own commit to try and keep your eyes from glazing over.
2020-08-15 03:51:06 +02:00
layout: "language"
website: Break up Resources page into smaller chunks - Resource behavior gets its own page. - Meta-arguments all get their own pages. - Stuff about resource syntax itself gets a page. In the process of breaking the meta-arguments out into their own pages, I revised them (with the exception of `provider`) so that they apply to both resources and modules. Like with Expressions, this commit repurposes the old resources.html URL as a landing page for old links.
2020-11-13 03:06:32 +01:00
page_title: "Resources Landing Page - Configuration Language"
dos2unix
2014-07-28 19:43:00 +02:00
---
website: Break up Resources page into smaller chunks - Resource behavior gets its own page. - Meta-arguments all get their own pages. - Stuff about resource syntax itself gets a page. In the process of breaking the meta-arguments out into their own pages, I revised them (with the exception of `provider`) so that they apply to both resources and modules. Like with Expressions, this commit repurposes the old resources.html URL as a landing page for old links.
2020-11-13 03:06:32 +01:00
# Resources Landing Page
dos2unix
2014-07-28 19:43:00 +02:00
website: Break up Resources page into smaller chunks - Resource behavior gets its own page. - Meta-arguments all get their own pages. - Stuff about resource syntax itself gets a page. In the process of breaking the meta-arguments out into their own pages, I revised them (with the exception of `provider`) so that they apply to both resources and modules. Like with Expressions, this commit repurposes the old resources.html URL as a landing page for old links.
2020-11-13 03:06:32 +01:00
To improve navigation, we've split the old Resources page into several smaller
pages.
website: Version notes: Add new -> old links to 0.12 language docs (except function pages)
2019-01-17 01:30:43 +01:00
website: Break up Resources page into smaller chunks - Resource behavior gets its own page. - Meta-arguments all get their own pages. - Stuff about resource syntax itself gets a page. In the process of breaking the meta-arguments out into their own pages, I revised them (with the exception of `provider`) so that they apply to both resources and modules. Like with Expressions, this commit repurposes the old resources.html URL as a landing page for old links.
2020-11-13 03:06:32 +01:00
<a id="resource-syntax"></a>
<a id="resource-types"></a>
<a id="providers"></a>
<a id="resource-arguments"></a>
<a id="documentation-for-resource-types"></a>
<a id="meta-arguments"></a>
<a id="operation-timeouts"></a>
website: Add links to relevant Learn guides in several docs pages (#25718) Co-authored-by: Tu Nguyen <im2nguyen@users.noreply.github.com>
2020-07-31 22:16:35 +02:00
website: Break up Resources page into smaller chunks - Resource behavior gets its own page. - Meta-arguments all get their own pages. - Stuff about resource syntax itself gets a page. In the process of breaking the meta-arguments out into their own pages, I revised them (with the exception of `provider`) so that they apply to both resources and modules. Like with Expressions, this commit repurposes the old resources.html URL as a landing page for old links.
2020-11-13 03:06:32 +01:00
## Syntax and Elements of Resource Blocks
dos2unix
2014-07-28 19:43:00 +02:00
website: Break up Resources page into smaller chunks - Resource behavior gets its own page. - Meta-arguments all get their own pages. - Stuff about resource syntax itself gets a page. In the process of breaking the meta-arguments out into their own pages, I revised them (with the exception of `provider`) so that they apply to both resources and modules. Like with Expressions, this commit repurposes the old resources.html URL as a landing page for old links.
2020-11-13 03:06:32 +01:00
This information has moved to
[Resource Blocks](/docs/configuration/blocks/resources/syntax.html).
dos2unix
2014-07-28 19:43:00 +02:00
website: Break up Resources page into smaller chunks - Resource behavior gets its own page. - Meta-arguments all get their own pages. - Stuff about resource syntax itself gets a page. In the process of breaking the meta-arguments out into their own pages, I revised them (with the exception of `provider`) so that they apply to both resources and modules. Like with Expressions, this commit repurposes the old resources.html URL as a landing page for old links.
2020-11-13 03:06:32 +01:00
<a id="resource-behavior"></a>
<a id="accessing-resource-attributes"></a>
<a id="resource-dependencies"></a>
<a id="local-only-resources"></a>
dos2unix
2014-07-28 19:43:00 +02:00
website: Break up Resources page into smaller chunks - Resource behavior gets its own page. - Meta-arguments all get their own pages. - Stuff about resource syntax itself gets a page. In the process of breaking the meta-arguments out into their own pages, I revised them (with the exception of `provider`) so that they apply to both resources and modules. Like with Expressions, this commit repurposes the old resources.html URL as a landing page for old links.
2020-11-13 03:06:32 +01:00
## Details of Resource Behavior
dos2unix
2014-07-28 19:43:00 +02:00
website: Break up Resources page into smaller chunks - Resource behavior gets its own page. - Meta-arguments all get their own pages. - Stuff about resource syntax itself gets a page. In the process of breaking the meta-arguments out into their own pages, I revised them (with the exception of `provider`) so that they apply to both resources and modules. Like with Expressions, this commit repurposes the old resources.html URL as a landing page for old links.
2020-11-13 03:06:32 +01:00
This information has moved to
[Resource Behavior](/docs/configuration/blocks/resources/behavior.html).
website: revise the "Resources" configuration docs section This is now the leading subsection of the Configuration section of the docs, and so this rewrite intends to make it more "guide-like" and as accessible as possible to those who are not yet familiar with other Terraform concepts. This rewrite also attempts to introduce some consistency into our vocabulary, which should eventually be reflected throughout our documentation. In particular: - "Resource" refers to the block the user writes in configuration, while "Resource _Type_" refers to what the provider defines. We previously used "resource" for both of these interchangeably. - "Resource" is no longer used to refer to what gets created and managed in remote APIs as a result of a resource block in configuration. Lacking a good distinct name for these, this guide uses the word "object", qualifying it as "infrastructure object" or "remote object" where necessary to retain clarity. This distinction is important to enable a clear description of resource lifecycle. - "Argument" refers to an element (attribute or block) within a resource block. This terminology was already being used in some places, so we embrace it here as a way to distinguish from "attribute", which is what a resource _exports_ for use in expressions. - Since interpolation is no longer needed to use expressions in the language, the word "expression" is used to describe the definition of a value that might involve some computation. Where necessary, this is used with a modifier "arbitrary expression" to contrast with situations where the set of allowed expression constructs is constrained.
2018-05-05 23:00:31 +02:00
website: Break up Resources page into smaller chunks - Resource behavior gets its own page. - Meta-arguments all get their own pages. - Stuff about resource syntax itself gets a page. In the process of breaking the meta-arguments out into their own pages, I revised them (with the exception of `provider`) so that they apply to both resources and modules. Like with Expressions, this commit repurposes the old resources.html URL as a landing page for old links.
2020-11-13 03:06:32 +01:00
## Resource Meta-Arguments
website: revise the "Resources" configuration docs section This is now the leading subsection of the Configuration section of the docs, and so this rewrite intends to make it more "guide-like" and as accessible as possible to those who are not yet familiar with other Terraform concepts. This rewrite also attempts to introduce some consistency into our vocabulary, which should eventually be reflected throughout our documentation. In particular: - "Resource" refers to the block the user writes in configuration, while "Resource _Type_" refers to what the provider defines. We previously used "resource" for both of these interchangeably. - "Resource" is no longer used to refer to what gets created and managed in remote APIs as a result of a resource block in configuration. Lacking a good distinct name for these, this guide uses the word "object", qualifying it as "infrastructure object" or "remote object" where necessary to retain clarity. This distinction is important to enable a clear description of resource lifecycle. - "Argument" refers to an element (attribute or block) within a resource block. This terminology was already being used in some places, so we embrace it here as a way to distinguish from "attribute", which is what a resource _exports_ for use in expressions. - Since interpolation is no longer needed to use expressions in the language, the word "expression" is used to describe the definition of a value that might involve some computation. Where necessary, this is used with a modifier "arbitrary expression" to contrast with situations where the set of allowed expression constructs is constrained.
2018-05-05 23:00:31 +02:00
website: Break up Resources page into smaller chunks - Resource behavior gets its own page. - Meta-arguments all get their own pages. - Stuff about resource syntax itself gets a page. In the process of breaking the meta-arguments out into their own pages, I revised them (with the exception of `provider`) so that they apply to both resources and modules. Like with Expressions, this commit repurposes the old resources.html URL as a landing page for old links.
2020-11-13 03:06:32 +01:00
Each resource meta-argument has moved to its own page.
website: revise the "Resources" configuration docs section This is now the leading subsection of the Configuration section of the docs, and so this rewrite intends to make it more "guide-like" and as accessible as possible to those who are not yet familiar with other Terraform concepts. This rewrite also attempts to introduce some consistency into our vocabulary, which should eventually be reflected throughout our documentation. In particular: - "Resource" refers to the block the user writes in configuration, while "Resource _Type_" refers to what the provider defines. We previously used "resource" for both of these interchangeably. - "Resource" is no longer used to refer to what gets created and managed in remote APIs as a result of a resource block in configuration. Lacking a good distinct name for these, this guide uses the word "object", qualifying it as "infrastructure object" or "remote object" where necessary to retain clarity. This distinction is important to enable a clear description of resource lifecycle. - "Argument" refers to an element (attribute or block) within a resource block. This terminology was already being used in some places, so we embrace it here as a way to distinguish from "attribute", which is what a resource _exports_ for use in expressions. - Since interpolation is no longer needed to use expressions in the language, the word "expression" is used to describe the definition of a value that might involve some computation. Where necessary, this is used with a modifier "arbitrary expression" to contrast with situations where the set of allowed expression constructs is constrained.
2018-05-05 23:00:31 +02:00
website: Break up Resources page into smaller chunks - Resource behavior gets its own page. - Meta-arguments all get their own pages. - Stuff about resource syntax itself gets a page. In the process of breaking the meta-arguments out into their own pages, I revised them (with the exception of `provider`) so that they apply to both resources and modules. Like with Expressions, this commit repurposes the old resources.html URL as a landing page for old links.
2020-11-13 03:06:32 +01:00
<a id="depends_on-explicit-resource-dependencies"></a>
Mildwonkey/012 docs updated (#20542) * docs: update plan command documentation. Fixes #19235 * docs: added a missing reserved variable name. Fixes #19159. * website: add note that resource names cannot start with a number * website: add some notes to the 0.12 upgrade guide
2019-03-01 21:30:51 +01:00
website: Break up Resources page into smaller chunks - Resource behavior gets its own page. - Meta-arguments all get their own pages. - Stuff about resource syntax itself gets a page. In the process of breaking the meta-arguments out into their own pages, I revised them (with the exception of `provider`) so that they apply to both resources and modules. Like with Expressions, this commit repurposes the old resources.html URL as a landing page for old links.
2020-11-13 03:06:32 +01:00
### `depends_on`
website: revise the "Resources" configuration docs section This is now the leading subsection of the Configuration section of the docs, and so this rewrite intends to make it more "guide-like" and as accessible as possible to those who are not yet familiar with other Terraform concepts. This rewrite also attempts to introduce some consistency into our vocabulary, which should eventually be reflected throughout our documentation. In particular: - "Resource" refers to the block the user writes in configuration, while "Resource _Type_" refers to what the provider defines. We previously used "resource" for both of these interchangeably. - "Resource" is no longer used to refer to what gets created and managed in remote APIs as a result of a resource block in configuration. Lacking a good distinct name for these, this guide uses the word "object", qualifying it as "infrastructure object" or "remote object" where necessary to retain clarity. This distinction is important to enable a clear description of resource lifecycle. - "Argument" refers to an element (attribute or block) within a resource block. This terminology was already being used in some places, so we embrace it here as a way to distinguish from "attribute", which is what a resource _exports_ for use in expressions. - Since interpolation is no longer needed to use expressions in the language, the word "expression" is used to describe the definition of a value that might involve some computation. Where necessary, this is used with a modifier "arbitrary expression" to contrast with situations where the set of allowed expression constructs is constrained.
2018-05-05 23:00:31 +02:00
website: Break up Resources page into smaller chunks - Resource behavior gets its own page. - Meta-arguments all get their own pages. - Stuff about resource syntax itself gets a page. In the process of breaking the meta-arguments out into their own pages, I revised them (with the exception of `provider`) so that they apply to both resources and modules. Like with Expressions, this commit repurposes the old resources.html URL as a landing page for old links.
2020-11-13 03:06:32 +01:00
This information has moved to
[`depends_on`](/docs/configuration/meta-arguments/depends_on.html).
website: revise the "Resources" configuration docs section This is now the leading subsection of the Configuration section of the docs, and so this rewrite intends to make it more "guide-like" and as accessible as possible to those who are not yet familiar with other Terraform concepts. This rewrite also attempts to introduce some consistency into our vocabulary, which should eventually be reflected throughout our documentation. In particular: - "Resource" refers to the block the user writes in configuration, while "Resource _Type_" refers to what the provider defines. We previously used "resource" for both of these interchangeably. - "Resource" is no longer used to refer to what gets created and managed in remote APIs as a result of a resource block in configuration. Lacking a good distinct name for these, this guide uses the word "object", qualifying it as "infrastructure object" or "remote object" where necessary to retain clarity. This distinction is important to enable a clear description of resource lifecycle. - "Argument" refers to an element (attribute or block) within a resource block. This terminology was already being used in some places, so we embrace it here as a way to distinguish from "attribute", which is what a resource _exports_ for use in expressions. - Since interpolation is no longer needed to use expressions in the language, the word "expression" is used to describe the definition of a value that might involve some computation. Where necessary, this is used with a modifier "arbitrary expression" to contrast with situations where the set of allowed expression constructs is constrained.
2018-05-05 23:00:31 +02:00
website: Break up Resources page into smaller chunks - Resource behavior gets its own page. - Meta-arguments all get their own pages. - Stuff about resource syntax itself gets a page. In the process of breaking the meta-arguments out into their own pages, I revised them (with the exception of `provider`) so that they apply to both resources and modules. Like with Expressions, this commit repurposes the old resources.html URL as a landing page for old links.
2020-11-13 03:06:32 +01:00
<a id="count-multiple-resource-instances-by-count"></a>
<a id="the-count-object"></a>
<a id="referring-to-instances"></a>
<a id="using-expressions-in-count"></a>
<a id="when-to-use-for_each-instead-of-count"></a>
Website: 0.13 docs edits, mostly around provider requirements (#25686) * Make sidebar nav in language docs more intuitive * Minor display fixes for registry docs * Explain providers in the registry in the providers index * Revise a bunch of language docs around provider reqs This is mostly an effort to smooth out some of the explanations, make sure things are presented in a helpful order, make sure terminology lines up, draw connections between related concepts, make default behavior more apparent, and the like. It shouldn't include very much new information, but there might be one or two things that came out of a conversation somewhere. Co-authored-by: Judith Malnick <judith@hashicorp.com>
2020-07-31 06:07:36 +02:00
website: Break up Resources page into smaller chunks - Resource behavior gets its own page. - Meta-arguments all get their own pages. - Stuff about resource syntax itself gets a page. In the process of breaking the meta-arguments out into their own pages, I revised them (with the exception of `provider`) so that they apply to both resources and modules. Like with Expressions, this commit repurposes the old resources.html URL as a landing page for old links.
2020-11-13 03:06:32 +01:00
### `count`
Website: 0.13 docs edits, mostly around provider requirements (#25686) * Make sidebar nav in language docs more intuitive * Minor display fixes for registry docs * Explain providers in the registry in the providers index * Revise a bunch of language docs around provider reqs This is mostly an effort to smooth out some of the explanations, make sure things are presented in a helpful order, make sure terminology lines up, draw connections between related concepts, make default behavior more apparent, and the like. It shouldn't include very much new information, but there might be one or two things that came out of a conversation somewhere. Co-authored-by: Judith Malnick <judith@hashicorp.com>
2020-07-31 06:07:36 +02:00
website: Break up Resources page into smaller chunks - Resource behavior gets its own page. - Meta-arguments all get their own pages. - Stuff about resource syntax itself gets a page. In the process of breaking the meta-arguments out into their own pages, I revised them (with the exception of `provider`) so that they apply to both resources and modules. Like with Expressions, this commit repurposes the old resources.html URL as a landing page for old links.
2020-11-13 03:06:32 +01:00
This information has moved to
[`count`](/docs/configuration/meta-arguments/count.html).
Website: 0.13 docs edits, mostly around provider requirements (#25686) * Make sidebar nav in language docs more intuitive * Minor display fixes for registry docs * Explain providers in the registry in the providers index * Revise a bunch of language docs around provider reqs This is mostly an effort to smooth out some of the explanations, make sure things are presented in a helpful order, make sure terminology lines up, draw connections between related concepts, make default behavior more apparent, and the like. It shouldn't include very much new information, but there might be one or two things that came out of a conversation somewhere. Co-authored-by: Judith Malnick <judith@hashicorp.com>
2020-07-31 06:07:36 +02:00
website: Break up Resources page into smaller chunks - Resource behavior gets its own page. - Meta-arguments all get their own pages. - Stuff about resource syntax itself gets a page. In the process of breaking the meta-arguments out into their own pages, I revised them (with the exception of `provider`) so that they apply to both resources and modules. Like with Expressions, this commit repurposes the old resources.html URL as a landing page for old links.
2020-11-13 03:06:32 +01:00
<a id="for_each-multiple-resource-instances-defined-by-a-map-or-set-of-strings"></a>
<a id="the-each-object"></a>
<a id="using-expressions-in-for_each"></a>
<a id="referring-to-instances-1"></a>
<a id="using-sets"></a>
Website: 0.13 docs edits, mostly around provider requirements (#25686) * Make sidebar nav in language docs more intuitive * Minor display fixes for registry docs * Explain providers in the registry in the providers index * Revise a bunch of language docs around provider reqs This is mostly an effort to smooth out some of the explanations, make sure things are presented in a helpful order, make sure terminology lines up, draw connections between related concepts, make default behavior more apparent, and the like. It shouldn't include very much new information, but there might be one or two things that came out of a conversation somewhere. Co-authored-by: Judith Malnick <judith@hashicorp.com>
2020-07-31 06:07:36 +02:00
website: Break up Resources page into smaller chunks - Resource behavior gets its own page. - Meta-arguments all get their own pages. - Stuff about resource syntax itself gets a page. In the process of breaking the meta-arguments out into their own pages, I revised them (with the exception of `provider`) so that they apply to both resources and modules. Like with Expressions, this commit repurposes the old resources.html URL as a landing page for old links.
2020-11-13 03:06:32 +01:00
### `for_each`
Website: 0.13 docs edits, mostly around provider requirements (#25686) * Make sidebar nav in language docs more intuitive * Minor display fixes for registry docs * Explain providers in the registry in the providers index * Revise a bunch of language docs around provider reqs This is mostly an effort to smooth out some of the explanations, make sure things are presented in a helpful order, make sure terminology lines up, draw connections between related concepts, make default behavior more apparent, and the like. It shouldn't include very much new information, but there might be one or two things that came out of a conversation somewhere. Co-authored-by: Judith Malnick <judith@hashicorp.com>
2020-07-31 06:07:36 +02:00
website: Break up Resources page into smaller chunks - Resource behavior gets its own page. - Meta-arguments all get their own pages. - Stuff about resource syntax itself gets a page. In the process of breaking the meta-arguments out into their own pages, I revised them (with the exception of `provider`) so that they apply to both resources and modules. Like with Expressions, this commit repurposes the old resources.html URL as a landing page for old links.
2020-11-13 03:06:32 +01:00
This information has moved to
[`for_each`](/docs/configuration/meta-arguments/for_each.html).
Website: 0.13 docs edits, mostly around provider requirements (#25686) * Make sidebar nav in language docs more intuitive * Minor display fixes for registry docs * Explain providers in the registry in the providers index * Revise a bunch of language docs around provider reqs This is mostly an effort to smooth out some of the explanations, make sure things are presented in a helpful order, make sure terminology lines up, draw connections between related concepts, make default behavior more apparent, and the like. It shouldn't include very much new information, but there might be one or two things that came out of a conversation somewhere. Co-authored-by: Judith Malnick <judith@hashicorp.com>
2020-07-31 06:07:36 +02:00
website: Break up Resources page into smaller chunks - Resource behavior gets its own page. - Meta-arguments all get their own pages. - Stuff about resource syntax itself gets a page. In the process of breaking the meta-arguments out into their own pages, I revised them (with the exception of `provider`) so that they apply to both resources and modules. Like with Expressions, this commit repurposes the old resources.html URL as a landing page for old links.
2020-11-13 03:06:32 +01:00
<a id="provider-selecting-a-non-default-provider-configuration"></a>
Website: 0.13 docs edits, mostly around provider requirements (#25686) * Make sidebar nav in language docs more intuitive * Minor display fixes for registry docs * Explain providers in the registry in the providers index * Revise a bunch of language docs around provider reqs This is mostly an effort to smooth out some of the explanations, make sure things are presented in a helpful order, make sure terminology lines up, draw connections between related concepts, make default behavior more apparent, and the like. It shouldn't include very much new information, but there might be one or two things that came out of a conversation somewhere. Co-authored-by: Judith Malnick <judith@hashicorp.com>
2020-07-31 06:07:36 +02:00
website: Break up Resources page into smaller chunks - Resource behavior gets its own page. - Meta-arguments all get their own pages. - Stuff about resource syntax itself gets a page. In the process of breaking the meta-arguments out into their own pages, I revised them (with the exception of `provider`) so that they apply to both resources and modules. Like with Expressions, this commit repurposes the old resources.html URL as a landing page for old links.
2020-11-13 03:06:32 +01:00
### `provider`
website: revise the "Resources" configuration docs section This is now the leading subsection of the Configuration section of the docs, and so this rewrite intends to make it more "guide-like" and as accessible as possible to those who are not yet familiar with other Terraform concepts. This rewrite also attempts to introduce some consistency into our vocabulary, which should eventually be reflected throughout our documentation. In particular: - "Resource" refers to the block the user writes in configuration, while "Resource _Type_" refers to what the provider defines. We previously used "resource" for both of these interchangeably. - "Resource" is no longer used to refer to what gets created and managed in remote APIs as a result of a resource block in configuration. Lacking a good distinct name for these, this guide uses the word "object", qualifying it as "infrastructure object" or "remote object" where necessary to retain clarity. This distinction is important to enable a clear description of resource lifecycle. - "Argument" refers to an element (attribute or block) within a resource block. This terminology was already being used in some places, so we embrace it here as a way to distinguish from "attribute", which is what a resource _exports_ for use in expressions. - Since interpolation is no longer needed to use expressions in the language, the word "expression" is used to describe the definition of a value that might involve some computation. Where necessary, this is used with a modifier "arbitrary expression" to contrast with situations where the set of allowed expression constructs is constrained.
2018-05-05 23:00:31 +02:00
website: Break up Resources page into smaller chunks - Resource behavior gets its own page. - Meta-arguments all get their own pages. - Stuff about resource syntax itself gets a page. In the process of breaking the meta-arguments out into their own pages, I revised them (with the exception of `provider`) so that they apply to both resources and modules. Like with Expressions, this commit repurposes the old resources.html URL as a landing page for old links.
2020-11-13 03:06:32 +01:00
This information has moved to
[`provider`](/docs/configuration/meta-arguments/resource-provider.html).
website: revise the "Resources" configuration docs section This is now the leading subsection of the Configuration section of the docs, and so this rewrite intends to make it more "guide-like" and as accessible as possible to those who are not yet familiar with other Terraform concepts. This rewrite also attempts to introduce some consistency into our vocabulary, which should eventually be reflected throughout our documentation. In particular: - "Resource" refers to the block the user writes in configuration, while "Resource _Type_" refers to what the provider defines. We previously used "resource" for both of these interchangeably. - "Resource" is no longer used to refer to what gets created and managed in remote APIs as a result of a resource block in configuration. Lacking a good distinct name for these, this guide uses the word "object", qualifying it as "infrastructure object" or "remote object" where necessary to retain clarity. This distinction is important to enable a clear description of resource lifecycle. - "Argument" refers to an element (attribute or block) within a resource block. This terminology was already being used in some places, so we embrace it here as a way to distinguish from "attribute", which is what a resource _exports_ for use in expressions. - Since interpolation is no longer needed to use expressions in the language, the word "expression" is used to describe the definition of a value that might involve some computation. Where necessary, this is used with a modifier "arbitrary expression" to contrast with situations where the set of allowed expression constructs is constrained.
2018-05-05 23:00:31 +02:00
website: Break up Resources page into smaller chunks - Resource behavior gets its own page. - Meta-arguments all get their own pages. - Stuff about resource syntax itself gets a page. In the process of breaking the meta-arguments out into their own pages, I revised them (with the exception of `provider`) so that they apply to both resources and modules. Like with Expressions, this commit repurposes the old resources.html URL as a landing page for old links.
2020-11-13 03:06:32 +01:00
<a id="lifecycle-lifecycle-customizations"></a>
website: Structural edit of configuration language docs This commit is a wide-ranging set of edits to the pages under /docs/configuration. Among other things, it - Separates style conventions out into their own page. - Separates type constraints and conversion info into their own page. - Conflates similar complex types a little more freely, since the distinction is only relevant when restricting inputs for a reusable module or resource. - Clarifies several concepts that confused me during edits.
2018-12-11 01:14:33 +01:00
website: Break up Resources page into smaller chunks - Resource behavior gets its own page. - Meta-arguments all get their own pages. - Stuff about resource syntax itself gets a page. In the process of breaking the meta-arguments out into their own pages, I revised them (with the exception of `provider`) so that they apply to both resources and modules. Like with Expressions, this commit repurposes the old resources.html URL as a landing page for old links.
2020-11-13 03:06:32 +01:00
### `lifecycle`
website: Structural edit of configuration language docs This commit is a wide-ranging set of edits to the pages under /docs/configuration. Among other things, it - Separates style conventions out into their own page. - Separates type constraints and conversion info into their own page. - Conflates similar complex types a little more freely, since the distinction is only relevant when restricting inputs for a reusable module or resource. - Clarifies several concepts that confused me during edits.
2018-12-11 01:14:33 +01:00
website: Break up Resources page into smaller chunks - Resource behavior gets its own page. - Meta-arguments all get their own pages. - Stuff about resource syntax itself gets a page. In the process of breaking the meta-arguments out into their own pages, I revised them (with the exception of `provider`) so that they apply to both resources and modules. Like with Expressions, this commit repurposes the old resources.html URL as a landing page for old links.
2020-11-13 03:06:32 +01:00
This information has moved to
[`lifecycle`](/docs/configuration/meta-arguments/lifecycle.html).
website: Structural edit of configuration language docs This commit is a wide-ranging set of edits to the pages under /docs/configuration. Among other things, it - Separates style conventions out into their own page. - Separates type constraints and conversion info into their own page. - Conflates similar complex types a little more freely, since the distinction is only relevant when restricting inputs for a reusable module or resource. - Clarifies several concepts that confused me during edits.
2018-12-11 01:14:33 +01:00
website: Break up Resources page into smaller chunks - Resource behavior gets its own page. - Meta-arguments all get their own pages. - Stuff about resource syntax itself gets a page. In the process of breaking the meta-arguments out into their own pages, I revised them (with the exception of `provider`) so that they apply to both resources and modules. Like with Expressions, this commit repurposes the old resources.html URL as a landing page for old links.
2020-11-13 03:06:32 +01:00
<a id="provisioner-and-connection-resource-provisioners"></a>
website: Structural edit of configuration language docs This commit is a wide-ranging set of edits to the pages under /docs/configuration. Among other things, it - Separates style conventions out into their own page. - Separates type constraints and conversion info into their own page. - Conflates similar complex types a little more freely, since the distinction is only relevant when restricting inputs for a reusable module or resource. - Clarifies several concepts that confused me during edits.
2018-12-11 01:14:33 +01:00
website: Break up Resources page into smaller chunks - Resource behavior gets its own page. - Meta-arguments all get their own pages. - Stuff about resource syntax itself gets a page. In the process of breaking the meta-arguments out into their own pages, I revised them (with the exception of `provider`) so that they apply to both resources and modules. Like with Expressions, this commit repurposes the old resources.html URL as a landing page for old links.
2020-11-13 03:06:32 +01:00
### Provisioners
website: Structural edit of configuration language docs This commit is a wide-ranging set of edits to the pages under /docs/configuration. Among other things, it - Separates style conventions out into their own page. - Separates type constraints and conversion info into their own page. - Conflates similar complex types a little more freely, since the distinction is only relevant when restricting inputs for a reusable module or resource. - Clarifies several concepts that confused me during edits.
2018-12-11 01:14:33 +01:00
website: Break up Resources page into smaller chunks - Resource behavior gets its own page. - Meta-arguments all get their own pages. - Stuff about resource syntax itself gets a page. In the process of breaking the meta-arguments out into their own pages, I revised them (with the exception of `provider`) so that they apply to both resources and modules. Like with Expressions, this commit repurposes the old resources.html URL as a landing page for old links.
2020-11-13 03:06:32 +01:00
This information has moved to
[Provisioners](/docs/configuration/blocks/resources/provisioners/index.html).