Versioned docs: replacing docs links with relative variants (#1537)

Signed-off-by: Janos <86970079+janosdebugs@users.noreply.github.com>
Signed-off-by: Damian Stasik <920747+damianstasik@users.noreply.github.com>
Signed-off-by: Roman Grinovski <roman.grinovski@gmail.com>
Co-authored-by: Damian Stasik <920747+damianstasik@users.noreply.github.com>
Co-authored-by: Roman Grinovski <roman.grinovski@gmail.com>
This commit is contained in:
Janos
2024-04-24 13:24:30 +02:00
committed by GitHub
parent f31de2d6bc
commit a15a6c9657
241 changed files with 1243 additions and 988 deletions

View File

@@ -41,10 +41,10 @@ to reintroduce the provider configuration.
## Provider Version Constraints in Modules
Although provider _configurations_ are shared between modules, each module must
declare its own [provider requirements](/docs/language/providers/requirements), so that
declare its own [provider requirements](../../../language/providers/requirements.mdx), so that
OpenTofu can ensure that there is a single version of the provider that is
compatible with all modules in the configuration and to specify the
[source address](/docs/language/providers/requirements#source-addresses) that serves as
[source address](../../../language/providers/requirements.mdx#source-addresses) that serves as
the global (module-agnostic) identifier for a provider.
To declare that a module requires particular versions of a specific provider,
@@ -67,7 +67,7 @@ however, specify any of the configuration settings that determine what remote
endpoints the provider will access, such as an AWS region; configuration
settings come from provider _configurations_, and a particular overall OpenTofu
configuration can potentially have
[several different configurations for the same provider](/docs/language/providers/configuration#alias-multiple-provider-configurations).
[several different configurations for the same provider](../../../language/providers/configuration.mdx#alias-multiple-provider-configurations).
## Provider Aliases Within Modules
@@ -99,7 +99,7 @@ features are needed by other parts of their overall configuration.
## Implicit Provider Inheritance
For convenience in simple configurations, a child module automatically inherits
[default provider configurations](/docs/language/providers/configuration#default-provider-configurations) from its parent. This means that
[default provider configurations](../../../language/providers/configuration.mdx#default-provider-configurations) from its parent. This means that
explicit `provider` blocks appear only in the root module, and downstream
modules can simply declare resources for that provider and have them
automatically associated with the root provider configurations.
@@ -130,11 +130,11 @@ We recommend using this approach when a single configuration for each provider
is sufficient for an entire configuration.
:::warning Note
Only provider configurations are inherited by child modules, not provider source or version requirements. Each module must [declare its own provider requirements](/docs/language/providers/requirements). This is especially important for non-HashiCorp providers.
Only provider configurations are inherited by child modules, not provider source or version requirements. Each module must [declare its own provider requirements](../../../language/providers/requirements.mdx). This is especially important for non-HashiCorp providers.
:::
In more complex situations there may be
[multiple provider configurations](/docs/language/providers/configuration#alias-multiple-provider-configurations),
[multiple provider configurations](../../../language/providers/configuration.mdx#alias-multiple-provider-configurations),
or a child module may need to use different provider settings than
its parent. For such situations, you must pass providers explicitly.
@@ -171,7 +171,7 @@ module "example" {
```
The `providers` argument within a `module` block is similar to
[the `provider` argument](/docs/language/meta-arguments/resource-provider)
[the `provider` argument](../../../language/meta-arguments/resource-provider.mdx)
within a resource, but is a map rather than a single string because a module may
contain resources from many different providers.