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

128 lines
3.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: Add big whitespace separators to recovery landing pages The resources, expressions, and modules pages were all split into smaller, more navigable pages, but the old URLs had accumulated a large number of deep links to their section headers. To help people recover when they click an old link, we converted those old URLs to landing pages, which preserve all of the old in-page anchors and point readers to the appropriate new destinations. However, because the new link-to-new-page sections are so small, it was kind of hard to tell which section you had clicked into! Especially if you were near the bottom of the page and the browser wasn't able to position the desired section at the very top of the window. This commit aims to improve that by putting one full screen of whitespace in between every linkable section on these landing pages. Yes, it's a hack, but you're meant to only view these pages for three seconds or so before moving on to the place you wanted to be, and this should help dispel any confusion about which place that is.
2020-12-02 00:27:41 +01:00
<div style="height: 100vh; margin: 0; padding: 0;"></div>
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: Add big whitespace separators to recovery landing pages The resources, expressions, and modules pages were all split into smaller, more navigable pages, but the old URLs had accumulated a large number of deep links to their section headers. To help people recover when they click an old link, we converted those old URLs to landing pages, which preserve all of the old in-page anchors and point readers to the appropriate new destinations. However, because the new link-to-new-page sections are so small, it was kind of hard to tell which section you had clicked into! Especially if you were near the bottom of the page and the browser wasn't able to position the desired section at the very top of the window. This commit aims to improve that by putting one full screen of whitespace in between every linkable section on these landing pages. Yes, it's a hack, but you're meant to only view these pages for three seconds or so before moving on to the place you wanted to be, and this should help dispel any confusion about which place that is.
2020-12-02 00:27:41 +01:00
<div style="height: 100vh; margin: 0; padding: 0;"></div>
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: Add big whitespace separators to recovery landing pages The resources, expressions, and modules pages were all split into smaller, more navigable pages, but the old URLs had accumulated a large number of deep links to their section headers. To help people recover when they click an old link, we converted those old URLs to landing pages, which preserve all of the old in-page anchors and point readers to the appropriate new destinations. However, because the new link-to-new-page sections are so small, it was kind of hard to tell which section you had clicked into! Especially if you were near the bottom of the page and the browser wasn't able to position the desired section at the very top of the window. This commit aims to improve that by putting one full screen of whitespace in between every linkable section on these landing pages. Yes, it's a hack, but you're meant to only view these pages for three seconds or so before moving on to the place you wanted to be, and this should help dispel any confusion about which place that is.
2020-12-02 00:27:41 +01:00
Each resource meta-argument has moved to its own page:
- [`depends_on`](/docs/configuration/meta-arguments/depends_on.html)
- [`count`](/docs/configuration/meta-arguments/count.html)
- [`for_each`](/docs/configuration/meta-arguments/for_each.html)
- [`provider`](/docs/configuration/meta-arguments/resource-provider.html)
- [`lifecycle`](/docs/configuration/meta-arguments/lifecycle.html)
- [Provisioners](/docs/configuration/blocks/resources/provisioners/index.html)
<div style="height: 100vh; margin: 0; padding: 0;"></div>
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: Add big whitespace separators to recovery landing pages The resources, expressions, and modules pages were all split into smaller, more navigable pages, but the old URLs had accumulated a large number of deep links to their section headers. To help people recover when they click an old link, we converted those old URLs to landing pages, which preserve all of the old in-page anchors and point readers to the appropriate new destinations. However, because the new link-to-new-page sections are so small, it was kind of hard to tell which section you had clicked into! Especially if you were near the bottom of the page and the browser wasn't able to position the desired section at the very top of the window. This commit aims to improve that by putting one full screen of whitespace in between every linkable section on these landing pages. Yes, it's a hack, but you're meant to only view these pages for three seconds or so before moving on to the place you wanted to be, and this should help dispel any confusion about which place that is.
2020-12-02 00:27:41 +01:00
<div style="height: 100vh; margin: 0; padding: 0;"></div>
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: Add big whitespace separators to recovery landing pages The resources, expressions, and modules pages were all split into smaller, more navigable pages, but the old URLs had accumulated a large number of deep links to their section headers. To help people recover when they click an old link, we converted those old URLs to landing pages, which preserve all of the old in-page anchors and point readers to the appropriate new destinations. However, because the new link-to-new-page sections are so small, it was kind of hard to tell which section you had clicked into! Especially if you were near the bottom of the page and the browser wasn't able to position the desired section at the very top of the window. This commit aims to improve that by putting one full screen of whitespace in between every linkable section on these landing pages. Yes, it's a hack, but you're meant to only view these pages for three seconds or so before moving on to the place you wanted to be, and this should help dispel any confusion about which place that is.
2020-12-02 00:27:41 +01:00
<div style="height: 100vh; margin: 0; padding: 0;"></div>
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: Add big whitespace separators to recovery landing pages The resources, expressions, and modules pages were all split into smaller, more navigable pages, but the old URLs had accumulated a large number of deep links to their section headers. To help people recover when they click an old link, we converted those old URLs to landing pages, which preserve all of the old in-page anchors and point readers to the appropriate new destinations. However, because the new link-to-new-page sections are so small, it was kind of hard to tell which section you had clicked into! Especially if you were near the bottom of the page and the browser wasn't able to position the desired section at the very top of the window. This commit aims to improve that by putting one full screen of whitespace in between every linkable section on these landing pages. Yes, it's a hack, but you're meant to only view these pages for three seconds or so before moving on to the place you wanted to be, and this should help dispel any confusion about which place that is.
2020-12-02 00:27:41 +01:00
<div style="height: 100vh; margin: 0; padding: 0;"></div>
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: Add big whitespace separators to recovery landing pages The resources, expressions, and modules pages were all split into smaller, more navigable pages, but the old URLs had accumulated a large number of deep links to their section headers. To help people recover when they click an old link, we converted those old URLs to landing pages, which preserve all of the old in-page anchors and point readers to the appropriate new destinations. However, because the new link-to-new-page sections are so small, it was kind of hard to tell which section you had clicked into! Especially if you were near the bottom of the page and the browser wasn't able to position the desired section at the very top of the window. This commit aims to improve that by putting one full screen of whitespace in between every linkable section on these landing pages. Yes, it's a hack, but you're meant to only view these pages for three seconds or so before moving on to the place you wanted to be, and this should help dispel any confusion about which place that is.
2020-12-02 00:27:41 +01:00
<div style="height: 100vh; margin: 0; padding: 0;"></div>
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: Add big whitespace separators to recovery landing pages The resources, expressions, and modules pages were all split into smaller, more navigable pages, but the old URLs had accumulated a large number of deep links to their section headers. To help people recover when they click an old link, we converted those old URLs to landing pages, which preserve all of the old in-page anchors and point readers to the appropriate new destinations. However, because the new link-to-new-page sections are so small, it was kind of hard to tell which section you had clicked into! Especially if you were near the bottom of the page and the browser wasn't able to position the desired section at the very top of the window. This commit aims to improve that by putting one full screen of whitespace in between every linkable section on these landing pages. Yes, it's a hack, but you're meant to only view these pages for three seconds or so before moving on to the place you wanted to be, and this should help dispel any confusion about which place that is.
2020-12-02 00:27:41 +01:00
<div style="height: 100vh; margin: 0; padding: 0;"></div>
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).
website: Add big whitespace separators to recovery landing pages The resources, expressions, and modules pages were all split into smaller, more navigable pages, but the old URLs had accumulated a large number of deep links to their section headers. To help people recover when they click an old link, we converted those old URLs to landing pages, which preserve all of the old in-page anchors and point readers to the appropriate new destinations. However, because the new link-to-new-page sections are so small, it was kind of hard to tell which section you had clicked into! Especially if you were near the bottom of the page and the browser wasn't able to position the desired section at the very top of the window. This commit aims to improve that by putting one full screen of whitespace in between every linkable section on these landing pages. Yes, it's a hack, but you're meant to only view these pages for three seconds or so before moving on to the place you wanted to be, and this should help dispel any confusion about which place that is.
2020-12-02 00:27:41 +01:00
<div style="height: 100vh; margin: 0; padding: 0;"></div>