docs: editorial review of part 2 #4
Conversation
review for IBM style, grammar, terminology, and for consistency with part 1. Signed-off-by: Allen Dean <[email protected]>
docs/part2/20-custom-module.md
Outdated
|
|
||
| Notice these two settings in the `main.tf` file: | ||
|
|
||
| - The `override_json_string` input variable is set to `true`, which instructs the landing zone module to look for and use the `override.json` file in the same directory. |
There was a problem hiding this comment.
To me, it's confusing that we say that the var is set to true, yet the value doesn't include that boolean. Should we say more about what we're doing in that templatefile?
There was a problem hiding this comment.
Correct the override_json_string is set to the string value of the templated file that will be used to override the default values.
There was a problem hiding this comment.
Vincent had -
The input named override_json_string takes the full json definition. In this example, the json passed to the module goes through the templatefile function first to 'inject' the prefix. It is done to ensure uniqueness of the resource group names in the account as indicated in step 1.
There was a problem hiding this comment.
Got it. I added this info about the placeholders from what's published.
It seems that there might be some differences between the source branch I was using and what's published out there. Hope there aren't many.
|
|
||
| The purpose of lab 2 is to show of the manual steps in lab 1 can be fully automated. Lab 2 will also show how the fully automated custom solution can be shared with other users in your enterprise through the [IBM Cloud Catalog](https://cloud.ibm.com/catalog). | ||
| Now in lab 2, you use automation to accomplish what you did manually in lab 1. Lab 2 also demonstrates how you can share the fully automated custom solution with other users in your enterprise through the [IBM Cloud catalog](https://cloud.ibm.com/catalog). |
There was a problem hiding this comment.
shouldn't it be -
Now in lab 2, you will use automation
There was a problem hiding this comment.
I've used our tech writing style of keeping most things in the present tense. For example,
In lab 1, you provision a secure VPC-based topology...
Feel free to change back to future if it makes more sense to the lab usage.
|
|
||
| The module accepts more than 70 input variables that you can use to tweak the VPC topology. Consider the input variables as "knobs" that you can turn to adjust the topology. | ||
| - By using a JSON file, named `override.json` | ||
|
|
There was a problem hiding this comment.
You can pass a string value also to the variable called override_json_string
There was a problem hiding this comment.
Changed to By passing a JSON string value to the override.json variable to keep the 2 list items parallel.
docs/part2/20-custom-module.md
Outdated
| ```bash | ||
| In this step, you run a Terraform module that automates the creation of the custom landing zone topology that you defined in the JSON file in the [previous step](./10-customizing.md). | ||
|
|
||
| The objective now is to provide a basic Terraform module that can be easily consumed and that creates the custom VPC topology. You can consider this module as a level of abstraction that simplifies consumption. Consumers of the module do not need to understand the landing zone code or the JSON file that contains the topology definition. They can run a `terraform apply` command with a minimal number of inputs to deploy the fully customized VPC topology in their account. |
There was a problem hiding this comment.
be easily consumed and that creates the custom VPC...
docs/part2/20-custom-module.md
Outdated
|
|
||
| Notice these two settings in the `main.tf` file: | ||
|
|
||
| - The `override_json_string` input variable is set to `true`, which instructs the landing zone module to look for and use the `override.json` file in the same directory. |
There was a problem hiding this comment.
Correct the override_json_string is set to the string value of the templated file that will be used to override the default values.
docs/part2/20-custom-module.md
Outdated
| Notice these two settings in the `main.tf` file: | ||
|
|
||
| - The `override_json_string` input variable is set to `true`, which instructs the landing zone module to look for and use the `override.json` file in the same directory. | ||
| - The `source` is set to the standard VSI pattern and points to the version 4.4.4 (the most recent version at the time that this lab was written). |
docs/part2/20-custom-module.md
Outdated
|
|
||
| Notice these two settings in the `main.tf` file: | ||
|
|
||
| - The `override_json_string` input variable is set to `true`, which instructs the landing zone module to look for and use the `override.json` file in the same directory. |
There was a problem hiding this comment.
Vincent had -
The input named override_json_string takes the full json definition. In this example, the json passed to the module goes through the templatefile function first to 'inject' the prefix. It is done to ensure uniqueness of the resource group names in the account as indicated in step 1.
Signed-off-by: Allen Dean <[email protected]>
|
Pushed some updates @argeiger. |
A rather significant review of the Part 2. Check for accuracy.
FYI, you still have a number of
TODOs in the labPing me if you have questions or don't understand the changes.