website: Fix inconsistencies in the registry protocol page

Some hasty, incorrect merge conflict fixing caused this page to have a
strange mix of terminology between "system" and "provider". Along with
that, there were also several editorial errors caused by text on this
page having originally been derived from the provider registry
documentation.

This documentation will now consistently talk about being a module
registry protocol rather than a provider registry protocol, and it will
consistently use the term "system" as a generic term for the final part
of the module source address, aside from noting that there is an optional
convention to name it after the "type" part of an official provider when
possible.
This commit is contained in:
Martin Atkins 2020-11-16 10:06:27 -08:00
parent 8c82b3f6a0
commit 7ccaee1018
1 changed files with 19 additions and 17 deletions

View File

@ -10,7 +10,7 @@ description: |-
# Module Registry Protocol # Module Registry Protocol
-> Third-party provider registries are supported only in Terraform CLI 0.11 and later. Prior versions do not support this protocol. -> Third-party module registries are supported only in Terraform CLI 0.11 and later. Prior versions do not support this protocol.
The module registry protocol is what Terraform CLI uses to discover metadata The module registry protocol is what Terraform CLI uses to discover metadata
about modules available for installation and to locate the distribution about modules available for installation and to locate the distribution
@ -32,25 +32,27 @@ Terraform CLI itself does not use them.
## Module Addresses ## Module Addresses
Each Terraform module has an associated address. A module address has the Each Terraform module has an associated address. A module address has the
syntax `hostname/namespace/name/provider`, where: syntax `hostname/namespace/name/system`, where:
* `hostname` is the hostname of the provider registry that serves this module. * `hostname` is the hostname of the module registry that serves this module.
* `namespace` is the name of a namespace, unique on a particular hostname, that * `namespace` is the name of a namespace, unique on a particular hostname, that
can contain one or more modules that are somehow related. On the public can contain one or more modules that are somehow related. On the public
Terraform Registry the "namespace" represents the organization that is Terraform Registry the "namespace" represents the organization that is
packaging and distributing the module. packaging and distributing the module.
* `name` is the module name, which generally names the abstraction that the * `name` is the module name, which generally names the abstraction that the
module is intending to create. module is intending to create.
* `provider` is the name of a provider that the module is primarily written to * `system` is the name of a remote system that the module is primarily written
target. For multi-cloud abstractions, there can be multiple modules with to target. For multi-cloud abstractions, there can be multiple modules with
addresses that differ only in "provider" to reflect provider-specific addresses that differ only in "system" to reflect provider-specific
implementations of the abstraction, like implementations of the abstraction, like
`registry.terraform.io/hashicorp/consul/aws` vs. `registry.terraform.io/hashicorp/consul/aws` vs.
`registry.terraform.io/hashicorp/consul/azurerm`. The provider name commonly `registry.terraform.io/hashicorp/consul/azurerm`. The system name commonly
matches the type portion of the address of an official provider, but that matches the type portion of the address of an official provider, like `aws`
is not required. or `azurerm` in the above examples, but that is not required and so you can
use whichever system keywords make sense for the organization of your
particular registry.
The `hostname/` portion of a provider address (including its slash delimiter) The `hostname/` portion of a module address (including its slash delimiter)
is optional, and if omitted defaults to `registry.terraform.io/`. is optional, and if omitted defaults to `registry.terraform.io/`.
For example: For example:
@ -61,12 +63,12 @@ For example:
* `example.com/awesomecorp/consul/happycloud` is a hypothetical module published * `example.com/awesomecorp/consul/happycloud` is a hypothetical module published
on a third-party registry. on a third-party registry.
If you intend only to share a module you've developed for use by all If you intend to share a module you've developed for use by all Terraform
Terraform users, please consider publishing it into the public users, please consider publishing it into the public
[Terraform Registry](https://registry.terraform.io/), which will make your [Terraform Registry](https://registry.terraform.io/) to make your module more
module discoverable. You only need to implement this module registry discoverable. You only need to implement this module registry protocol if you
protocol if you wish to publish modules whose addresses include a different wish to publish modules whose addresses include a different hostname that is
hostname that is under your control. under your control.
## Module Versions ## Module Versions
@ -80,7 +82,7 @@ blocks have the same source address.
## Service Discovery ## Service Discovery
The providers protocol begins with Terraform CLI using The module registry protocol begins with Terraform CLI using
[Terraform's remote service discovery protocol](./remote-service-discovery.html), [Terraform's remote service discovery protocol](./remote-service-discovery.html),
with the hostname in the module address acting as the "User-facing Hostname". with the hostname in the module address acting as the "User-facing Hostname".