luxolus
/
open-consul
2
0
Fork 0
Code Issues 1 Pull Requests Packages Releases Wiki Activity

docs/nia: fix catalog-services typos pt 2 (#10493)

This commit is contained in:
lornasong 2021-06-24 16:45:46 -04:00 committed by GitHub
parent e20abcc14f
commit c232a544a4
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
website/content/docs/nia/configuration.mdx
View File

@ -178,7 +178,7 @@ See [Task Execution: Catalog Services Condition](/docs/nia/tasks#catalog-service
task {
name = "catalog_service_condition_task"
description = "execute on service de/registrations with name matching 'web.*'"
source = "path/to/catalog-service-module"
source = "path/to/catalog-services-module"
providers = ["my-provider"]
// configure depending on module. provides detailed information for these

4
website/content/docs/nia/tasks.mdx
View File

@ -72,11 +72,11 @@ Below is an example configuration for a task that will execute when a service wi
```hcl
task {
name = "catalog_service_condition_task"
source = "path/to/catalog-service-module"
source = "path/to/catalog-services-module"
providers = ["my-provider"]
services = ["web-api"]
condition "catalog-service" {
condition "catalog-services" {
datacenter = "dc1"
regexp = "web.*"
source_includes_var = false

4
website/content/docs/nia/terraform-modules.mdx
View File

@ -101,7 +101,7 @@ variable "services" {
### Catalog Services Variable
If you are creating a module for a [catalog-service condition](/docs/nia/tasks#catalog-services-condition), then you have the option to add the `catalog_services` variable, which contains service registration and tag information. If your module would benefit from consuming this information, you can copy the `catalog_services` variable declaration to your `variables.tf` file in addition to the other variables.
If you are creating a module for a [catalog-services condition](/docs/nia/tasks#catalog-services-condition), then you have the option to add the `catalog_services` variable, which contains service registration and tag information. If your module would benefit from consuming this information, you can copy the `catalog_services` variable declaration to your `variables.tf` file in addition to the other variables.
```hcl
variable "catalog_services" {
@ -112,7 +112,7 @@ variable "catalog_services" {
The keys of the `catalog_services` map are the names of the services that are registered with Consul at the given datacenter. The value for each service name is a list of all known tags for that service.
We recommend that if you make a module with with a catalog-service condition, that you document this in the README. This way, users that want to configure a task with your module will know to configure a catalog-services [condition](/docs/nia/configuration#condition) block.
We recommend that if you make a module with with a catalog-services condition, that you document this in the README. This way, users that want to configure a task with your module will know to configure a catalog-services [condition](/docs/nia/configuration#condition) block.
Similarly, if you include the `catalog_services` variable in your module, we recommend that you also document this usage in the README. Users of your module will then know to set the catalog-services condition [`source_includes_var`](/docs/nia/configuration#source_includes_var) configuration to be true. When this field is set to true, Consul-Terraform-Sync will declare the `catalog_services` variable in the generated root module, and pass the variable to a child module. Therefore, if this field is configured inconsistently, Consul-Terraform-Sync will error and exit.