fixup! Post about Terragrunt.

content/tf-project-structure.rst

@@ -46,11 +46,10 @@ that has all of the changes (the sub-module changes, the calling modules
 changes, any fallout from those changes).
 
 This process fitted us nicely. The PR had the entire picture and we could really
-see if the change improved anything (like adding an output to a module and
-fetching it in a different module would be clear if you see it being used). We
-did on occasion had conflicting changes and we did had to use targeted
-:code:`plan` and :code:`apply` but as far as I can remember no more than once a
-quarter.
+see if the change improved anything (like adding an output to a module to be
+used in a different module would be clear if you see it being used). We did on
+occasion had conflicting changes and we did had to use targeted :code:`plan` and
+:code:`apply` but as far as I can remember less than once a quarter.
 
 Terragrunt recommends splitting the repository in 2, one for sub-modules and one
 for actually deployed modules. Then you create :code:`terragrunt.hcl` files that
@@ -58,14 +57,15 @@ list the sub-modules needed with the Git ref used. This allows you to use the
 RDS database sub-module from today but the auto-scaling group from last year. I
 see little point in this.
 
-The change process goes as follows, 1 PR for the sub-modules repository and (at
-least) 1 for the live repository. Now I hear that the recommendation has
-changed. The new recommendation is that each sub-module will be in a separate
-repository. So more PRs for each change (that one change of adding an output and
-using it became less obvious but requires more work, I wouldn't call it a win).
-I wonder if there's any place that has 2 repositories, 1 for code 1 for the
-tests and you change the code, and when it's merged you go to the tests repo and
-update the tests there to use the new code to see if it passes?
+The change process goes as follows, 1 PR for the sub-modules repository and 1
+for the live repository (or more, we haven't gotten around to discussing
+environments yet) Now I hear that the recommendation has changed. The new
+recommendation is that each sub-module will be in a separate repository. So more
+PRs for each change (that one change of adding an output and using it became
+less obvious but requires more work, I wouldn't call it a win).  I wonder if
+there's any place that has 2 repositories, 1 for code 1 for the tests and you
+change the code, and when it's merged you go to the tests repo and update the
+tests there to use the new code to see if it passes?
 
 Another outcome from this way of working I keep seeing is that because changes
 are not applied (or planned) before merging the changes to the sub-module,
@@ -103,7 +103,8 @@ would look like this:
     # Review the changes.
     terraform apply tfplan
 
-For making life a little easier I added the following snippet to each module:
+For making life a little easier I also added the following snippet to each
+module:
 
 .. code:: terraform
 
@@ -131,10 +132,10 @@ with the Terraform commands and plan files to stich everything togethere. Even
 on paper this doesn't look like a good idea and it isn't one in practice, making
 debugging issues difficult.
 
-It also suggests that you can have different versions of the different
-sub-modules in use across different environments, putting emphais on having
-the :code:`main` branch match exactly what is each environment instead of
-putting emphasis of avoiding drift between the different environments.
+It also suggests that you can have different versions of the sub-modules in use
+across different environments, putting emphais on having the :code:`main` branch
+match exactly what is each environment instead of putting emphasis of avoiding
+drift between the different environments.
 
 Conclusions
 -----------